perm filename MSG.MSG[X3,LSP]48 blob
sn#880993 filedate 1990-01-10 generic text, type C, neo UTF8
COMMENT ⊗ VALID 01070 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00139 00002 ∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
C00141 00003 ∂09-Oct-86 1136 RPG Greetings
C00142 00004 ∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
C00144 00005 ∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
C00151 00006 ∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
C00153 00007 ∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
C00155 00008 ∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
C00157 00009 ∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
C00160 00010 ∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
C00162 00011 ∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
C00163 00012 ∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
C00166 00013 ∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
C00173 00014 ∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
C00175 00015 ∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
C00176 00016 ∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
C00178 00017 ∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
C00179 00018 ∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
C00183 00019 ∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
C00185 00020 ∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
C00192 00021 ∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
C00194 00022 ∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
C00196 00023 ∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
C00198 00024 ∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
C00200 00025 ∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
C00202 00026 ∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
C00204 00027 ∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
C00207 00028 ∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
C00213 00029 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
C00232 00030 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
C00237 00031 ∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
C00243 00032 ∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
C00249 00033 ∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
C00253 00034 ∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
C00280 00035 ∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
C00287 00036 ∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
C00290 00037 ∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
C00292 00038 ∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
C00300 00039 ∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
C00311 00040 ∂10-Feb-87 0246 RPG Registration
C00312 00041 ∂10-Feb-87 2209 RPG Reminder About March Registration Procedure
C00323 00042 ∂13-Feb-87 1948 MATHIS@ADA20.ISI.EDU plans for Palo Alto and mailing
C00330 00043 ∂27-Feb-87 1453 RPG X3 registration list 2/27/87
C00335 00044 ∂27-Feb-87 1513 ohlander@venera.isi.edu Re: X3 registration list 2/27/87
C00337 00045 ∂03-Mar-87 1251 berman@vaxa.isi.edu Re: Who's Where?
C00339 00046 ∂03-Mar-87 1359 berman@vaxa.isi.edu Validation
C00343 00047 ∂07-Mar-87 1414 MATHIS@ADA20.ISI.EDU agenda update
C00345 00048 ∂12-Mar-87 2210 RPG Final Attendee List
C00352 00049 ∂13-Mar-87 0204 brown%bizet.DEC@decwrl.DEC.COM Technical Editor
C00354 00050 ∂13-Mar-87 0852 RPG Writer
C00355 00051 ∂18-Mar-87 1341 MATHIS@ADA20.ISI.EDU draft minutes Palo Alto meeting
C00370 00052 ∂18-Mar-87 1342 MATHIS@ADA20.ISI.EDU meeting documents
C00391 00053 ∂20-Mar-87 1345 primerd!doug@enx.prime.pdn Windows and Graphics Subcommittee
C00393 00054 ∂23-Mar-87 1130 berman@vaxa.isi.edu Gary Brown...
C00394 00055 ∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
C00398 00056 ∂20-Apr-87 2253 dcm%hpfclp@hplabs.HP.COM Fall X3J13 meeting
C00402 00057 ∂21-Apr-87 0821 RWK@YUKON.SCRC.Symbolics.COM On the Kanji feature of Common Lisp
C00405 00058 ∂23-Apr-87 0106 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the character-set extension of Common Lisp
C00409 00059 ∂15-May-87 0436 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Next Meeting
C00411 00060 ∂31-May-87 0903 MATHIS@ADA20.ISI.EDU
C00417 00061 ∂31-May-87 0915 MATHIS@ADA20.ISI.EDU A multi-byte character extension proposal
C00459 00062 ∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 1 of 2
C00509 00063 ∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 2 of 2
C00565 00064 ∂01-Jun-87 0532 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol script
C00572 00065 ∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 3 of 6
C00618 00066 ∂01-Jun-87 0530 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 5 of 6
C00667 00067 ∂01-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 1 of 6
C00717 00068 ∂01-Jun-87 0529 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 4 of 6
C00769 00069 ∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 2 of 6
C00824 00070 ∂01-Jun-87 0531 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 6 of 6
C00877 00071 ∂11-Jun-87 1121 Masinter.pa@Xerox.COM Issues from the cleanup committee
C00879 00072 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
C00884 00073 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
C00890 00074 ∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
C00895 00075 ∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue FORMAT-OP-C (Version 5)
C00902 00076 ∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
C00907 00077 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM AREF-1D (Version 5)
C00913 00078 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
C00917 00079 ∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
C00923 00080 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
C00927 00081 ∂11-Jun-87 1625 Masinter.pa@Xerox.COM (REVISION) Issue: PATHNAME-STREAM (Version 3)
C00932 00082 ∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
C00936 00083 ∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
C00942 00084 ∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
C00950 00085 ∂11-Jun-87 1842 Masinter.pa@Xerox.COM Issue: PRINC-CHARACTER (Version 2)
C00957 00086 ∂15-Jun-87 1920 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
C00969 00087 ∂16-Jun-87 2337 Masinter.pa@Xerox.COM
C00981 00088 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: IF-BODY (Version 7)
C00995 00089 ∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 5)
C01019 00090 ∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
C01023 00091 ∂17-Jun-87 1150 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C01030 00092 ∂17-Jun-87 1247 barmar@Think.COM Issue: FUNCTION-TYPE (Version 5)
C01036 00093 ∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C01039 00094 ∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C01043 00095 ∂17-Jun-87 1740 Mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU updcoming meeting
C01047 00096 ∂17-Jun-87 2011 FAHLMAN@C.CS.CMU.EDU Issue: IF-BODY (Version 7)
C01055 00097 ∂18-Jun-87 0736 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
C01058 00098 ∂18-Jun-87 0821 shebs%orion@cs.utah.edu IF with multiple ELSE
C01060 00099 ∂18-Jun-87 0913 barmar@AQUINAS.THINK.COM Issue: IF-BODY (Version 7)
C01065 00100 ∂18-Jun-87 1001 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
C01068 00101 ∂18-Jun-87 1740 RWK@YUKON.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
C01072 00102 ∂18-Jun-87 2350 RWK@YUKON.SCRC.Symbolics.COM IF with multiple ELSE
C01076 00103 ∂19-Jun-87 2100 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
C01080 00104 ∂19-Jun-87 2204 Moon@STONY-BROOK.SCRC.Symbolics.COM IF with multiple ELSE
C01082 00105 ∂20-Jun-87 0437 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
C01084 00106 ∂21-Jun-87 1652 franz!frisky!jkf@ucbarpa.Berkeley.EDU Re: IF with multiple ELSE
C01086 00107 ∂22-Jun-87 0935 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
C01088 00108 ∂22-Jun-87 1013 cperdue@Sun.COM Re: IF with multiple ELSE
C01091 00109 ∂22-Jun-87 1112 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
C01093 00110 ∂22-Jun-87 1126 FAHLMAN@C.CS.CMU.EDU IF with multiple ELSE
C01096 00111 ∂22-Jun-87 1207 barmar@Think.COM Re: IF with multiple ELSE
C01100 00112 ∂22-Jun-87 1214 shebs@cs.utah.edu Purpose of this Mailing List
C01102 00113 ∂23-Jun-87 1104 RPG Meeting Room at MIT
C01105 00114 ∂25-Jun-87 2342 RPG Meeting Room
C01106 00115 ∂26-Jun-87 1048 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Meeting Room
C01108 00116 ∂30-Jun-87 1109 procyon@Cs.Ucl.AC.UK Common Lisp Mailing List
C01109 00117 ∂02-Jul-87 1648 MATHIS@ADA20.ISI.EDU BALLOT! ISO NWI
C01111 00118 ∂05-Jul-87 1803 MATHIS@ADA20.ISI.EDU DRAFT letter and ballot
C01138 00119 ∂12-Jul-87 2020 MATHIS@ADA20.ISI.EDU x3j13 ballot
C01163 00120 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
C01168 00121 ∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
C01193 00122 ∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
C01195 00123 ∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
C01198 00124 ∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
C01200 00125 ∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
C01206 00126 ∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
C01221 00127 ∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
C01235 00128 ∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
C01243 00129 ∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP 20 Oct 87 16:36:09 PDT
C01246 00130 ∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP 22 Oct 87 08:39:11 PDT
C01248 00131 ∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
C01251 00132 ∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
C01253 00133 ∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
C01270 00134 ∂11-Nov-87 1800 X3J13-mailer Final reservations
C01276 00135 ∂12-Nov-87 1335 X3J13-mailer next meeting
C01279 00136 ∂29-Nov-87 1424 X3J13-mailer subcommittees
C01283 00137 ∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
C01295 00138 ∂14-Dec-87 1055 X3J13-mailer March meeting
C01307 00139 ∂11-Jan-88 1056 X3J13-mailer mailings
C01309 00140 ∂11-Jan-88 1249 X3J13-mailer mailings
C01315 00141 ∂26-Jan-88 1107 X3J13-mailer voting
C01320 00142 ∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
C01322 00143 ∂13-Feb-88 1728 X3J13-mailer Issues from the cleanup sub-committee
C01326 00144 ∂14-Feb-88 1045 X3J13-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
C01334 00145 ∂14-Feb-88 1049 X3J13-mailer Issue: APPEND-DOTTED (Version 5)
C01342 00146 ∂14-Feb-88 1057 X3J13-mailer Issue: AREF-1D (Version 7)
C01349 00147 ∂14-Feb-88 1103 X3J13-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
C01354 00148 ∂14-Feb-88 1109 X3J13-mailer Issue: COLON-NUMBER (Version 1)
C01359 00149 ∂14-Feb-88 1112 X3J13-mailer Issue COMPILER-WARNING-BREAK (Version 4)
C01364 00150 ∂14-Feb-88 1125 X3J13-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
C01369 00151 ∂14-Feb-88 1130 X3J13-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
C01374 00152 ∂14-Feb-88 1122 X3J13-mailer Issue: DECLARE-MACROS (Version 3)
C01389 00153 ∂14-Feb-88 1137 X3J13-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C01395 00154 ∂14-Feb-88 1155 X3J13-mailer Issue: DRIBBLE-TECHNIQUE (Version 2)
C01401 00155 ∂14-Feb-88 1201 X3J13-mailer Issue: FLET-DECLARATIONS (Version 2)
C01407 00156 ∂14-Feb-88 1204 X3J13-mailer Issue: FORMAT-COMMA-INTERVAL (Version 2)
C01413 00157 ∂14-Feb-88 1214 X3J13-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
C01422 00158 ∂14-Feb-88 1223 X3J13-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
C01429 00159 ∂14-Feb-88 1231 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
C01438 00160 ∂14-Feb-88 1301 X3J13-mailer Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
C01446 00161 ∂14-Feb-88 1310 X3J13-mailer Issue: PATHNAME-STREAM (Version 6)
C01453 00162 ∂14-Feb-88 1306 X3J13-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
C01467 00163 ∂14-Feb-88 1300 X3J13-mailer Issue: FUNCTION-TYPE (version 9)
C01496 00164 ∂14-Feb-88 1328 X3J13-mailer Issue: PATHNAME-SYMBOL (Version 5)
C01505 00165 ∂14-Feb-88 1338 X3J13-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
C01520 00166 ∂14-Feb-88 1352 X3J13-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
C01526 00167 ∂14-Feb-88 1341 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C01546 00168 ∂14-Feb-88 1354 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
C01559 00169 ∂14-Feb-88 1408 X3J13-mailer
C01566 00170 ∂14-Feb-88 1406 X3J13-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
C01575 00171 ∂14-Feb-88 1455 X3J13-mailer Common Lisp cleanup issue status to X3J13
C01595 00172 ∂16-Feb-88 1045 X3J13-mailer March 1988 agenda questions
C01597 00173 ∂16-Feb-88 2122 X3J13-mailer March 1988 agenda questions
C01599 00174 ∂23-Feb-88 1308 X3J13-mailer Re: voting
C01601 00175 ∂23-Feb-88 1541 X3J13-mailer voting
C01613 00176 ∂24-Feb-88 1139 X3J13-mailer X3J13 committee meeting agenda draft
C01616 00177 ∂24-Feb-88 1139 X3J13-mailer Subcommittee meetings
C01619 00178 ∂24-Feb-88 1140 X3J13-mailer voting at X3J13
C01622 00179 ∂28-Feb-88 1147 X3J13-mailer ISO meeting news
C01624 00180 ∂01-Mar-88 1445 X3J13-mailer X3 attendee list to date
C01628 00181 ∂02-Mar-88 1203 Common-Lisp-mailer Request to be added to mailing list...
C01630 00182 ∂02-Mar-88 1350 X3J13-mailer Re: X3 attendee list to date
C01632 00183 ∂04-Mar-88 1440 X3J13-mailer X3J13 attendee list
C01638 00184 ∂07-Mar-88 1542 X3J13-mailer new and improved list
C01644 00185 ∂08-Mar-88 1121 X3J13-mailer Re: X3J13 attendee list
C01646 00186 ∂08-Mar-88 1339 X3J13-mailer X3 attendee list to date
C01648 00187 ∂19-Mar-88 1821 X3J13-mailer last meeting
C01650 00188 ∂19-Mar-88 1844 X3J13-mailer minutes 3/88 mtg
C01670 00189 ∂21-Apr-88 0708 X3J13-mailer X3J13 Meeting 6/13 - 6/17/88
C01672 00190 ∂21-Apr-88 0829 X3J13-mailer X3J13 Meeting
C01680 00191 ∂21-Apr-88 0908 X3J13-mailer X3J13 Meeting
C01688 00192 ∂21-Apr-88 1242 X3J13-mailer X3J13 Meeting
C01691 00193 ∂21-Apr-88 1306 X3J13-mailer X3J13 Meeting
C01694 00194 ∂21-Apr-88 1352 X3J13-mailer X3J13 Meeting
C01697 00195 ∂22-Apr-88 0114 X3J13-mailer X3J13 Meeting
C01700 00196 ∂25-Apr-88 1415 X3J13-mailer June Meeting addendum and varia
C01704 00197 ∂25-Apr-88 1830 X3J13-mailer June Meeting addendum and varia
C01706 00198 ∂25-Apr-88 1937 X3J13-mailer X3J13 Meeting
C01708 00199 ∂26-Apr-88 0848 X3J13-mailer June Meeting addendum and varia
C01710 00200 ∂27-Apr-88 0100 X3J13-mailer June Meeting addendum and varia
C01712 00201 ∂27-Apr-88 0104 X3J13-mailer June Meeting addendum and varia
C01714 00202 ∂28-Apr-88 1315 X3J13-mailer mail to bouzane for June X3 meeting
C01716 00203 ∂10-May-88 1438 X3J13-mailer X3J13 June Meeting
C01720 00204 ∂10-May-88 2005 X3J13-mailer Re: June Meeting
C01722 00205 ∂16-May-88 1119 X3J13-mailer agenda items please
C01724 00206 ∂19-May-88 1621 X3J13-mailer mailing deadline approaches
C01726 00207 ∂23-May-88 1640 X3J13-mailer June agenda draft
C01729 00208 ∂30-May-88 1838 X3J13-mailer mailing list and next meeting
C01734 00209 ∂02-Jun-88 1614 X3J13-mailer 88-007
C01736 00210 ∂07-Jun-88 1559 X3J13-mailer Issue: FUNCTION-TYPE (version 11)
C01756 00211 ∂08-Jun-88 1211 X3J13-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01762 00212 ∂08-Jun-88 1237 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
C01767 00213 ∂08-Jun-88 1244 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
C01782 00214 ∂08-Jun-88 1509 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C01786 00215 ∂08-Jun-88 1524 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
C01790 00216 ∂08-Jun-88 1531 X3J13-mailer Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
C01799 00217 ∂08-Jun-88 1806 X3J13-mailer Issue: EVAL-OTHER (Version 2)
C01806 00218 ∂08-Jun-88 1752 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
C01818 00219 ∂08-Jun-88 1918 X3J13-mailer Issue: DEFPACKAGE (version 2)
C01830 00220 ∂08-Jun-88 1946 X3J13-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
C01834 00221 ∂08-Jun-88 1958 X3J13-mailer Issue: LAST-N (Version 2)
C01839 00222 ∂08-Jun-88 2030 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
C01847 00223 ∂08-Jun-88 2049 X3J13-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
C01853 00224 ∂08-Jun-88 2058 X3J13-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
C01860 00225 ∂08-Jun-88 2103 X3J13-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2
C01867 00226 ∂09-Jun-88 0714 CL-Cleanup-mailer Issue: LAST-N (Version 2)
C01869 00227 ∂09-Jun-88 0907 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C01871 00228 ∂09-Jun-88 1043 X3J13-mailer [bouzane@scrc-pegasus: X3J13 Meeting]
C01874 00229 ∂09-Jun-88 1525 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
C01876 00230 ∂09-Jun-88 2119 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
C01883 00231 ∂09-Jun-88 2136 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
C01887 00232 ∂09-Jun-88 2307 X3J13-mailer Issue status
C01890 00233 ∂10-Jun-88 0056 X3J13-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
C01900 00234 ∂10-Jun-88 0107 X3J13-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
C01908 00235 ∂10-Jun-88 0108 X3J13-mailer Issue: STEP-ENVIRONMENT (Version 1)
C01914 00236 ∂10-Jun-88 0154 X3J13-mailer Issues for discussion at June 1988 X3J13 meeting
C01920 00237 ∂07-Jul-88 0732 X3J13-mailer DRAFT Minutes June meeting
C01945 00238 ∂11-Aug-88 1444 X3J13-mailer CLOS workshop
C01950 00239 ∂11-Aug-88 1607 X3J13-mailer CLOS workshop
C01955 00240 ∂19-Aug-88 1210 X3J13-mailer Virginia and Hawaii X3J13 meetings
C01964 00241 ∂04-Sep-88 1352 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
C01969 00242 ∂04-Sep-88 1342 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C01989 00243 ∂08-Sep-88 1751 X3J13-mailer Fairfax X3 registration form
C01995 00244 ∂12-Sep-88 0841 X3J13-mailer Availability of the standard
C01997 00245 ∂12-Sep-88 1344 X3J13-mailer Common Lisp Mailing Lists
C01998 00246 ∂12-Sep-88 1954 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C02006 00247 ∂13-Sep-88 0841 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C02012 00248 ∂13-Sep-88 1139 X3J13-mailer Re: Issue: FUNCTION-TYPE (version 12)
C02015 00249 ∂15-Sep-88 0225 X3J13-mailer "passed" cleanup issues
C02019 00250 ∂15-Sep-88 1617 X3J13-mailer additional passed clean-up issues
C02021 00251 ∂16-Sep-88 1145 X3J13-mailer agenda items please
C02024 00252 ∂16-Sep-88 1157 X3J13-mailer subcommittee meetings
C02026 00253 ∂19-Sep-88 1857 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
C02029 00254 ∂23-Sep-88 1056 X3J13-mailer issue COMPILE-FILE-PACKAGE
C02032 00255 ∂23-Sep-88 1053 X3J13-mailer compiler cleanup issue status
C02037 00256 ∂23-Sep-88 1056 X3J13-mailer issue OPTIMIZE-DEBUG-INFO
C02042 00257 ∂23-Sep-88 1057 X3J13-mailer issue PROCLAIM-INLINE-WHERE
C02047 00258 ∂23-Sep-88 1055 X3J13-mailer issue COMPILE-ARGUMENT-PROBLEMS
C02053 00259 ∂23-Sep-88 1054 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
C02067 00260 ∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
C02081 00261 ∂23-Sep-88 1054 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
C02095 00262 ∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
C02105 00263 ∂23-Sep-88 1055 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
C02116 00264 ∂23-Sep-88 1212 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
C02119 00265 ∂26-Sep-88 0931 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
C02126 00266 ∂26-Sep-88 0931 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
C02132 00267 ∂26-Sep-88 0931 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
C02147 00268 ∂26-Sep-88 1041 X3J13-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL
C02150 00269 ∂26-Sep-88 1203 X3J13-mailer Hawaii hotel arrangements
C02152 00270 ∂29-Sep-88 1544 X3J13-mailer Fairfax attendees
C02157 00271 ∂29-Sep-88 1546 X3J13-mailer Fairfax Subcommittee Meetings Update
C02159 00272 ∂29-Sep-88 1544 X3J13-mailer Fairfax Updated Agenda DRAFT
C02162 00273 ∂29-Sep-88 1825 X3J13-mailer Re: Fairfax Updated Agenda DRAFT
C02164 00274 ∂30-Sep-88 0956 X3J13-mailer Fairfax attendees
C02166 00275 ∂30-Sep-88 1236 X3J13-mailer March '89 X3J13/ISO meeting host needed
C02168 00276 ∂30-Sep-88 1405 X3J13-mailer Arpanet access during Fairfax meeting
C02170 00277 ∂03-Oct-88 1122 X3J13-mailer Subcommittee Meetings at Contel
C02172 00278 ∂03-Oct-88 1252 X3J13-mailer Error terminology
C02194 00279 ∂04-Oct-88 1159 X3J13-mailer Hotel reservations for Hawaii
C02196 00280 ∂04-Oct-88 2041 X3J13-mailer Re: error definitions
C02200 00281 ∂06-Oct-88 1249 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C02206 00282 ∂06-Oct-88 1317 X3J13-mailer Fairfax Registration
C02212 00283 ∂06-Oct-88 1328 X3J13-mailer Revised DRAFT Agenda
C02215 00284 ∂06-Oct-88 1714 X3J13-mailer X3J13 issues to be emailed: stay tuned for barrage
C02217 00285 ∂06-Oct-88 1718 X3J13-mailer Issue: ALIST-NIL (Version 4)
C02225 00286 ∂06-Oct-88 1752 X3J13-mailer Arpanet access during Dallas PI meeting
C02227 00287 ∂06-Oct-88 1806 X3J13-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
C02233 00288 ∂06-Oct-88 1921 X3J13-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
C02240 00289 ∂06-Oct-88 2007 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 6)
C02250 00290 ∂06-Oct-88 2058 X3J13-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
C02256 00291 ∂06-Oct-88 2057 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
C02263 00292 ∂06-Oct-88 2058 X3J13-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
C02269 00293 ∂06-Oct-88 2058 X3J13-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
C02275 00294 ∂06-Oct-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
C02281 00295 ∂06-Oct-88 2111 X3J13-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
C02289 00296 ∂06-Oct-88 2123 X3J13-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C02295 00297 ∂06-Oct-88 2150 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
C02305 00298 ∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
C02307 00299 ∂07-Oct-88 1501 X3J13-mailer Issue HASH-TABLE-TESTS (Version 1)
C02315 00300 ∂07-Oct-88 1501 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
C02321 00301 ∂07-Oct-88 1643 X3J13-mailer Issue: NTH-VALUE (Version 3)
C02327 00302 ∂07-Oct-88 1642 X3J13-mailer Issue: LAMBDA-FORM (Version 3)
C02335 00303 ∂07-Oct-88 2151 X3J13-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C02343 00304 ∂07-Oct-88 2151 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
C02348 00305 ∂07-Oct-88 2150 X3J13-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C02356 00306 ∂07-Oct-88 2152 X3J13-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
C02368 00307 ∂07-Oct-88 2206 X3J13-mailer STEP-ENVIRONMENT, version 3
C02373 00308 ∂07-Oct-88 2151 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C02393 00309 ∂07-Oct-88 2215 X3J13-mailer Issue: STREAM-ACCESS (version 1)
C02402 00310 ∂07-Oct-88 2317 X3J13-mailer Issue: SUBTYPEP-TOO-VAGUE (Version 4)
C02410 00311 ∂07-Oct-88 2334 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 4)
C02418 00312 ∂07-Oct-88 2343 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
C02423 00313 ∂08-Oct-88 1150 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
C02426 00314 ∂08-Oct-88 1229 X3J13-mailer REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
C02428 00315 ∂08-Oct-88 1253 X3J13-mailer DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
C02434 00316 ∂08-Oct-88 1320 X3J13-mailer DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
C02448 00317 ∂08-Oct-88 1329 X3J13-mailer DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
C02469 00318 ∂08-Oct-88 1441 X3J13-mailer DRAFT Issue: DEFPACKAGE (version 6)
C02485 00319 ∂08-Oct-88 1547 X3J13-mailer DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
C02492 00320 ∂08-Oct-88 1605 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
C02498 00321 ∂08-Oct-88 1651 X3J13-mailer DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
C02505 00322 ∂08-Oct-88 1651 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 5)
C02514 00323 ∂08-Oct-88 1651 X3J13-mailer Issue: EXIT-EXTENT (Version 3)
C02529 00324 ∂08-Oct-88 1703 X3J13-mailer DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
C02539 00325 ∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
C02549 00326 ∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
C02562 00327 ∂08-Oct-88 1741 X3J13-mailer DRAFTIssue: HASH-TABLE-ACCESS (version 1)
C02568 00328 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C02579 00329 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
C02595 00330 ∂08-Oct-88 1751 X3J13-mailer DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
C02605 00331 ∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-DEFINITION (Version 1)
C02625 00332 ∂08-Oct-88 1956 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
C02633 00333 ∂08-Oct-88 2035 X3J13-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
C02640 00334 ∂08-Oct-88 2043 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 4)
C02655 00335 ∂08-Oct-88 2055 X3J13-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
C02670 00336 ∂08-Oct-88 2106 X3J13-mailer PRINT-CIRCLE-STRUCTURE (Version 3)
C02678 00337 ∂08-Oct-88 2112 X3J13-mailer DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
C02700 00338 ∂08-Oct-88 2134 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
C02709 00339 ∂08-Oct-88 2146 X3J13-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
C02714 00340 ∂08-Oct-88 2129 X3J13-mailer DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
C02742 00341 ∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
C02746 00342 ∂08-Oct-88 2203 X3J13-mailer DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
C02755 00343 ∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TAILP-NIL (Version 2)
C02763 00344 ∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
C02772 00345 ∂08-Oct-88 2153 X3J13-mailer Issue: SETF-SUB-METHODS (Version 5)
C02799 00346 ∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: STREAM-INFO (Version 5)
C02825 00347 ∂08-Oct-88 2216 X3J13-mailer DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C02834 00348 ∂09-Oct-88 0230 X3J13-mailer Draft Issue: CLOS-CONDITIONS (Version 3)
C02849 00349 ∂14-Oct-88 1427 X3J13-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
C02860 00350 ∂18-Oct-88 2146 CL-Cleanup-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
C02862 00351 ∂25-Oct-88 0852 X3J13-mailer Proposed US Position Statement
C02868 00352 ∂25-Oct-88 1405 X3J13-mailer Comments on Cleanup issues due within two weeks
C02871 00353 ∂26-Oct-88 1925 X3J13-mailer Proposed US Position Statement
C02873 00354 ∂28-Oct-88 0347 X3J13-mailer mailing list update
C02874 00355 ∂01-Nov-88 1237 X3J13-mailer March meeting
C02876 00356 ∂01-Nov-88 1245 X3J13-mailer March meeting
C02878 00357 ∂02-Nov-88 0930 X3J13-mailer Hawaii hotel reservations reminder
C02880 00358 ∂02-Nov-88 1612 X3J13-mailer Re: Proposed US Position Statement
C02888 00359 ∂07-Nov-88 0639 X3J13-mailer Re: Proposed US Position Statement
C02890 00360 ∂07-Nov-88 1517 X3J13-mailer US Position Statement (Version 2)
C02899 00361 ∂09-Nov-88 1137 X3J13-mailer Official US Position
C02907 00362 ∂14-Nov-88 0804 X3J13-mailer Re: Hawaii hotel reservations reminder
C02909 00363 ∂14-Nov-88 1130 X3J13-mailer Ignore that message
C02910 00364 ∂20-Nov-88 0359 X3J13-mailer Phase 1 standard
C02912 00365 ∂29-Nov-88 1235 X3J13-mailer ISO Meeting Report
C02939 00366 ∂02-Dec-88 2351 X3J13-mailer re: ISO meeting report
C02947 00367 ∂05-Dec-88 1209 X3J13-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C02984 00368 ∂05-Dec-88 1238 X3J13-mailer Another Report on ISO/WG16
C02994 00369 ∂05-Dec-88 1249 X3J13-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 4)
C03004 00370 ∂05-Dec-88 1531 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
C03012 00371 ∂05-Dec-88 1641 X3J13-mailer Issue: DEFPACKAGE (Version 7)
C03033 00372 ∂06-Dec-88 0810 X3J13-mailer Re: ISO meeting report
C03038 00373 ∂07-Dec-88 1425 X3J13-mailer January agenda items please
C03040 00374 ∂07-Dec-88 1659 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 4)
C03051 00375 ∂07-Dec-88 1803 X3J13-mailer Issue: DOTTED-MACRO-FORMS (Version 3)
C03060 00376 ∂07-Dec-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
C03066 00377 ∂07-Dec-88 2143 X3J13-mailer Issue: FORMAT-PRETTY-PRINT (Version 7)
C03076 00378 ∂08-Dec-88 0613 X3J13-mailer Re: January agenda items please
C03078 00379 ∂08-Dec-88 1056 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
C03087 00380 ∂08-Dec-88 1129 X3J13-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
C03093 00381 ∂08-Dec-88 1147 X3J13-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
C03116 00382 ∂08-Dec-88 1524 X3J13-mailer Issue: HASH-TABLE-TESTS (Version 2)
C03124 00383 ∂08-Dec-88 1644 X3J13-mailer Issue: LCM-NO-ARGUMENTS (Version 1)
C03127 00384 ∂08-Dec-88 1643 X3J13-mailer Issue: LAMBDA-FORM (Version 4)
C03137 00385 ∂08-Dec-88 1716 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 5)
C03147 00386 ∂08-Dec-88 1739 X3J13-mailer Issue: NTH-VALUE (Version 4)
C03153 00387 ∂08-Dec-88 2041 X3J13-mailer Issue: PACKAGE-DELETION (Version 5)
C03167 00388 ∂09-Dec-88 0039 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
C03174 00389 ∂09-Dec-88 0057 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
C03195 00390 ∂09-Dec-88 0119 X3J13-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
C03197 00391 ∂09-Dec-88 0059 X3J13-mailer Issue: SETF-PLACES (Version 1)
C03229 00392 ∂09-Dec-88 0119 X3J13-mailer Issue: FUNCTION-DEFINITION (Version 2)
C03238 00393 ∂09-Dec-88 0133 X3J13-mailer Issue: STREAM-ACCESS (Version 2)
C03249 00394 ∂09-Dec-88 1008 X3J13-mailer Issue: STREAM-INFO (Version 6)
C03274 00395 ∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-DECLARE (Version 2)
C03279 00396 ∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
C03289 00397 ∂09-Dec-88 1407 X3J13-mailer Caveat on "From: cl-cleanup..."
C03291 00398 ∂09-Dec-88 1406 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 5)
C03300 00399 ∂09-Dec-88 1531 X3J13-mailer Issue: TEST-NOT-IF-NOT (Version 2)
C03310 00400 ∂09-Dec-88 1605 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
C03320 00401 ∂09-Dec-88 1618 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
C03326 00402 ∂09-Dec-88 1705 X3J13-mailer Issue: DECLARATION-SCOPE (Version 4)
C03353 00403 ∂09-Dec-88 1742 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 8)
C03365 00404 ∂10-Dec-88 0348 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
C03367 00405 ∂10-Dec-88 0513 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 8)
C03371 00406 ∂10-Dec-88 1236 X3J13-mailer ISO Meeting Status
C03373 00407 ∂12-Dec-88 0832 X3J13-mailer Re: ISO Meeting Status
C03376 00408 ∂12-Dec-88 0942 X3J13-mailer Issue release & scheduling
C03379 00409 ∂12-Dec-88 0942 X3J13-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 3)
C03385 00410 ∂12-Dec-88 1004 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
C03390 00411 ∂12-Dec-88 1111 X3J13-mailer Issue: FIXNUM-NON-PORTABLE (Version 4)
C03399 00412 ∂12-Dec-88 1054 X3J13-mailer Issue: EXIT-EXTENT (Version 5)
C03423 00413 ∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 3)
C03435 00414 ∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-COMPOSITION (Version 4)
C03449 00415 ∂12-Dec-88 1212 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 4)
C03457 00416 ∂12-Dec-88 1212 X3J13-mailer Issue: HASH-TABLE-STABILITY (Version 1)
C03490 00417 ∂12-Dec-88 1400 X3J13-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
C03502 00418 ∂12-Dec-88 1400 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
C03519 00419 ∂12-Dec-88 1434 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)
C03527 00420 ∂12-Dec-88 1434 X3J13-mailer Issue: PROCLAIM-LEXICAL (Version 9)
C03549 00421 ∂12-Dec-88 1528 X3J13-mailer Issue: TAILP-NIL (Version 5)
C03560 00422 ∂12-Dec-88 1601 X3J13-mailer Re: Issue: TEST-NOT-IF-NOT (Version 3)
C03561 00423 ∂12-Dec-88 1609 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
C03571 00424 ∂12-Dec-88 1623 X3J13-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
C03577 00425 ∂12-Dec-88 1622 X3J13-mailer Issue: REST-LIST-ALLOCATION (Version 3)
C03591 00426 ∂12-Dec-88 1735 X3J13-mailer CommonLisp/C interface
C03593 00427 ∂12-Dec-88 1755 X3J13-mailer Issue: TAILP-NIL (Version 5)
C03595 00428 ∂12-Dec-88 1838 X3J13-mailer ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
C03610 00429 ∂13-Dec-88 0800 X3J13-mailer CommonLisp/C interface
C03612 00430 ∂13-Dec-88 0819 X3J13-mailer CommonLisp/C interface
C03617 00431 ∂13-Dec-88 0833 X3J13-mailer Re: CommonLisp/C interface
C03619 00432 ∂13-Dec-88 1115 X3J13-mailer [barmar@Think.COM: CommonLisp/C interface]
C03623 00433 ∂13-Dec-88 1120 X3J13-mailer CommonLisp/C interface
C03628 00434 ∂13-Dec-88 1233 X3J13-mailer Re: CommonLisp/C interface
C03632 00435 ∂14-Dec-88 1043 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C03635 00436 ∂14-Dec-88 1157 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
C03637 00437 ∂14-Dec-88 1205 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C03639 00438 ∂14-Dec-88 1659 X3J13-mailer Hawaii registration
C03643 00439 ∂14-Dec-88 1707 X3J13-mailer Re: CommonLisp/C interface
C03648 00440 ∂15-Dec-88 0929 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C03651 00441 ∂15-Dec-88 0945 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C03653 00442 ∂15-Dec-88 1504 X3J13-mailer Hawaii registration form
C03657 00443 ∂15-Dec-88 1525 X3J13-mailer Hawaii registration form OOOPS!
C03659 00444 ∂15-Dec-88 1715 X3J13-mailer Symbolics Cambridge office is moving
C03661 00445 ∂16-Dec-88 0847 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C03663 00446 ∂19-Dec-88 2242 X3J13-mailer Corrections to the ISO Report
C03670 00447 ∂20-Dec-88 0233 X3J13-mailer Gabriel's report
C03675 00448 ∂20-Dec-88 0757 X3J13-mailer Re: Gabriel's report
C03678 00449 ∂20-Dec-88 1137 X3J13-mailer access to the standard
C03680 00450 ∂22-Dec-88 1139 X3J13-mailer Error terminology
C03682 00451 ∂22-Dec-88 1241 X3J13-mailer Re: Corrections to the ISO Report
C03691 00452 ∂22-Dec-88 1447 X3J13-mailer Re: Corrections to the ISO Report
C03700 00453 ∂03-Jan-89 1228 X3J13-mailer Hawaii registration status
C03706 00454 ∂03-Jan-89 1324 X3J13-mailer issues from cl-compiler
C03708 00455 ∂03-Jan-89 1424 X3J13-mailer issue ALLOW-LOCAL-INLINE
C03717 00456 ∂03-Jan-89 1428 X3J13-mailer issue DEFCONSTANT-SPECIAL
C03724 00457 ∂03-Jan-89 1426 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY
C03738 00458 ∂03-Jan-89 1432 X3J13-mailer issue SHARP-COMMA-CONFUSION
C03746 00459 ∂03-Jan-89 1429 X3J13-mailer issue LOAD-TIME-EVAL
C03762 00460 ∂05-Jan-89 1342 X3J13-mailer ISO discussion and X3J13 Agenda DRAFT
C03766 00461 ∂06-Jan-89 1504 X3J13-mailer Ballots, please
C03768 00462 ∂06-Jan-89 2253 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C03789 00463 ∂07-Jan-89 0935 X3J13-mailer Issue CONSTANT-MODIFICATION, version 2
C03794 00464 ∂07-Jan-89 0933 X3J13-mailer Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
C03813 00465 ∂07-Jan-89 0946 X3J13-mailer **DRAFT** Issue COMPILER-VERBOSITY, version 5
C03825 00466 ∂07-Jan-89 0944 X3J13-mailer **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
C03852 00467 ∂07-Jan-89 1048 X3J13-mailer issues relating to compiled constants
C03855 00468 ∂07-Jan-89 1049 X3J13-mailer **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
C03866 00469 ∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue CONSTANT-COLLAPSING
C03872 00470 ∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue QUOTE-MAY-COPY
C03898 00471 ∂07-Jan-89 1048 X3J13-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
C03926 00472 ∂07-Jan-89 1316 X3J13-mailer **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
C03937 00473 ∂07-Jan-89 1311 X3J13-mailer **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
C03948 00474 ∂08-Jan-89 2342 CL-Compiler-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
C03950 00475 ∂09-Jan-89 0848 X3J13-mailer Editorial committee issues
C03952 00476 ∂09-Jan-89 0849 X3J13-mailer Issue:DEPRECATION-POSITION
C03960 00477 ∂09-Jan-89 0851 X3J13-mailer Issue:SUBSETTING-POSITION
C03968 00478 ∂09-Jan-89 0851 X3J13-mailer Issue:CUT-OFF-DATES
C03977 00479 ∂09-Jan-89 0852 X3J13-mailer Issue:CONFORMANCE-POSITION
C03983 00480 ∂09-Jan-89 1155 X3J13-mailer Issue:EXTENSIONS-POSITION
C03991 00481 ∂09-Jan-89 1242 X3J13-mailer Re: Issue:SUBSETTING-POSITION
C03995 00482 ∂09-Jan-89 1303 X3J13-mailer revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
C03999 00483 ∂10-Jan-89 0905 X3J13-mailer FTP access to compiler issues
C04001 00484 ∂10-Jan-89 0935 X3J13-mailer **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
C04012 00485 ∂10-Jan-89 1238 X3J13-mailer summary of open cl-compiler issues
C04020 00486 ∂10-Jan-89 1543 X3J13-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 2)
C04025 00487 ∂10-Jan-89 1555 X3J13-mailer Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
C04030 00488 ∂10-Jan-89 1710 X3J13-mailer Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
C04034 00489 ∂11-Jan-89 1433 X3J13-mailer Another DRAFT Agenda
C04038 00490 ∂11-Jan-89 1649 X3J13-mailer Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
C04046 00491 ∂11-Jan-89 1703 X3J13-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
C04061 00492 ∂11-Jan-89 2008 X3J13-mailer Ballot (finally)
C04083 00493 ∂11-Jan-89 2237 X3J13-mailer Issue: SPECIAL-TYPE-SHADOWING (Version 1)
C04089 00494 ∂11-Jan-89 2233 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
C04098 00495 ∂11-Jan-89 2316 X3J13-mailer Issue: THE-AMBIGUITY (Version 2)
C04106 00496 ∂11-Jan-89 2346 X3J13-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
C04117 00497 ∂11-Jan-89 2357 X3J13-mailer Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
C04125 00498 ∂12-Jan-89 0015 X3J13-mailer Issue: EQUAL-STRUCTURE, (Version 6)
C04136 00499 ∂12-Jan-89 0104 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
C04149 00500 ∂12-Jan-89 0117 X3J13-mailer Issue: APPEND-ATOM (Version 1)
C04157 00501 ∂12-Jan-89 0121 X3J13-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C04168 00502 ∂12-Jan-89 1413 X3J13-mailer Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
C04177 00503 ∂12-Jan-89 1526 X3J13-mailer Issue: REMF-MULTIPLE (Version 2)
C04185 00504 ∂12-Jan-89 1642 X3J13-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
C04212 00505 ∂12-Jan-89 1711 X3J13-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C04224 00506 ∂12-Jan-89 1731 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
C04232 00507 ∂23-Jan-89 1051 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C04235 00508 ∂23-Jan-89 1409 X3J13-mailer Second edition of "Common Lisp: The Language"
C04243 00509 ∂23-Jan-89 1423 X3J13-mailer cl-compiler issues
C04246 00510 ∂24-Jan-89 1231 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
C04271 00511 ∂24-Jan-89 1312 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
C04274 00512 ∂25-Jan-89 0613 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C04280 00513 ∂25-Jan-89 0850 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C04282 00514 ∂25-Jan-89 0936 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C04285 00515 ∂26-Jan-89 0002 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
C04293 00516 ∂26-Jan-89 1803 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
C04298 00517 ∂27-Jan-89 0307 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C04301 00518 ∂31-Jan-89 0132 X3J13-mailer Comments on the Character proposal dated January 1, 1989
C04310 00519 ∂31-Jan-89 1357 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
C04315 00520 ∂01-Feb-89 1353 X3J13-mailer Fairfax information and registration form
C04321 00521 ∂02-Feb-89 1307 X3J13-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
C04331 00522 ∂03-Feb-89 2333 X3J13-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
C04338 00523 ∂05-Feb-89 1020 X3J13-mailer Fairfax and Hotel badness
C04340 00524 ∂07-Feb-89 1543 X3J13-mailer What-a-Guy!
C04345 00525 ∂09-Feb-89 0436 X3J13-mailer Preview of things to come from editorial committee
C04349 00526 ∂09-Feb-89 0440 X3J13-mailer Issue: FONTS
C04353 00527 ∂09-Feb-89 0444 X3J13-mailer Issue: TOC
C04363 00528 ∂09-Feb-89 0437 X3J13-mailer Issue: CUT-OFF-DATES
C04383 00529 ∂09-Feb-89 0537 X3J13-mailer Issue: ERROR-TERMINOLOGY
C04401 00530 ∂09-Feb-89 0928 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C04404 00531 ∂09-Feb-89 1008 X3J13-mailer Issue: ERROR-TERMINOLOGY
C04409 00532 ∂09-Feb-89 0959 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C04415 00533 ∂09-Feb-89 1059 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C04418 00534 ∂14-Feb-89 0922 X3J13-mailer X3J13/ISO overlap
C04420 00535 ∂14-Feb-89 1226 X3J13-mailer Copying and Equality paper
C04422 00536 ∂20-Feb-89 0129 X3J13-mailer Issue: SUBSETTING-POSITION
C04432 00537 ∂20-Feb-89 1255 X3J13-mailer Re: Issue: SUBSETTING-POSITION
C04436 00538 ∂20-Feb-89 1406 X3J13-mailer Issue: CONFORMANCE-POSITION
C04443 00539 ∂21-Feb-89 0638 X3J13-mailer Updated version of standard available
C04452 00540 ∂21-Feb-89 2149 X3J13-mailer Source for section 1.8
C04455 00541 ∂21-Feb-89 2155 X3J13-mailer Issue: FONTS
C04459 00542 ∂21-Feb-89 2151 X3J13-mailer Feb. 21 Letter Ballot
C04466 00543 ∂21-Feb-89 2153 X3J13-mailer Issue: TOC
C04477 00544 ∂21-Feb-89 2149 X3J13-mailer Source for section 2.4
C04498 00545 ∂21-Feb-89 2201 X3J13-mailer Issue: CUT-OFF-DATES
C04518 00546 ∂21-Feb-89 2201 X3J13-mailer Issue: ERROR-TERMINOLOGY
C04540 00547 ∂21-Feb-89 2150 X3J13-mailer Source for section 6.1
C04561 00548 ∂21-Feb-89 2208 X3J13-mailer Source for section 2.5
C04624 00549 ∂21-Feb-89 2209 X3J13-mailer Source for section 2.3
C04687 00550 ∂22-Feb-89 1338 X3J13-mailer cs proposal part 2 of 3
C04728 00551 ∂22-Feb-89 1337 X3J13-mailer cs proposal part1 of 3
C04778 00552 ∂22-Feb-89 1336 X3J13-mailer recent sent to wrong mailing list
C04836 00553 ∂22-Feb-89 1339 X3J13-mailer cs proposal part 3 of 3
C04884 00554 ∂22-Feb-89 1630 X3J13-mailer cs proposal part 3 of 3
C04886 00555 ∂22-Feb-89 1707 X3J13-mailer Re: cs proposal part 3 of 3
C04888 00556 ∂22-Feb-89 1714 X3J13-mailer cs proposal
C04889 00557 ∂22-Feb-89 1713 X3J13-mailer cs proposal straw vote
C04897 00558 ∂22-Feb-89 1713 X3J13-mailer cs proposal errata
C04899 00559 ∂24-Feb-89 1437 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C04902 00560 ∂24-Feb-89 1426 X3J13-mailer Issue: EXTENTIONS-POSITION
C04909 00561 ∂24-Feb-89 1439 X3J13-mailer Issue: MACRO-AS-FUNCTION
C04913 00562 ∂24-Feb-89 1439 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C04917 00563 ∂24-Feb-89 1439 X3J13-mailer Issue: UNSPECIFIED-DATATYPES
C04922 00564 ∂27-Feb-89 0217 X3J13-mailer Issue: EXTRA-SYNTAX
C04925 00565 ∂27-Feb-89 0218 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
C04930 00566 ∂27-Feb-89 0255 X3J13-mailer Review schedule reminder
C04934 00567 ∂27-Feb-89 1101 X3J13-mailer characters and conformance
C04937 00568 ∂28-Feb-89 0956 X3J13-mailer agenda items, registration
C04942 00569 ∂28-Feb-89 1347 X3J13-mailer cs proposal
C04943 00570 ∂01-Mar-89 1109 X3J13-mailer Section 1.7
C04952 00571 ∂01-Mar-89 1111 X3J13-mailer Section 5.2
C04967 00572 ∂01-Mar-89 1136 X3J13-mailer Section 1.5
C04974 00573 ∂01-Mar-89 1159 X3J13-mailer New versions of standard files available
C04977 00574 ∂01-Mar-89 1203 X3J13-mailer Section 1.3
C04981 00575 ∂01-Mar-89 1138 X3J13-mailer Section 1.6
C05016 00576 ∂01-Mar-89 1207 X3J13-mailer Section 2.1
C05022 00577 ∂01-Mar-89 1232 X3J13-mailer Section 1.2
C05024 00578 ∂01-Mar-89 1232 X3J13-mailer Section 1.1
C05035 00579 ∂01-Mar-89 1234 X3J13-mailer Section 1.4
C05041 00580 ∂01-Mar-89 1240 X3J13-mailer Section 5.3
C05054 00581 ∂01-Mar-89 1243 X3J13-mailer Section 5.4
C05073 00582 ∂01-Mar-89 1305 X3J13-mailer Section 1.7
C05077 00583 ∂01-Mar-89 1257 X3J13-mailer cs proposal and straw vote
C05090 00584 ∂01-Mar-89 1335 X3J13-mailer Re: Section 1.7
C05093 00585 ∂01-Mar-89 1526 X3J13-mailer minor comments on letter ballot material
C05101 00586 ∂01-Mar-89 1853 X3J13-mailer Re: minor comments on letter ballot material
C05105 00587 ∂01-Mar-89 2340 X3J13-mailer Section 2.2, part 1
C05145 00588 ∂02-Mar-89 0008 X3J13-mailer Section 2.2 - part 3
C05162 00589 ∂01-Mar-89 2355 X3J13-mailer Section 2.2 - part 2
C05199 00590 ∂02-Mar-89 0834 X3J13-mailer Section 2.2 - part 4
C05223 00591 ∂02-Mar-89 0930 X3J13-mailer cs proposal comments
C05224 00592 ∂02-Mar-89 0928 X3J13-mailer forwarding note from gregor from larry
C05234 00593 ∂02-Mar-89 0928 X3J13-mailer forwarding mail from gray
C05245 00594 ∂02-Mar-89 0929 X3J13-mailer cs proposal comments
C05256 00595 ∂02-Mar-89 1000 X3J13-mailer Re: cs proposal and straw vote
C05261 00596 ∂02-Mar-89 0905 X3J13-mailer Section 2.2 - part 5
C05342 00597 ∂02-Mar-89 1151 X3J13-mailer Re: cs proposal comments
C05345 00598 ∂02-Mar-89 1632 X3J13-mailer minor comments on the character proposal
C05349 00599 ∂02-Mar-89 1909 X3J13-mailer cs proposal and straw vote
C05354 00600 ∂02-Mar-89 1929 X3J13-mailer answer to request for comments on comments on comments on characters
C05365 00601 ∂02-Mar-89 1941 CL-Characters-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
C05368 00602 ∂03-Mar-89 0004 X3J13-mailer cs comments
C05373 00603 ∂03-Mar-89 0913 X3J13-mailer cs comments
C05380 00604 ∂03-Mar-89 1006 X3J13-mailer Issue: ERROR-TERMINOLOGY
C05392 00605 ∂03-Mar-89 1130 X3J13-mailer Re: Section 1.7
C05394 00606 ∂03-Mar-89 1202 X3J13-mailer Common Lisp
C05397 00607 ∂03-Mar-89 1221 X3J13-mailer KMP's personal comments on 22-Feb-89 Character Proposal
C05421 00608 ∂03-Mar-89 1427 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C05425 00609 ∂03-Mar-89 1539 X3J13-mailer What is a FUNCTION?
C05429 00610 ∂03-Mar-89 1548 X3J13-mailer Error Terminology
C05437 00611 ∂03-Mar-89 1632 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C05441 00612 ∂03-Mar-89 1704 X3J13-mailer Issue: ERROR-TERMINOLOGY
C05443 00613 ∂04-Mar-89 1159 X3J13-mailer Error Terminology
C05445 00614 ∂06-Mar-89 1133 X3J13-mailer Re: KMP's personal comments on 22-Feb-89 Character Proposal
C05447 00615 ∂06-Mar-89 1322 X3J13-mailer Re: minor comments on letter ballot material
C05451 00616 ∂06-Mar-89 1348 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
C05457 00617 ∂06-Mar-89 1355 X3J13-mailer minor comments on letter ballot material
C05460 00618 ∂06-Mar-89 1453 X3J13-mailer Re: cs proposal comments
C05465 00619 ∂06-Mar-89 1449 X3J13-mailer Re: cs proposal and straw vote
C05471 00620 ∂06-Mar-89 1538 X3J13-mailer Re: cs proposal and straw vote
C05474 00621 ∂06-Mar-89 1627 X3J13-mailer cs proposal straw vote
C05486 00622 ∂06-Mar-89 1714 X3J13-mailer Review schedule reminder
C05488 00623 ∂07-Mar-89 0254 X3J13-mailer clarification
C05491 00624 ∂07-Mar-89 1334 X3J13-mailer hotel for march meeting
C05492 00625 ∂07-Mar-89 1403 X3J13-mailer Agenda DRAFT
C05495 00626 ∂07-Mar-89 1429 X3J13-mailer registration list
C05500 00627 ∂08-Mar-89 0523 X3J13-mailer Issue: PLUS-ABNORMAL
C05501 00628 ∂08-Mar-89 0520 X3J13-mailer Issue: PLUS-ABNORMAL
C05504 00629 ∂08-Mar-89 1649 X3J13-mailer February 21 Ballot
C05509 00630 ∂08-Mar-89 1741 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
C05514 00631 ∂09-Mar-89 1340 X3J13-mailer Issue: SUBSETTING-POSITION
C05516 00632 ∂09-Mar-89 1345 X3J13-mailer Issue: EXTENTIONS-POSITION
C05518 00633 ∂09-Mar-89 1349 X3J13-mailer Issue: MACRO-AS-FUNCTION
C05520 00634 ∂09-Mar-89 1350 X3J13-mailer Issue: UNSOLICITED-MESSAGES (Version 2)
C05522 00635 ∂09-Mar-89 1352 X3J13-mailer Issue: UNSPECIFIED-DATATYPES (Version 2)
C05524 00636 ∂09-Mar-89 1357 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
C05526 00637 ∂09-Mar-89 1406 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
C05530 00638 ∂09-Mar-89 1433 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
C05533 00639 ∂09-Mar-89 1539 X3J13-mailer Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
C05535 00640 ∂12-Mar-89 1616 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C05539 00641 ∂13-Mar-89 0714 X3J13-mailer cl-compiler mail
C05541 00642 ∂13-Mar-89 0747 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C05556 00643 ∂13-Mar-89 0749 X3J13-mailer issue COMPILER-VERBOSITY, version 6
C05563 00644 ∂13-Mar-89 0748 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 9
C05578 00645 ∂13-Mar-89 0815 X3J13-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
C05608 00646 ∂13-Mar-89 0821 X3J13-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
C05620 00647 ∂13-Mar-89 0824 X3J13-mailer issue CONSTANT-COLLAPSING, version 5
C05627 00648 ∂13-Mar-89 0840 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C05631 00649 ∂13-Mar-89 0834 X3J13-mailer issue LOAD-TIME-EVAL, version 11
C05657 00650 ∂13-Mar-89 0853 X3J13-mailer issue COMPILER-VERBOSITY, version 6
C05659 00651 ∂13-Mar-89 0855 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C05667 00652 ∂13-Mar-89 0853 X3J13-mailer issue MACRO-CACHING, version 2
C05685 00653 ∂13-Mar-89 0924 X3J13-mailer issue QUOTE-SEMANTICS, version 2
C05699 00654 ∂13-Mar-89 0929 X3J13-mailer issue SAFE-CODE, version 1
C05705 00655 ∂13-Mar-89 1014 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C05711 00656 ∂13-Mar-89 1046 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C05713 00657 ∂13-Mar-89 1450 X3J13-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
C05726 00658 ∂13-Mar-89 1452 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C05741 00659 ∂13-Mar-89 1514 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
C05772 00660 ∂13-Mar-89 1517 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
C05796 00661 ∂13-Mar-89 1531 X3J13-mailer **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
C05806 00662 ∂13-Mar-89 1533 X3J13-mailer issue DEFINE-OPTIMIZER, version 5
C05824 00663 ∂13-Mar-89 1536 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
C05833 00664 ∂13-Mar-89 1545 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL, version 6
C05866 00665 ∂13-Mar-89 1601 X3J13-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
C05882 00666 ∂13-Mar-89 1610 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
C05895 00667 ∂13-Mar-89 1627 X3J13-mailer issue WITH-COMPILATION-UNIT, version 3
C05905 00668 ∂13-Mar-89 1622 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C05934 00669 ∂13-Mar-89 1643 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
C05937 00670 ∂13-Mar-89 1634 X3J13-mailer summary of active cl-compiler issues
C05946 00671 ∂14-Mar-89 0938 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
C05951 00672 ∂14-Mar-89 0956 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
C05956 00673 ∂14-Mar-89 1005 CL-Compiler-mailer issue WITH-COMPILATION-UNIT, version 3
C05959 00674 ∂14-Mar-89 1217 CL-Compiler-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
C05961 00675 ∂14-Mar-89 1232 CL-Compiler-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
C05966 00676 ∂14-Mar-89 1310 CL-Compiler-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
C05970 00677 ∂14-Mar-89 1326 CL-Compiler-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
C05973 00678 ∂14-Mar-89 1340 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C05975 00679 ∂14-Mar-89 1351 CL-Compiler-mailer issue SAFE-CODE, version 1
C05977 00680 ∂14-Mar-89 1357 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
C05979 00681 ∂14-Mar-89 1419 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C05985 00682 ∂14-Mar-89 1438 CL-Compiler-mailer issue COMPILER-DIAGNOSTICS, version 9
C05989 00683 ∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C05991 00684 ∂14-Mar-89 1544 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C05998 00685 ∂14-Mar-89 1555 X3J13-mailer LETTER BALLOT -- Sun Microsystems
C06008 00686 ∂14-Mar-89 1610 X3J13-mailer Re: Issue: UNSOLICITED-MESSAGES
C06011 00687 ∂14-Mar-89 1629 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
C06020 00688 ∂14-Mar-89 1636 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
C06030 00689 ∂14-Mar-89 1651 CL-Compiler-mailer issue QUOTE-SEMANTICS, version 2
C06033 00690 ∂14-Mar-89 1700 CL-Compiler-mailer issue MACRO-CACHING, version 2
C06036 00691 ∂14-Mar-89 1704 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
C06038 00692 ∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-COLLAPSING, version 5
C06041 00693 ∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
C06043 00694 ∂14-Mar-89 1731 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C06049 00695 ∂14-Mar-89 1730 CL-Compiler-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C06052 00696 ∂14-Mar-89 1731 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C06064 00697 ∂15-Mar-89 0520 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06079 00698 ∂15-Mar-89 0622 X3J13-mailer BASE-CHARACTER
C06083 00699 ∂15-Mar-89 0636 X3J13-mailer Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
C06097 00700 ∂15-Mar-89 0924 CL-Characters-mailer BASE-CHARACTER
C06099 00701 ∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06101 00702 ∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C06103 00703 ∂15-Mar-89 1016 X3J13-mailer Issue: EXTRA-RETURN-VALUES (Version 2)
C06110 00704 ∂15-Mar-89 1018 X3J13-mailer BASE-CHARACTER
C06112 00705 ∂15-Mar-89 1227 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C06114 00706 ∂15-Mar-89 1446 X3J13-mailer Issue ERROR TERMINOLOGY
C06119 00707 ∂15-Mar-89 1451 CL-Compiler-mailer Issue SAFE-CODE, version 1
C06121 00708 ∂15-Mar-89 1506 CL-Editorial-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C06133 00709 ∂15-Mar-89 1553 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
C06136 00710 ∂15-Mar-89 1603 X3J13-mailer Feb. 21 letter ballot
C06141 00711 ∂15-Mar-89 1722 X3J13-mailer Bartley's Comments
C06142 00712 ∂15-Mar-89 1756 X3J13-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C06145 00713 ∂15-Mar-89 1853 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
C06148 00714 ∂15-Mar-89 1941 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C06152 00715 ∂16-Mar-89 0601 X3J13-mailer Re: issue COMPILER-VERBOSITY, version 6
C06155 00716 ∂16-Mar-89 0632 X3J13-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C06176 00717 ∂16-Mar-89 0713 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C06179 00718 ∂16-Mar-89 0720 X3J13-mailer Issue: LOAD-TRUENAME (Version 1)
C06188 00719 ∂16-Mar-89 0708 CL-Compiler-mailer Re: Issue SAFE-CODE, version 1
C06191 00720 ∂16-Mar-89 0719 X3J13-mailer Re: issue LOAD-TIME-EVAL, version 11
C06194 00721 ∂16-Mar-89 0831 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
C06204 00722 ∂16-Mar-89 0854 X3J13-mailer Issue: CLOS-CONDITIONS (Version 4)
C06219 00723 ∂16-Mar-89 0928 CL-Compiler-mailer Issue SAFE-CODE, version 1
C06222 00724 ∂16-Mar-89 0958 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
C06226 00725 ∂16-Mar-89 0958 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C06228 00726 ∂16-Mar-89 0957 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C06234 00727 ∂16-Mar-89 0958 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C06237 00728 ∂16-Mar-89 1040 X3J13-mailer Re: Issue ERROR TERMINOLOGY
C06240 00729 ∂16-Mar-89 1044 X3J13-mailer Issue: CLOSED-STREAM-OPERATION (Version 7)
C06248 00730 ∂16-Mar-89 1051 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C06251 00731 ∂16-Mar-89 1044 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C06263 00732 ∂16-Mar-89 1045 X3J13-mailer DRAFT Issue: CONDITION-RESTARTS (Version 1)
C06283 00733 ∂16-Mar-89 1117 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C06286 00734 ∂16-Mar-89 1146 X3J13-mailer Issue ERROR TERMINOLOGY, dpANS C
C06289 00735 ∂16-Mar-89 1205 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C06292 00736 ∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-PRINT-NAME, v.2
C06296 00737 ∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-COPY-PLIST, v.1
C06300 00738 ∂16-Mar-89 1213 X3J13-mailer
C06325 00739 ∂16-Mar-89 1212 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
C06339 00740 ∂16-Mar-89 1221 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
C06342 00741 ∂16-Mar-89 1241 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
C06346 00742 ∂16-Mar-89 1436 X3J13-mailer Fatal vesus Harmless
C06354 00743 ∂16-Mar-89 1418 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
C06358 00744 ∂16-Mar-89 1424 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C06361 00745 ∂16-Mar-89 1443 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C06364 00746 ∂16-Mar-89 1354 X3J13-mailer Issue: DYNAMIC-EXTENT
C06369 00747 ∂16-Mar-89 1356 CL-Compiler-mailer Issue SAFE-CODE, version 1
C06371 00748 ∂16-Mar-89 1551 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C06373 00749 ∂16-Mar-89 1603 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
C06375 00750 ∂16-Mar-89 1726 X3J13-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
C06379 00751 ∂16-Mar-89 1746 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C06382 00752 ∂16-Mar-89 1745 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C06385 00753 ∂16-Mar-89 1801 X3J13-mailer SYMBOL-MACROLET-SEMANTICS, version 6
C06397 00754 ∂16-Mar-89 2103 X3J13-mailer Issue: EXIT-EXTENT, v.6
C06421 00755 ∂16-Mar-89 2220 X3J13-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
C06438 00756 ∂16-Mar-89 2254 X3J13-mailer Issue: HASH-TABLE-ACCESS (version 2)
C06448 00757 ∂16-Mar-89 2244 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME, v.1
C06487 00758 ∂16-Mar-89 2334 X3J13-mailer Issue LOOP-AND-DISCREPANCY, version 1
C06493 00759 ∂16-Mar-89 2330 X3J13-mailer Issue: LOAD-OBJECTS (Version 3)
C06515 00760 ∂17-Mar-89 0009 X3J13-mailer Issue: REAL-NUMBER-TYPE (version 3)
C06527 00761 ∂17-Mar-89 0817 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C06531 00762 ∂17-Mar-89 0834 X3J13-mailer Issue: LOCALLY-TOP-LEVEL (Version 2)
C06539 00763 ∂17-Mar-89 0857 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C06541 00764 ∂17-Mar-89 0854 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C06543 00765 ∂17-Mar-89 1041 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
C06551 00766 ∂17-Mar-89 1223 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C06554 00767 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06559 00768 ∂17-Mar-89 1223 X3J13-mailer Issue ERROR TERMINOLOGY
C06565 00769 ∂17-Mar-89 1223 X3J13-mailer issue SAFE-CODE, version 1
C06567 00770 ∂17-Mar-89 1246 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
C06569 00771 ∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06572 00772 ∂17-Mar-89 1251 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C06575 00773 ∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06578 00774 ∂17-Mar-89 1316 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
C06582 00775 ∂17-Mar-89 1356 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C06585 00776 ∂17-Mar-89 1426 X3J13-mailer CLTL II
C06590 00777 ∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06594 00778 ∂17-Mar-89 1555 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C06597 00779 ∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06599 00780 ∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06602 00781 ∂17-Mar-89 1612 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C06604 00782 ∂17-Mar-89 1623 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
C06607 00783 ∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C06613 00784 ∂17-Mar-89 1758 X3J13-mailer too much mail!
C06616 00785 ∂17-Mar-89 2051 X3J13-mailer March meeting issues and sections
C06625 00786 ∂17-Mar-89 2110 X3J13-mailer Issue: EXTRA-RETURN-VALUES (version 3)
C06627 00787 ∂17-Mar-89 2304 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
C06634 00788 ∂18-Mar-89 0137 X3J13-mailer The Cleanup Issue Status List
C06667 00789 ∂20-Mar-89 0002 X3J13-mailer X3J13 mailer
C06670 00790 ∂20-Mar-89 1229 X3J13-mailer Re: Fatal vesus Harmless
C06675 00791 ∂20-Mar-89 1315 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
C06677 00792 ∂21-Mar-89 1455 X3J13-mailer Issue: COMMON-TYPE (version 1)
C06681 00793 ∂21-Mar-89 1500 X3J13-mailer Issue: HASH-TABLE-SIZE (version 1)
C06686 00794 ∂21-Mar-89 1458 X3J13-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
C06691 00795 ∂21-Mar-89 1453 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C06706 00796 ∂21-Mar-89 1629 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C06721 00797 ∂21-Mar-89 1732 CL-Compiler-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
C06725 00798 ∂21-Mar-89 2048 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C06768 00799 ∂22-Mar-89 0845 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C06770 00800 ∂22-Mar-89 0931 X3J13-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 2)
C06780 00801 ∂22-Mar-89 1401 X3J13-mailer **DRAFT** issue: PATHNAME-COMPONENT-CASE (Version 1)
C06796 00802 ∂22-Mar-89 1900 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C06815 00803 ∂22-Mar-89 2031 X3J13-mailer Issue: PATHNAME-COMPONENT-CASE (Version 2)
C06837 00804 ∂23-Mar-89 0028 X3J13-mailer 20 March cs proposal
C06841 00805 ∂23-Mar-89 0127 X3J13-mailer 20 March cs proposal part 1 of 1
C06922 00806 ∂23-Mar-89 0702 X3J13-mailer Re: 20 March cs proposal
C06924 00807 ∂23-Mar-89 0903 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C06933 00808 ∂23-Mar-89 1504 X3J13-mailer **DRAFT** Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C06947 00809 ∂23-Mar-89 1503 X3J13-mailer **DRAFT** Issue: PATHNAME-EXTENSIONS (Version 1)
C06961 00810 ∂23-Mar-89 1503 X3J13-mailer issue CLOS-MACRO-COMPILATION, version 3
C06974 00811 ∂23-Mar-89 1504 X3J13-mailer Issue: PATHNAME-WILD (Version 2)
C06983 00812 ∂23-Mar-89 1503 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 5
C06998 00813 ∂23-Mar-89 1503 X3J13-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED, v.6
C07018 00814 ∂23-Mar-89 1504 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 10
C07036 00815 ∂23-Mar-89 1503 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 5
C07053 00816 ∂23-Mar-89 1512 X3J13-mailer issue COMPILER-LET-CONFUSION, version 8
C07081 00817 ∂23-Mar-89 1523 X3J13-mailer issue CONSTANT-COLLAPSING, version 6
C07090 00818 ∂23-Mar-89 1521 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 9
C07102 00819 ∂23-Mar-89 1522 X3J13-mailer issue QUOTE-SEMANTICS, version 3
C07119 00820 ∂23-Mar-89 1523 X3J13-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 8
C07133 00821 ∂23-Mar-89 1537 X3J13-mailer **DRAFT** Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C07150 00822 ∂23-Mar-89 1552 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C07153 00823 ∂23-Mar-89 1527 X3J13-mailer issue DEFINE-OPTIMIZER, version 6
C07178 00824 ∂23-Mar-89 1552 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C07184 00825 ∂23-Mar-89 1526 X3J13-mailer issue CONSTANT-COMPILABLE-TYPES, version 9
C07208 00826 ∂23-Mar-89 1526 X3J13-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 6
C07240 00827 ∂23-Mar-89 1527 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL, version 7
C07275 00828 ∂23-Mar-89 1538 CL-Cleanup-mailer The Revised Cleanup Issue Status List
C07309 00829 ∂23-Mar-89 1657 X3J13-mailer cl-compiler issue status as of Mar 23
C07320 00830 ∂23-Mar-89 1656 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C07335 00831 ∂23-Mar-89 2100 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 3)
C07344 00832 ∂23-Mar-89 2059 X3J13-mailer **DRAFT** Issue: PATHNAME-PRINT-READ (Version 1)
C07352 00833 ∂23-Mar-89 2059 X3J13-mailer **DRAFT** Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
C07368 00834 ∂24-Mar-89 0824 X3J13-mailer Re: 20 March cs proposal
C07377 00835 ∂24-Mar-89 1457 X3J13-mailer **DRAFT** Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C07379 00836 ∂25-Mar-89 2231 X3J13-mailer **DRAFT** Issue: READ-CASE-SENSITIVITY (Version 2)
C07396 00837 ∂25-Mar-89 2239 X3J13-mailer **DRAFT** Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER (Version 1)
C07427 00838 ∂26-Mar-89 2005 X3J13-mailer **DRAFT** Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
C07440 00839 ∂26-Mar-89 2146 CL-Characters-mailer Really about TYPEP failures
C07444 00840 ∂03-Apr-89 1231 X3J13-mailer compiler issues
C07449 00841 ∂06-Apr-89 1220 X3J13-mailer June 26 - 28 meeting, Palo Alto, CA
C07453 00842 ∂06-Apr-89 1256 X3J13-mailer editorial issues summary
C07455 00843 ∂06-Apr-89 1307 X3J13-mailer addition to editorial issues summary
C07457 00844 ∂06-Apr-89 1305 X3J13-mailer Issue: ERROR-TERMINOLOGY (Version 8)
C07477 00845 ∂06-Apr-89 1316 X3J13-mailer UNSOLICITED-MESSAGES (version 6)
C07482 00846 ∂07-Apr-89 1102 X3J13-mailer Did you blow it?
C07487 00847 ∂07-Apr-89 1420 X3J13-mailer Did you blow it?
C07496 00848 ∂08-Apr-89 1627 X3J13-mailer Did you blow it?
C07499 00849 ∂09-Apr-89 2059 X3J13-mailer Issue: DEFMACRO-LAMBDA-LIST, v3
C07509 00850 ∂12-Apr-89 2156 X3J13-mailer Line Trouble
C07512 00851 ∂17-Apr-89 0933 X3J13-mailer Issue STREAM-DEFINITION-BY-USER (V1)
C07555 00852 ∂18-Apr-89 2212 X3J13-mailer Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
C07575 00853 ∂25-May-89 0020 X3J13-mailer Letter ballot status
C07578 00854 ∂25-May-89 0047 X3J13-mailer CONFORMANCE-POSITION
C07591 00855 ∂25-May-89 1039 X3J13-mailer Re: CONFORMANCE-POSITION
C07594 00856 ∂25-May-89 1247 X3J13-mailer CONFORMANCE-POSITION
C07599 00857 ∂26-May-89 0901 X3J13-mailer Windows Standards Discussion at 6/26 Palo Alto Meeting
C07602 00858 ∂26-May-89 1058 X3J13-mailer CONFORMANCE-POSITION
C07604 00859 ∂26-May-89 1418 X3J13-mailer Re: CONFORMANCE-POSITION
C07606 00860 ∂29-May-89 1324 X3J13-mailer two things
C07608 00861 ∂30-May-89 0821 X3J13-mailer two things
C07612 00862 ∂30-May-89 0913 X3J13-mailer CONFORMANCE-POSITION
C07614 00863 ∂31-May-89 0703 X3J13-mailer the standard and FTP
C07616 00864 ∂31-May-89 1530 X3J13-mailer June meeting registration form
C07620 00865 ∂31-May-89 1533 X3J13-mailer agenda items please
C07622 00866 ∂01-Jun-89 1214 X3J13-mailer re: two things
C07625 00867 ∂02-Jun-89 1725 X3J13-mailer New submission address for LASC
C07629 00868 ∂12-Jun-89 0424 X3J13-mailer Issue: CONFORMANCE-POSITION
C07642 00869 ∂12-Jun-89 0452 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C07647 00870 ∂12-Jun-89 0755 X3J13-mailer Agenda item: Series and Generators
C07651 00871 ∂13-Jun-89 1559 X3J13-mailer Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)
C07691 00872 ∂13-Jun-89 1615 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C07710 00873 ∂15-Jun-89 0824 X3J13-mailer issue CLOS-MACRO-COMPILATION, version 4
C07722 00874 ∂15-Jun-89 0908 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6
C07742 00875 ∂15-Jun-89 0918 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 6
C07757 00876 ∂15-Jun-89 0921 X3J13-mailer issue MACRO-CACHING, version 3
C07767 00877 ∂15-Jun-89 0913 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 4
C07785 00878 ∂15-Jun-89 0948 X3J13-mailer cl-compiler issue status
C07788 00879 ∂16-Jun-89 2126 X3J13-mailer Issue: PATHNAME-SYSTEM-TYPE (version 2)
C07795 00880 ∂16-Jun-89 2153 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 3)
C07815 00881 ∂16-Jun-89 2225 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 7)
C07839 00882 ∂16-Jun-89 2239 X3J13-mailer Issue: PATHNAME-COMPONENT-CASE (version 5)
C07855 00883 ∂19-Jun-89 0847 X3J13-mailer Issue: DATA-IO (version 7)
C07873 00884 ∂19-Jun-89 0851 X3J13-mailer Issue: FLOAT-UNDERFLOW (version 3)
C07885 00885 ∂19-Jun-89 0914 X3J13-mailer Issue: MAP-INTO (version 2)
C07891 00886 ∂19-Jun-89 0911 X3J13-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
C07912 00887 ∂19-Jun-89 0916 X3J13-mailer Issue: STRING-COERCION (Version 2)
C07919 00888 ∂19-Jun-89 0922 X3J13-mailer Issue: STREAM-CAPABILITIES (version 3)
C07927 00889 ∂19-Jun-89 1055 X3J13-mailer Issue: CONFORMANCE-POSITION (version 9)
C07929 00890 ∂19-Jun-89 1546 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C07932 00891 ∂19-Jun-89 1545 X3J13-mailer Issue: PATHNAME-WILD (version 6)
C07961 00892 ∂19-Jun-89 1721 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
C07964 00893 ∂19-Jun-89 1845 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C07966 00894 ∂19-Jun-89 2112 X3J13-mailer June Agenda DRAFT
C07969 00895 ∂19-Jun-89 2113 X3J13-mailer registration list
C07973 00896 ∂20-Jun-89 0753 X3J13-mailer June Agenda DRAFT
C07975 00897 ∂20-Jun-89 0845 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C07978 00898 ∂20-Jun-89 0901 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C07980 00899 ∂20-Jun-89 1252 X3J13-mailer EXTRA-RETURN-VALUES
C07985 00900 ∂20-Jun-89 1307 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C07993 00901 ∂20-Jun-89 1336 X3J13-mailer Issue: EXTRA-RETURN-VALUES (version 5)
C07995 00902 ∂20-Jun-89 1823 X3J13-mailer June Agenda DRAFT
C07997 00903 ∂20-Jun-89 2235 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C08004 00904 ∂21-Jun-89 1035 X3J13-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
C08015 00905 ∂21-Jun-89 1042 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
C08039 00906 ∂21-Jun-89 1059 X3J13-mailer Issue: PATHNAME-WILD (version 5)
C08060 00907 ∂21-Jun-89 1129 X3J13-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
C08069 00908 ∂21-Jun-89 1506 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C08074 00909 ∂21-Jun-89 1507 X3J13-mailer Issue: PATHNAME-LOGICAL (version 3)
C08130 00910 ∂21-Jun-89 1550 X3J13-mailer Issue: PATHNAME-WILD (version 5)
C08132 00911 ∂21-Jun-89 1550 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
C08134 00912 ∂21-Jun-89 1827 X3J13-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
C08136 00913 ∂22-Jun-89 0528 X3J13-mailer csprop
C08138 00914 ∂22-Jun-89 0553 X3J13-mailer csprop
C08220 00915 ∂22-Jun-89 0723 X3J13-mailer Re: csprop
C08222 00916 ∂22-Jun-89 1217 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C08234 00917 ∂22-Jun-89 1218 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.6
C08247 00918 ∂22-Jun-89 1251 X3J13-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 10
C08294 00919 ∂22-Jun-89 1408 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 7
C08313 00920 ∂22-Jun-89 1422 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 13
C08334 00921 ∂22-Jun-89 1524 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C08339 00922 ∂22-Jun-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C08345 00923 ∂22-Jun-89 1620 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C08352 00924 ∂22-Jun-89 1650 X3J13-mailer No content change. Fixed ugly printing of sec 2.6
C08433 00925 ∂23-Jun-89 0642 X3J13-mailer June meeting registration list
C08437 00926 ∂23-Jun-89 0645 X3J13-mailer Agenda DRAFT
C08440 00927 ∂23-Jun-89 1048 X3J13-mailer Amendments
C08442 00928 ∂23-Jun-89 1049 X3J13-mailer Issue: DATA-IO (version 8)
C08462 00929 ∂23-Jun-89 1050 X3J13-mailer Issue: MAP-INTO (version 3)
C08469 00930 ∂23-Jun-89 1049 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 11)
C08489 00931 ∂23-Jun-89 1052 X3J13-mailer Issue: PATHNAME-WILD (version 7)
C08517 00932 ∂23-Jun-89 1051 X3J13-mailer Issue: PATHNAME-LOGICAL (version 4)
C08571 00933 ∂23-Jun-89 1234 X3J13-mailer issue CLOS-MACRO-COMPILATION, version 5
C08583 00934 ∂25-Jun-89 0755 X3J13-mailer registration list update
C08587 00935 ∂29-Jun-89 2133 X3J13-mailer Top 10
C08591 00936 ∂04-Jul-89 0825 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 5
C08610 00937 ∂04-Jul-89 0839 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 8
C08627 00938 ∂04-Jul-89 0925 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 14
C08642 00939 ∂04-Jul-89 0931 X3J13-mailer issue PROCLAIM-ETC-IN-COMPILE-FILE, version 5
C08651 00940 ∂04-Jul-89 1005 X3J13-mailer passed cl-compiler issues
C08653 00941 ∂04-Jul-89 0954 X3J13-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 11
C08699 00942 ∂04-Jul-89 2123 X3J13-mailer Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
C08707 00943 ∂05-Jul-89 0027 X3J13-mailer Re: Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
C08712 00944 ∂05-Jul-89 0206 X3J13-mailer call for participation
C08715 00945 ∂05-Jul-89 1331 X3J13-mailer Re: Portability?
C08724 00946 ∂07-Jul-89 0046 X3J13-mailer Portability?
C08726 00947 ∂11-Jul-89 1302 X3J13-mailer issue DEFINE-COMPILER-MACRO
C08729 00948 ∂11-Jul-89 1716 X3J13-mailer issue DEFINE-COMPILER-MACRO
C08734 00949 ∂11-Jul-89 1827 X3J13-mailer issue DEFINE-COMPILER-MACRO
C08740 00950 ∂11-Jul-89 2006 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
C08745 00951 ∂12-Jul-89 0023 X3J13-mailer passed cl-compiler issues
C08747 00952 ∂12-Jul-89 0944 X3J13-mailer re: issue DEFINE-COMPILER-MACRO
C08749 00953 ∂12-Jul-89 0919 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 2
C08762 00954 ∂12-Jul-89 1003 X3J13-mailer re: issue DEFINE-COMPILER-MACRO, version 2
C08764 00955 ∂12-Jul-89 1024 X3J13-mailer re: issue DEFINE-COMPILER-MACRO, version 2
C08767 00956 ∂12-Jul-89 1359 X3J13-mailer issue DEFINE-COMPILER-MACRO
C08783 00957 ∂12-Jul-89 1435 X3J13-mailer issue DEFINE-COMPILER-MACRO
C08786 00958 ∂12-Jul-89 1459 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
C08790 00959 ∂12-Jul-89 1550 X3J13-mailer passed cl-compiler issues
C08792 00960 ∂13-Jul-89 0757 X3J13-mailer re: issue DEFINE-COMPILER-MACRO
C08794 00961 ∂13-Jul-89 0903 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
C08799 00962 ∂13-Jul-89 0958 X3J13-mailer issue DEFINE-COMPILER-MACRO
C08801 00963 ∂13-Jul-89 1030 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
C08807 00964 ∂13-Jul-89 1224 CL-Cleanup-mailer issue DEFINE-COMPILER-MACRO
C08815 00965 ∂13-Jul-89 1539 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
C08818 00966 ∂13-Jul-89 2013 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
C08820 00967 ∂14-Jul-89 1202 X3J13-mailer minutes? dates?
C08821 00968 ∂16-Jul-89 1227 X3J13-mailer minutes? dates?
C08823 00969 ∂17-Jul-89 0621 X3J13-mailer Re: minutes? dates?
C08825 00970 ∂17-Jul-89 0709 X3J13-mailer Re: minutes? dates?
C08828 00971 ∂17-Jul-89 1002 X3J13-mailer Re: minutes? dates?
C08830 00972 ∂28-Jul-89 1710 X3J13-mailer cs proposal
C08911 00973 ∂07-Aug-89 0925 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
C08914 00974 ∂07-Aug-89 1000 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
C08916 00975 ∂07-Aug-89 1218 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
C08918 00976 ∂07-Aug-89 1253 X3J13-mailer Re: support for PRETTY-PRINT-INTERFACE:XP version 5
C08920 00977 ∂07-Aug-89 1358 X3J13-mailer Support for PRETTY-PRINT-INTERFACE:XP version 5
C08922 00978 ∂08-Aug-89 0016 X3J13-mailer Re: support for PRETTY-PRINT-INTERFACE:XP version 5
C08924 00979 ∂08-Aug-89 2110 X3J13-mailer ANSI ANTICS REVISITED
C08931 00980 ∂11-Aug-89 1025 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
C08933 00981 ∂14-Aug-89 0714 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5
C08974 00982 ∂14-Aug-89 0717 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5
C09052 00983 ∂14-Aug-89 1013 CL-Error-Handling-mailer Answers to common administrative questions about CL error handling
C09058 00984 ∂16-Aug-89 2001 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5, part 1
C09099 00985 ∂16-Aug-89 2002 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5, part 2
C09176 00986 ∂17-Aug-89 1307 X3J13-mailer In case you hadn't heard...
C09178 00987 ∂28-Aug-89 0805 X3J13-mailer Organizing ANSI Common Lisp
C09181 00988 ∂12-Sep-89 1505 X3J13-mailer November X3J13 meeting
C09182 00989 ∂19-Sep-89 1435 X3J13-mailer November meeting (again)
C09184 00990 ∂19-Sep-89 1848 X3J13-mailer latest draft
C09187 00991 ∂20-Sep-89 0826 CL-Cleanup-mailer Issue COMPLEX-ATANH-BOGUS-FORMULA
C09196 00992 ∂25-Sep-89 1304 X3J13-mailer Other things we might want to clean up
C09203 00993 ∂25-Sep-89 1319 X3J13-mailer Other things we might want to clean up
C09206 00994 ∂25-Sep-89 1329 X3J13-mailer Other things we might want to clean up
C09209 00995 ∂25-Sep-89 1341 X3J13-mailer Other things we might want to clean up
C09214 00996 ∂25-Sep-89 1515 X3J13-mailer Time functions
C09215 00997 ∂25-Sep-89 1722 X3J13-mailer Time functions
C09217 00998 ∂26-Sep-89 1230 X3J13-mailer November X3J13 meeting, Palo Alto
C09221 00999 ∂26-Sep-89 1310 X3J13-mailer November X3J13 meeting, Palo Alto
C09223 01000 ∂26-Sep-89 2054 X3J13-mailer function and generic-function
C09227 01001 ∂27-Sep-89 1718 X3J13-mailer Other things we might want to clean up
C09229 01002 ∂29-Sep-89 1526 X3J13-mailer November X3J13 meeting, Palo Alto
C09231 01003 ∂04-Oct-89 2059 X3J13-mailer Other things we might want to clean up
C09235 01004 ∂04-Oct-89 2138 X3J13-mailer Other things we might want to clean up
C09238 01005 ∂04-Oct-89 2211 X3J13-mailer Character proposal
C09240 01006 ∂05-Oct-89 0703 X3J13-mailer Other things we might want to clean up
C09243 01007 ∂05-Oct-89 1008 X3J13-mailer Re: Character proposal
C09245 01008 ∂06-Oct-89 1808 X3J13-mailer character proposal
C09246 01009 ∂07-Oct-89 1453 X3J13-mailer 2 week rule and agenda items
C09248 01010 ∂08-Oct-89 1407 X3J13-mailer more cleanups
C09265 01011 ∂08-Oct-89 1846 X3J13-mailer more cleanups
C09279 01012 ∂08-Oct-89 1922 X3J13-mailer Sins of omission
C09282 01013 ∂09-Oct-89 1022 X3J13-mailer issue EVALHOOK-STEP-CONFUSION
C09289 01014 ∂09-Oct-89 1156 X3J13-mailer Re: issue EVALHOOK-STEP-CONFUSION
C09291 01015 ∂09-Oct-89 1545 X3J13-mailer re: more cleanups
C09301 01016 ∂09-Oct-89 1627 X3J13-mailer re: more cleanups
C09305 01017 ∂09-Oct-89 2101 X3J13-mailer re: more cleanups
C09310 01018 ∂10-Oct-89 1146 X3J13-mailer re: more cleanups
C09316 01019 ∂10-Oct-89 1215 X3J13-mailer November Attendee List
C09320 01020 ∂10-Oct-89 1810 X3J13-mailer Sins of omission
C09324 01021 ∂11-Oct-89 1035 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
C09337 01022 ∂11-Oct-89 1403 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-OPTIONS
C09343 01023 ∂11-Oct-89 1547 X3J13-mailer issue DEFSTRUCT-SYNTAX-ERRORS
C09352 01024 ∂12-Oct-89 0625 X3J13-mailer more cleanups
C09357 01025 ∂12-Oct-89 0740 X3J13-mailer Re: more cleanups
C09362 01026 ∂12-Oct-89 1106 X3J13-mailer more cleanups
C09364 01027 ∂12-Oct-89 1203 X3J13-mailer more cleanups
C09366 01028 ∂13-Oct-89 0048 X3J13-mailer completeness of the draft
C09369 01029 ∂13-Oct-89 0059 X3J13-mailer Issues COMPILER-VERBOSITY, LOAD-TRUENAME
C09371 01030 ∂13-Oct-89 0951 X3J13-mailer Issues COMPILER-VERBOSITY, LOAD-TRUENAME
C09373 01031 ∂13-Oct-89 1033 X3J13-mailer Re: Issues COMPILER-VERBOSITY, LOAD-TRUENAME
C09375 01032 ∂13-Oct-89 1222 X3J13-mailer Issues COMPILER-VERBOSITY, LOAD-TRUENAME
C09378 01033 ∂15-Oct-89 0954 X3J13-mailer more standards
C09379 01034 ∂16-Oct-89 0950 X3J13-mailer re: more cleanups
C09380 01035 ∂16-Oct-89 0943 X3J13-mailer re: more cleanups
C09383 01036 ∂16-Oct-89 0950 X3J13-mailer more cleanups
C09388 01037 ∂16-Oct-89 0956 X3J13-mailer more cleanups
C09391 01038 ∂16-Oct-89 1003 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
C09395 01039 ∂16-Oct-89 1631 X3J13-mailer more cleanups
C09399 01040 ∂17-Oct-89 0040 X3J13-mailer more cleanups
C09403 01041 ∂17-Oct-89 1053 X3J13-mailer more cleanups
C09408 01042 ∂19-Oct-89 0822 X3J13-mailer November X3J13 meeting, Palo Alto
C09412 01043 ∂19-Oct-89 0836 X3J13-mailer November meeting (Shake, Rattle and Roll!)
C09417 01044 ∂22-Oct-89 2254 X3J13-mailer Report on WG16 Meeting
C09424 01045 ∂23-Oct-89 0735 X3J13-mailer Report on WG16 Meeting
C09427 01046 ∂23-Oct-89 0836 X3J13-mailer re: Report on WG16 Meeting
C09429 01047 ∂23-Oct-89 0822 X3J13-mailer WG16 and subsets
C09438 01048 ∂23-Oct-89 0946 X3J13-mailer WG16 and subsets
C09442 01049 ∂23-Oct-89 1019 X3J13-mailer re: Report on WG16 Meeting
C09446 01050 ∂23-Oct-89 1105 X3J13-mailer Re: Report on WG16 Meeting
C09459 01051 ∂23-Oct-89 1223 X3J13-mailer Re: Report on WG16 Meeting
C09464 01052 ∂23-Oct-89 1240 X3J13-mailer re: Report on WG16 Meeting
C09467 01053 ∂23-Oct-89 1255 X3J13-mailer Re: WG16 and subsets
C09473 01054 ∂23-Oct-89 1530 X3J13-mailer issue READER-ERROR
C09478 01055 ∂23-Oct-89 1542 X3J13-mailer issue INSPECT-RETURN-VALUE
C09485 01056 ∂23-Oct-89 1750 X3J13-mailer Re: Report on WG16 Meeting
C09490 01057 ∂23-Oct-89 1824 X3J13-mailer issue READER-ERROR
C09493 01058 ∂23-Oct-89 1835 X3J13-mailer issue INSPECT-RETURN-VALUE
C09496 01059 ∂23-Oct-89 2115 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-OPTIONS
C09498 01060 ∂24-Oct-89 0725 X3J13-mailer November Attendee List
C09500 01061 ∂24-Oct-89 0925 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
C09506 01062 ∂24-Oct-89 0955 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
C09508 01063 ∂24-Oct-89 1036 X3J13-mailer issue &ENVIRONMENT-BINDING-ORDER
C09514 01064 ∂24-Oct-89 1221 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
C09516 01065 ∂24-Oct-89 1250 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 3
C09535 01066 ∂24-Oct-89 1638 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 3
C09541 01067 ∂24-Oct-89 2110 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
C09544 01068 ∂25-Oct-89 0351 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
C09546 01069 ∂25-Oct-89 0539 X3J13-mailer issue INSPECT-RETURN-VALUE
C09548 01070 ∂25-Oct-89 0702 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
C09550 ENDMK
C⊗;
∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 86 06:15:52 PDT
Date: Thu, 9 Oct 86 09:14:26 edt
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8610091314.AA20136@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: common-lisp-request@su-ai.ARPA, mathis@b.isi.edu, rpg@sail.stanford.edu,
x3j13@sail.stanford.edu
Subject: ANSI X3J13 committee
Cc: jjohnson@mitre.ARPA
Greetings to all recipients of this message. I would appreciate your including
me on any correspondence concerning the standardization of Common Lisp within
ANSI and any other countries contributions to this ISO effort since I
am MITRE's representative on the X3J13 committee.
Sincerely,
Jerry Johnson
MITRE Corporation
AI Center
Mail Stop W418
1820 Dolley Madison Blvd
McLean, VA 22102
703-883-7173
∂09-Oct-86 1136 RPG Greetings
To: x3j13@SAIL.STANFORD.EDU
I am sending this message to reassure you that the X3J13
mailing list exists. The net address is:
x3j13@sail.stanford.edu
and the request address is
x3j13-request@sail.stanford.edu
-rpg-
∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Oct 86 15:47:04 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 6231; Fri 10-Oct-86 18:44:00 EDT
Date: Fri, 10 Oct 86 18:44 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Meeting conflict
To: x3j13@SAIL.STANFORD.EDU
cc: Hewitt@XX.LCS.MIT.EDU
Message-ID: <861010184419.6.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Folks,
I will be able to attend the next meeting on December 10 and 11 but not Dec.
12 because I have two scheduling conflicts on the 12th (it's my birthday and I
have to be present at another conflicting meeting on Friday the 12th).
--Carl
∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 06:53:28 PST
Date: 27 Oct 1986 06:30-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: X3J13 Meeting Dallas Dec 10-12
From: MATHIS@ADA20.ISI.EDU
To: X3J13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]27-Oct-86 06:30:46.MATHIS>
The second meeting of X3J13 will be held from 1pm, Wednesday,
December 10, 1986, until noon, Friday, December 12, 1986, at the
Sheraton Park Central in Dallas, Texas. Arrangements have been
made by Ellen Waldrum of Texas Instruments.
Many aspects of these early meetings are attempts to determine
the best things for this committee. There was some feeling that
this three day format was better than a two day format from both
travel and work perspectives. Having the meeting in a hotel makes
somethings easier, but it also makes the meal service more
expensive. TI graciously offered to help offset some of these
costs, but I thought that was the wrong precedent to be setting.
At the first meeting, it seemed that most people brought lunches
back to the meeting room so they could keep discussing various
issues; that is why we arranged a lunch for Thursday. At every
other TI sponsored meeting I have ever attended (once before)
there was an informal dinner (everyone ordering from the menu and
paying their own) at the Trail Dust (which is good and very
informal). We could make these arrangements for Wednesday night.
All of these food arrangements are optional.
Other aspects of the meeting (agenda, discussion papers, etc.)
will be covered in subsequent messages. -- Bob Mathis
The following is from Ellen Waldrum:
X3J13 December Meeting Registration Form; mail to:
Beverly Williams
Texas Instruments
P.O. Box 655474
MS 3651
Dallas, Texas 75265
A block of rooms is available at the Sheraton Park Central. The
rate will be $60 a night (plus tax). Please check the
appropriate dates and supply a credit card number if you wish to
have the room guaranteed. Coffee, juice, breakfast rolls, and
fruit will be available for the morning sessions and coffee and
soft drinks will be available for the afternoon sessions. Lunch
has been arranged for the Dec. 11 meeting. The cost per person
for this food service is $25. Please include a check for this
amount with the registration form if you wish to partake. Delta
Airlines has agreed to give participants a 40% discount.
Unfortunately, the reference number needed for reservations is
not available yet. It will be posted to the X3J13 mailing list
as soon as it is known. There has been some interest expressed
in having a group dinner at the Trail Dust the evening of Dec.
10 with an extra cost. If enough people want to participate,
reservations will be made. If you are interested, please note
this in the appropriate space below. If you have questions about
room or airline reservations, please call Beverly at
214-997-2108. Questions of a more general nature about the
arrangements should be directed to Ellen Waldrum at 214-995-6716
or net mail address Waldrum%TI-CSL@CSNET-RELAY.
Name:
------------------------------------------------------
Institution:
----------------------------------------------
Street Address:
--------------------------------------------
City: State: Phone:
----------------- ---- ----------------
Reservations: Dec. 9: Dec. 10: Dec. 11:
----- ----- -----
Credit Card: AE MC Visa Number:
--- --- --- ---------------------
Food Service: Yes No
--- ---
(Please make check payable to Texas Instruments)
Dinner at Trail Dust: Yes No
---- ----
The room rate is only guaranteed for reservations made before
November 17 so please mail this form as soon as possible.
∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 86 07:23:18 PST
Date: 5 Nov 1986 07:14-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 second mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Nov-86 07:14:06.MATHIS>
I just sent out in US mail the second x3j13 mailing. In it I
said you should also have seen it on this electronic address.
Due to a computer problem (which you don't want to hearabout) I
am unable to send you the total information electronically; I am
however still able to communicate somewhat on the net.
If you have anything you want sent out before the next meeting I
should have it by November 14. In this case hardcopy that I
could photocopy would be helpful.
Remember to send in your hotel reservations for the Dallas
meeting.
-- Bob
∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:55 PST
Received: from ti-csl by csnet-relay.csnet id af01601; 13 Nov 86 8:10 EST
Received: from Puff (puff.ARPA) by tilde id AA04521; Wed, 12 Nov 86 16:05:10 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: Delta reference number
Date: 12-Nov-86 15:59:39
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741205578@Puff>
I had just sent the previous message when my phone rang.
Of course it was Beverly calling with the number I had
just told you was not available yet. To take advantage
of the Delta Airlines discount, you must make your
reservations through the Delta convention desk. The
phone number is 800-241-6760 and the reference file
number is B0238. We are listed with them as the
Computer Science Show. This discount is only good for
reservations made at least seven days in advance and
there are no penalties for cancellation. If you have
any questions or problems, please call Beverly or me
or send mail (Waldrum%ti-csl@csnet-relay).
-- Ellen
∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:26 PST
Received: from ti-csl by csnet-relay.csnet id ae01601; 13 Nov 86 8:08 EST
Received: from Puff (puff.ARPA) by tilde id AA03964; Wed, 12 Nov 86 15:49:14 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: December Meeting
Date: 12-Nov-86 15:43:45
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741204624@Puff>
If you are not able to mail your form in time to meet the
November 17 deadline and wish to make a reservation, you
should call Beverly Johnson at 214-997-2108 and give her
the pertinent information. If you do call Beverly, please
send the form anyway as verification.
The Delta airlines reference number is still not available.
All of the paperwork is done but Delta has not provided this
bit of pertinent information yet. It will be posted as soon
as we get it and Beverly will be calling those of you who have
already inquired.
-- Ellen
∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Nov 86 13:02:34 PST
Received: from ti-csl by csnet-relay.csnet id ad04601; 25 Nov 86 15:42 EST
Received: from Puff (puff.ARPA) by tilde id AA23037; Tue, 25 Nov 86 13:32:15 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Reservation confirmation
Date: 25-Nov-86 13:28:28
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742319706@Puff>
I have received reservation forms from the following
people:
Beckerle, Michael Hadden, George
Boelk, Mary Haflich, Steve
Brown, Gary Hewitt, Carl
Cugini, John Kiczales, Gregor
Daniels, Andrew Loeffler, David
Dussud, Patrick Margolin, Barry
Dabrowski, Christopher Perdue, Crispin
Ennis, Susan Rand, Douglas
Fahlman, Scott Rosenking, Jeffrey
Foderaro, John Wegman, Mark
Gabriel, Richard Wieland, Alexis
The following people have made reservations by phone
but the form has not yet arrived:
Beman, Richard Moon, David
Clinger, Will Vandeusen, Mary
Goldstein, Brad Weinreb, Dan
Masinter, Larry White, Jon
If your name is not in one of these lists and you
think it should be, please let me know ASAP.
Thanks,
Ellen
Waldrum%ti-csl@csnet-relay
214-995-6716
P.S. I will have receipts for the checks available
at the meeting.
∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Nov 86 13:55:32 PST
Received: from ti-csl by csnet-relay.csnet id bz12469; 27 Nov 86 16:45 EST
Received: from Puff (puff.ARPA) by tilde id AA09163; Wed, 26 Nov 86 15:41:43 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Additional reservations
Date: 26-Nov-86 15:36:49
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742413804@Puff>
When I send the original list of reservations, a
few names were inadvertently omitted. The following
people have also made phone reservations, but the
paperwork has not yet arrived:
Antonisse, James
Bobrow, Danny
Chaihalloux, Jerome
Giansiracusa, Bob
Mathis, Bob
Ohlander, Ron
Pitman, Kent
Steele, Guy
I have received a reservation form from Mary Van Deusen.
-- Ellen
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:15 PST
Date: 5 Dec 1986 11:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting in Dallas
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:46:24.MATHIS>
I have just sent out some last minute documents. I hope that you
have all made your arrangements. Two messages follow: first is
cover letter on that mailing; second is draft agenda outline. If
you have any questions or comments, please be in touch. -- Bob
∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:34:02 PST
Date: 5 Dec 1986 12:00-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting draft agenda outline
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:00:32.MATHIS>
agenda header -- 1
1 Call to Order, December 10, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-???)
5 Report on International Activities (Doc: 86-017)
6 Other Liaison Reports
7 Review of Goals and Objectives (Doc: 86-005)
8 Brief Overview of Technical Topics on Agenda
9 Recess, 5:00pm
agenda header -- 2
10 Call to Order, December 11, 9:00am
11 Function/Value Cells (Doc: 86-010)
12 Relationship of Common Lisp and Scheme
13 European approach to defining via levels
14 LUNCH Second Day, 12:00-1:00pm
15 Error Systems (Doc: 86-011, 86-012, 86-013, 86-014)
16 Update on object system discussions (Doc: 86-018)
17 Handling technical discussions
18 Recess, 5:00pm
agenda header -- 3
19 Call to Order, December 12, 9:00am
20 Summary of Technical Issues and Discussions
21 Planning Relative to Other Technical Issues
22 Call for Officer Candidates
23 Future Meeting Schedule (Doc: SD-04)
24 Review of Action Item Assignments
25 Adjournment, 12:00noon
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:25 PST
Date: 5 Dec 1986 11:56-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: third mailing cover letter
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:56:16.MATHIS>
Doc. No.: X3J13/86-015
Date: December 1, 1986
Project: X3J13 Common Lisp
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
Ph: (703)425-5923
Mathis
X3J13 Members, alternates, observers, and potential participants:
This is a last minute reminder of the next meeting in Dallas on
December 10-12, 1986. If you have yet to make your reservations,
call Beverly at TI at (214)997-2108 or for general information,
Ellen Waldrum at (214)995-6716.
1. The minutes of first meeting have been delayed due to an
unforeseen sequence of unforeseeable circumstances which should
have been predictable. They are promised for the meeting in
Dallas.
2. Enclosed with this letter are the preliminary papers on
function cells and error systems.
3. At the ISO/TC97/SC22 Advisory Group meeting in Vienna, it was
decided to move ahead for a new work item on Lisp with a convenor
coming from France and a project editor coming from the United
States. This will be an item for discussion at the Dallas
meeting.
4. I had the opportunity to meet with Cathie Kachurik of the X3
Secretariat and Gary Robinson of DEC (who also happens to be
quite active in X3 and ISO/TC97) about the use of the Steele book
as a basis for the eventual standard. This issue was the basis
for some motions at the last meeting, which at the current time
are out of order. In our general discussions of goals and
objectives for the X3J13 committee, we need to discuss the actual
form we envision for the eventual standard and how closely it may
be related to the Steele book or to other manuals which have been
developed by other companies.
5. Remember that after this second meeting, we will have to
propose to X3 a set of officer candidates for X3J13. If anybody
wants to serve they should be prepared to make it known at this
meeting.
6. There will be a detailed proposed agenda at the start of the
meeting, but for your planning: Wednesday afternoon will include
brief overviews of the various topics on the agenda and an
extended discussion of goals and objectives for X3J13; Thursday
morning will begin with the function/value cell discussion;
Thursday afternoon will begin with the error system discussion;
and Friday morning will be devoted to finishing up remaining
topics.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Attachments:
X3J13/86-010 "Issues of Separation in Function Cells and Value
Cells" by Gabriel and Pitman with others
X3J13/86-011 "Exceptional Situations in Lisp" by Pitman
X3J13/86-012 "Error Proposal #8 as of 8/4/86" by Pitman
X3J13/86-013 "Error Proposal #8 implementation suggestion as
of 8/4/86" by Pitman
X3J13/86-014 "Error Proposal Feedback up to 11/19/86"
∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 18:25:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 5 Dec 86 21:25:36-EST
Date: Fri, 5 Dec 1986 21:25 EST
Message-ID: <FAHLMAN.12260501376.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SU-AI.ARPA
Subject: Logisitcs for Dallas meeting
I have a couple of questions about local arrangements for the Dallas
meeting. Could someone from TI send the following info to this mailing
list. (My apologies if this info was in some earlier mailing -- I can't
seem to find it if so. Maybe it was on the reservation form, which I
mailed in and didn't copy.)
1. Mailing address and phone number of the Sheraton Park Central.
2. How to get there from DFW airport. Approximate price and time
required for a taxi. Is there any cheaper way to make the trip, such as
a hotel limo? A lot of us will probably be arriving 10 - noon on
Wednesday, and will be heading back to the airport after adjornment on
Friday.
Thanks,
Scott
∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 86 09:00:46 PST
Date: Mon, 8 Dec 86 11:50:17 est
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8612081650.AA17339@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@ADA20.ISI.EDU, x3j13@SU-AI.ARPA
Subject: Re: meeting in Dallas
Bob
My new mailing address is
Jerry Johnson
MITRE Corp
Mail Stop W418
1820 Dolley Madison Blvd
McLean VA 22102
Jerry
∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Dec 86 03:57:48 PST
Received: from ti-csl by csnet-relay.csnet id ad02710; 10 Dec 86 6:34 EST
Received: from Puff (puff.ARPA) by tilde id AA00397; Mon, 8 Dec 86 17:37:01 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Logistics for Dallas Meeting
Date: 8-Dec-86 16:50:13
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2743455011@Puff>
Thanks for the suggestion, Scott.
The mailing address of the hotel is
Sheraton Park Central
12720 Merit Drive
Dallas, Texas 75251
and the phone number is 214-385-3000.
Taxi fare from DFW to the hotel should be
approximately $20. There is also a shuttle
service called The Link that charges $9.
The approximate travel time is 30 minutes.
-- Ellen
∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 86 18:55:23 PST
Date: 12 Dec 1986 18:25-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]12-Dec-86 18:25:14.MATHIS>
Thanks to everyone. I think we had a very productive meeting.
We have a lot of work to do in preparation for the March 16-18,
1987, meeting in Palo Alto. Let's keep the communication going.
Watch this space and help fill it. -- Bob Mathis
∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
To: x3j13@SAIL.STANFORD.EDU
Here they are:
rpg
#msg.msg[jnk,jmc]
hst
"uwmcsd1!marque!maxiv"@UNIX.MACC.WISC.EDU
coffee@AEROSPACE.ARPA
cugini@ICST-ECF
dabrowski@ICST-ECF
"J.Dalton%uk.ac.edinburgh"@CS.UCL.AC.UK
ffitch@RAND-UNIX
padget@RAND-UNIX
NGALL@BBNG.ARPA
"barmar%bco"@HI-MULTICS.ARPA
hadden@HI-MULTICS.ARPA
hemphill@NRL-AIC.ARPA
"uwmcsd1!marque!gregj"@RSCH.WISC.EDU
"fkunze%franz.uucp"@UCBVAX.Berkeley.EDU
"jkf%franz.uucp"@UCBVAX.Berkeley.EDU
"smh%franz.uucp"@UCBVAX.Berkeley.EDU
Baggins@IBM.COM
Brandon@IBM.COM
"marick%mycroft"@GSWD-VMS.ARPA
dougr@MIT-EDDIE.ARPA
"primerd!barryn"@MIT-EDDIE.ARPA
"mcvax!inria!chaillou"@seismo.CSS.GOV
"mcvax!inria!crcge1!neidl"@seismo.CSS.GOV
peck@SPAM.ISTC.SRI.COM
scherlis@VAX.DARPA.MIL
squires@VAX.DARPA.MIL
gls@ZARATHUSTRA.THINK.COM
Wegman@IBM.COM
antonisse@MITRE.ARPA
jjohnson@MITRE.ARPA
Wieland@MITRE.ARPA
Yonke@USC-ECL.ARPA
Ohlander@ISI.EDU
balzer@A.ISI.EDU
Mathis@A.ISI.EDU
berman@VAXA.ISI.EDU
masinter.pa@Xerox.COM
Adler.pa@XEROX.COM
Bobrow.pa@XEROX.COM
pavel.pa@XEROX.COM
daniels.pa@XEROX.COM
gregor.pa@XEROX.COM
Ricci.pa@XEROX.COM
Sye.pasa@XEROX.COM
vittal.pasa@XEROX.COM
"JerryB%OZ"@XX.LCS.MIT.EDU
Hewitt@XX.LCS.MIT.EDU
"willc%tekchips@tek.csnet"@RELAY.CS.NET
"sridhar%tekchips@tek.csnet"@RELAY.CS.NET
"angela%gmdtub.uucp@Germany.csnet"@RELAY.CS.NET
"Bartley%TI-CSL"@RELAY.CS.NET
"Bate%TI-CSL"@RELAY.CS.NET
"Dussud%AUSOME%TI-CSL"@RELAY.CS.NET
"ida%utokyo-relay.csnet"@RELAY.CS.NET
"Waldrum%TI-CSL"@RELAY.CS.NET
"TURBA%sperry-csd.csnet"@RELAY.CS.NET
bawden@MC.LCS.MIT.EDU
RG@MC.LCS.MIT.EDU
"mike%acorn"@LIVE-OAK.LCS.MIT.EDU
"RSG%OZ"@AI.AI.MIT.EDU
JAR@MC.LCS.MIT.EDU
Soley@MC.LCS.MIT.EDU
"edsel!eb"@NAVAJO.STANFORD.EDU
"edsel!jonl"@NAVAJO.STANFORD.EDU
"edsel!jlz"@NAVAJO.STANFORD.EDU
fahlman@C.CS.CMU.EDU
RAM@C.CS.CMU.EDU
sgadol@Sun.COM
Muchnick@Sun.COM
CPerdue@Sun.COM
"quintus!gehrig!bak"@Sun.COM
Moon@SCRC-STONY-BROOK.ARPA
KMP@SCRC-STONY-BROOK.ARPA
DLW@SCRC-STONY-BROOK.ARPA
Goldstein@SCRC-STONY-BROOK.ARPA
ACW@SCRC-STONY-BROOK.ARPA
chaowatkins@SCRC-STONY-BROOK.ARPA
griss@HPLABS.HP.COM
"DCM%HPFCLP"@HPLABS.HP.COM
chapin@hplabs.hp.com
Krall@MCC.COM
Loeffler@MCC.COM
"Brown%Bach.Dec.Com"@DECWRL.DEC.COM
slater@umbc2.umd.edu
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:53 PST
Date: 19 Dec 1986 05:51-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: minutes of Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:51:46.MATHIS>
Gary Brown has already sent me the draft minutes of the Dallas
meeting. They seem very good, but he and I are still double
checking each other. If you want to see the preliminary version,
I will forward it to you; if you would rather wait, they will
come in about ten days. -- Bob Mathis
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:38 PST
Date: 19 Dec 1986 05:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes
Subject: [Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
sigh, sigh! Guy got this done, but to me on a day I was off the
net. He has inserted some sight additions. We should discuss
this on the net so that we can make a clean copy with clearly
specified alternate wordings so that we could vote on it point by
point at the next meeting. In Dallas I got the feeling that if
we had a clean text, it would probably be passed unanimously.
This is the chance for all of you (particularly those who could
not be in Dallas) to participate in the discussion. -- Bob
Mathis
Begin forwarded message
Received: FROM GODOT.THINK.COM BY USC-ISIF.ARPA WITH TCP ; 16 Dec 86 09:46:39 PST
from boethius by Godot.Think.COM via CHAOS; Tue, 16 Dec 86 12:45:00 EST
Date: Tue, 16 Dec 86 12:46 EST
From: Guy Steele <gls@Think.COM>
To: mathis@ada20.isi.edu
Cc: gls@AQUINAS
Subject: [gls@Think.COM: X3J13 charter (proposed)]
Return-Path: <gls@Think.COM>
Message-ID: <861216124628.6.GLS@BOETHIUS.THINK.COM>
Sigh. I mailed this Friday evening, but to the wrong address.
--Guy
----------------------------------------------------------------
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National
Standard for Common Lisp. It will codify existing practice,
provide extensions to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in
{\it Common Lisp: The Language} by Guy L. Steele Jr. (Digital
Press, 1984), which is the current {\it de facto} standard for
Common Lisp. Whenever there is a proposal for the standard to
differ from {\it Common Lisp: The Language}, the committee
shall weigh both future costs of adopting (or not adopting) a
change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in {\it Common Lisp: The Language}
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in {\it Common Lisp: The
Language} that require resolution. Topics (d) and (e) are not
addressed by {\it Common Lisp: The Language} but appear to be
well-understood and ready for standardization. Topics (f)-(i)
concern areas where standardization is desirable but not
crucial to production of a standard. Topic (j) is an area of
current controversy within the Lisp community. Other topics
may be considered if specific proposals are received.
4. The committee recognizes that Lisp programming practice
will continue to evolve and anticipates the need for future
revisions and extensions to the standard. This may include a
family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
[Possible amendment: change the word "extensions" in the first
paragraph to "additional features".]
--------------------
End forwarded message
∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 07:27:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Dec 86 10:26:34-EST
Date: Fri, 19 Dec 1986 10:26 EST
Message-ID: <FAHLMAN.12264051413.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: proposed purposes
In-reply-to: Msg of 19 Dec 1986 08:46-EST from MATHIS at ADA20.ISI.EDU
Looks excellent to me.
The proposed ammendment (extensions -> additional features), seems like
a useful clarification.
-- Scott
∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Dec 86 08:31:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 DEC 86 08:31:11 PST
Date: 19 Dec 86 08:30 PST
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: proposed purposes
In-reply-to: MATHIS@ADA20.ISI.EDU's message of 19 Dec 86 05:46 PST
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <861219-083111-7132@Xerox>
I like this very much -- with the suggested change:
extensions --> additional features
It captures both the need for resolving the current set of issues
relatively quicly for the current community, and also possible futures
that could involve more work, but provide great benefit.
danny
∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:35:49 PST
Posted-Date: Fri 19 Dec 86 09:35:29-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22770; Fri, 19 Dec 86 09:35:30 PST
Date: Fri 19 Dec 86 09:35:29-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:35:29.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "additional
features" to "extensions".
Ron
-------
∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:58:18 PST
Posted-Date: Fri 19 Dec 86 09:43:35-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22910; Fri, 19 Dec 86 09:43:36 PST
Date: Fri 19 Dec 86 09:43:35-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:43:35.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "extensions"
to "additional features."
Ron
-------
∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 11:55:25 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17572; Fri, 19 Dec 86 11:55:23 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8612191955.AA17572@vaxa.isi.edu>
Date: 19 Dec 1986 1155-PST (Friday)
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: proposed purposes,
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
In-Reply-To: Your message of 19 Dec 1986 05:46-PST.
<[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Me Like. Ugh.
RB.
∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Dec 86 13:19:50 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32441; Fri 19-Dec-86 15:52:55 EST
Date: Fri, 19 Dec 86 15:54 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219155422.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
This looks fine. The spelling of "ommissions" should omit one of the
m's. I agree that "extensions" should be changed to "additional
features".
∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86 20:17:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87742; Fri 19-Dec-86 23:15:26 EST
Date: Fri, 19 Dec 86 23:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219231549.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think this is an excellent charter for X3J13. I approve of the
wording and especially of the attitude about what is important and the
choice to finish Common Lisp rather than embarking on a new experiment.
One comment on "establish normative Common Lisp programming practice":
I doubt it's actually possible to get such a large group of Lisp programmers
to agree in any meaningful way on issues of programming style. If this
goal is achieved, it will be a monumental accomplishment. My preference
would be to leave it to the professors and the authors of textbooks, but
I have no real objection. After all, some of the lettered items will be
fairly difficult to bring to closure too.
∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Dec 86 18:49:07 PST
Received: by hplabs.HP.COM ; Mon, 22 Dec 86 14:07:40 pst
From: hpfclp!dcm@hplabs.HP.COM
Received: by hpfclp; Mon, 22 Dec 86 10:24:52 mst
Date: Mon, 22 Dec 86 10:24:52 mst
Return-Path: <hpfclp!dcm>
Received: from hpfcdcm.UUCP; Mon, 22 Dec 86 10:15 MST
To: hpfclp!x3j13@sail.stanford.edu
Subject: Charter statement
This may have already appeared from another source, I'm not sure since there
seems to be some problem with my mail address. Here is the text of Guy's
statement of purpose with some comments from the discussions. Words or
clauses that were topics of discussion are enclosed in []s. Additional notes
are indented after each item.
Dave Matthews
------------------------------------------------------------------------------
Revise draft 86-005
Purposes of X3J13 Committee (proposed)
1. X3J13 is chartered to produce an American National Standard for Common Lisp.
It will codify existing practice, provide [extensions] [necessary] to
[facilitate] portability of code among diverse implementations and [establish]
normative [Common] Lisp programming practice.
change establish to stabilize?
extensions is a loaded word, are they required or not, maybe features is
a better word?
should a stronger term than facilitate be used
are we really establishing a programming practice, including style, etc
2. The committee will begin with the language described in Common Lisp: the
Language by Guy L. Steele Jr., which is the current de facto standard for
Common Lisp. Whenever there is a proposal for the standard to differ from CLTL
the committee shall weigh both future costs of adopting (or not adopting) a
[feature] and costs of conversion of existing code. [Aesthetic criteria shall
be a subordinate consideration.]
feature might be better said as change
should the clause about aesthetics exist at all
3. The committee will address at least the following topics in the course of
producing the standard, in each case either incorporating specific features or
explaining why no action was taken:
a) repairing [errors/mistakes], ambiguities and minor omissions in CLTL
b) error handling/condition signalling
c) semantics of compilation
d) object-oriented programming
e) iteration [the LOOP] constructs
f) multiprocessing
g) graphics
h) windows
i) one or two name spaces for functions or values
j) validation
Topics (a)-(c) concern deficiencies in CLTL that require resolution. Topics
(d) and (e) are not addressed by CLTL but appear to be well-understood and
ready for standardization. Topics (f)-(h) concern areas where standardization
is desirable but not crucial to production of a standard. Topic (i) is an
area of current controversy in the LISP community.
Topic (j) is not currently clarified.
4. The committee recognizes that Lisp programming practice will continue to
evolve, and anticipates the need for future revisions and extensions to the
standard. This may include a family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international Lisp standard.
separated from item 4.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:05 PST
Date: 5 Jan 1987 17:12-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: 2nd meeting minutes X3J13/86-021
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:12:03.MATHIS>
DRAFT Minutes X3J13 Committee Meeting
Dates: December 10, 11, 12, 1986
Location: Sheraton Park Central Hotel, Dallas, Texas
Chair: Bob Mathis (acting)
Secretary: Gary Brown (acting)
Hour of opening: December 10, 1986 1:20 PM
Hour of adjournment: December 12, 1986 11:25 AM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None were prepared
Register of Documents: Attached
Motions seconded and not withdrawn:
Motion to formally thank Ellen Waldrum and Texas Instruments for
the meeting arrangements.
Moved by Dave Slater
Seconded by Peter Coffee
Unanimously approved
Future meeting schedule:
The next meeting is scheduled for March 16, 17 and 18, 1987 in Palo
Alto, California. Dick Gabriel will make the arrangements.
List of action items assigned to committee members:
Working groups were formed for eleven areas requiring investigation
and a convenor was assigned for each group. These groups are
informally charged with bringing evaluation and recommendations back
to the full committee. The body of the minutes lists the groups
and their convenors.
Meeting Summary:
Call to Order:
The meeting was called to order at 1:20 PM.
Opening remarks:
Bob Mathis specified significant dates for X3J13:
December 30, 1986: Wrapup mailing for second meeting
January 9, 1987: Minutes for second meeting due
January 15, 1987: Membership fees due (however no one has
yet received bills)
February 4, 1987: Deadline for next meetings mailing
February 10, 1987: Mailing for meeting 3
Bob Mathis introduced himself discussed his background. All attendees
then introduced themselves.
Approval of agenda:
The agenda, X3J13/86-016, was approved without objection.
Approval of minutes:
The minutes of the first meeting (September 23-24) were not available.
Report on International Activities:
Bob Mathis attended SC22 in Vienna and reported on that meeting.
The major decision was that an ISO Lisp committee would be formed
with a convenor from France and a project editor from the United
States.
Dick Gabriel reported on the "EuLisp" meeting in Paris. The
"EuLisp" group intends to work through ISO and Christian Queinnec
would be group convenor. Several technical issues were also
discussed at the Paris meeting and it is obvious that there
are some technical differences between the initial "EuLisp"
proposal and Common Lisp.
Other liaisons reports:
Bob Mathis asked if there were any volunteers to review:
o Guidelines for programming language conformity and testing
o Programming language standards document standard (i.e. a standard
for how a standard should be written)
Mathis also reported that DEC Press would cooperate with X3J13 in
preparation of standards document. However, initial discussions
with ANSI on allowing the "free" distribution of the standard
document were not encouraging.
Review of Goals and Objectives (86-005):
Approximately an hour and a half was spent discussing the proposed
goal statement for X3J13. Issues raised included:
o the relationship between X3J13 and an ISO Lisp standard effort
o conservative vs ambitious planning and language design
o de-facto vs real standards
Various committee members contributed opinions and historical anecdotes.
No formal motions were made.
Overview of technical topics.
Dick Gabriel gave a brief overview of issues surrounding function
and value cell separation. Kent Pitman gave a overview of the
proposed condition handling system.
Recess:
The meeting was recessed on December 10, 1986 at 5:30 PM.
Call to Order:
The meeting was resumed on December 11, 1986 at 9:07 AM.
Function/Value Cells (86-010):
Dick Gabriel presented the technical issues raised in "Issues of
Separation in Function Cells and Value Cells" (86-010). This topic
was dsicussed for two and a half hours.
Lunch:
The meeting was recessed for lunch from 11:45 AM to 12:50 PM.
Goals and Objectives:
Danny Bobrow presented some alterations to the "Goals and Objectives".
These proposed changes included:
o Stating that X3J13 would work on two fronts; ANS standard for Common
Lisp and working with ISO to prodcue Lisp standard for the longer term.
o Stating we would address other areas such as windows, graphics and
multi-processing
Jerome Chailloux gave his opinions on the goals for X3J13.
Error Systems:
Kent Pitman presented a description of the proposed Common Lisp
Condition handling system. Discussions lasted an hour and fifteen
minutes. Kent believes this proposal is relatively firm and a
final specification will be available soon.
Update on object systems:
Danny Bobrow presented the status of the proposed Common Lisp
object subsystem. The major change between current design and
what was previously proposed is no longer using DEFSTRUCT for
object definition but instead using two new macros; DEFRECORD and
DEFCLASS. Danny believes that this work is progressing well and
expects convergence before the next meeting.
Goal and Objectives:
Approximately half an hour was spent in another open discussion
X3J13 of Goals and Objectives. Bob Mathis suggested that an
ANS standard separate from ISO might be rejected by X3.
Recess:
The meeting was recessed on December 11, 1986 at 5:15 PM.
Call to Order:
The meeting was resumed on December 12, 1986 at 9:10 AM.
The committee voted to formally thank Ellen Waldrum and Texas
Instruments for the meeting arrangements.
Handling Technical Issues:
Bill Scherlis reported on the reccommendations of a subgroup formed
to discuss effective ways for X3J13 to discuss and decide issues.
They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person speicified is
the acting chair for each group [other initial members are listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk, Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
Goal and Objectives:
Guy Steele presented the recommendation of a subgroup formed
to create another draft of the Goals and Objectives statement for
X3J13. Here is a draft of this document:
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
features to facilitate portability of code among diverse
implementations and establish normative Common Lisp practice.
2. The committee will begin with the language described in "Common
Lisp: the Language" by Guy L. Steele Jr., which is the current
"de facto" standard for Common Lisp. Whenever there is a
proposal for the Standard to differ from CLtL, the committee
shall weigh both future costs of adopting (or not adopting)
a change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities and minor omissions in CLtL
(b) Error handling/condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration construct(s)
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) One or two namespaces for functions and values
(j) Validation
Topics (a)-(c) concern deficiencies in CLtL that require resolution.
Topics (d) and (e) are not addressed by CLtL but appear to be
well understood and ready for standarization. Topics (f)-(h)
concern areas where standarization is desirable but not crucial
to production of a standard. Topic (i) is an area of current
controversy within the Lisp community. Other topics may be
considered if specific proposals are received.
4. The comittee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
A discussion of this proposal took place followed by an informal
"sense of the committee" vote. The committee overwhelmingly
accepted this proposal. A final draft of this will be prepared
for a formal vote at the next meeting.
Call for officer candidates:
The following committee members are standing for X3J13 elected offices:
o Chair - Bob Mathis
o Vice-chair - Guy Steele
o International Representative - Dick Gabriel
Future meeting Schedule:
The next meeting will be March 16-18, 1987 in Palo Alto, California.
Adjournment:
The meeting was adjourned on December 12, 1986 at 11:25 AM.
Respectfully Submitted,
Gary L. Brown
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:30 PST
Date: 5 Jan 1987 17:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes X3J13/86-020
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:15:45.MATHIS>
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
extensions [amendment: change the word "extensions" to
"additional features".] to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic criteria shall be a subordinate
consideration.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:26:57 PST
Date: 5 Jan 1987 17:03-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: general letter X3J13/86-022
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:03:23.MATHIS>
Doc. No.: X3J13/86-022
Date: 86-12-30
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To everyone on the X3J13 (Common Lisp) mailing list:
This letter is being sent out in three different configurations: by
electronic mail to <x3j13> at SAIL (to everyone on that list), by regular
mail with enclosures (to everyone who has given an indication of
participation), and by regular mail without enclosures (to those on the
mailing list who have never responded). People who receive this letter
without enclosures, need to respond to this letter to remain on the mailing
list. Membership on X3J13 is open, but is based on a commitment to
continuing participation.
The Draft minutes of the Dallas meeting are enclosed (Doc: X3J13/86-021).
Thanks to Gary Brown. Included there is the list of initial members in the
task groups we formed (this was also the content of a separate electronic
message). Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed. At least part of the reason for
not forming the ISO interaction group was that the US delegation to the ISO
working group has not been chosen. Anyone from X3J13 is eligible if they
can make the additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation, please
contact me; Mathis, Gabriel, and Clinger have already expressed their
interest.
The acting chairs are to make sure that the members of their group
communicate with each other. If it is appropriate that a group set itself
an agenda and select a leader, the acting chair should make sure it
happens. Each of these groups will be called on for a BRIEF report at the
next meeting. If that report will be any more than just an affirmation of
existence, please contact me for scheduling.
As a separate document (Doc: X3J13/86-020) the draft proposed purposes are
also enclosed. This differs slightly from the version in the minutes; it is
X3J13/86-020 (or its revision) that we will be considering at the next
meeting. This has also been circulated electronically.
You (that is people who received enclosures with this letter or who respond
to this letter) will be sent the other documents resluting from the Dallas
meeting separately.
If you have any comments or other documents you want circulated before the
next meeting, please send them to me by February 4, 1987.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 07:19:23 PST
Date: 6 Jan 1987 07:13-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: task groups
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 6-Jan-87 07:13:41.MATHIS>
This has been covered in my over messages, but
is also being sent separately for emphasis.
-- Bob
At the meeting in Dallas, we decided to form some subgroups
(working groups, task groups, committees, or whatever name). What
follows is a section from the draft minutes giving the initial
structure of these groups. (Thanks to Gary Brown for getting the
minutes ready so promptly.) Others are free to join these groups,
but the size of each group should remain reasonable and
individuals should recognize they are making a commitment by
joining.
Bill Scherlis reported on the recommendations of a subgroup
formed to discuss effective ways for X3J13 to discuss and decide
issues. They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person specified is
the acting chair for each group [other initial members are
listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk,
Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
[At least part of the reason for not forming the ISO interaction
group was that the US delegation to the ISO working group has not
been chosen. Anyone from X3J13 is eligible if they can make the
additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation,
please contact me; Mathis, Gabriel, and Clinger have already
expressed their interest.]
[The acting chairs are to make sure that the members of their
group communicate with each other. If it is appropriate that a
group set itself an agenda and select a leader, the acting chair
should make sure it happens. Each of these groups will be called
on for a BRIEF report at the next meeting. If that report will be
any more than just an affirmation of existence, please contact me
for scheduling.]
∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 21:56:12 PST
Received: by navajo.stanford.edu; Tue, 6 Jan 87 21:55:27 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01003; Tue, 6 Jan 87 21:48:53 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA16556; Tue, 6 Jan 87 21:46:18 PST
Date: Tue, 6 Jan 87 21:46:18 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701070546.AA16556@bhopal.edsel.uucp>
To: navajo!MATHIS%ADA20.ISI.EDU@navajo.stanford.edu
Cc: navajo!x3j13%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
[Sorry for the late entry of this comment -- I sent it out over two weeks
ago, and it got "bounced back" from some mail gateway at Stanford after
a few days of mailer problems; also, I've been "out of action" for
the past two weeks.]
Return-Path: <jonl>
Date: Fri, 19 Dec 86 11:27:59 PST
From: jonl (Jon L White)
To: navajo!MATHIS%ADA20.ISI.EDU
Cc: navajo!x3j13%SAIL.STANFORD.EDU
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
At Dallas, there was question about the first paragraph wording:
". . . establish normative Common Lisp programming practice."
Just what does that mean? and how can a committee "establish" it?
Someone suggested that that phrase was a replacement for some nebulous
statement about "portability of programmers", or "portability of skills".
If that is indeed the goal, then it's hard to see how a committee can
"establish" it -- I remember a suggestion being offered to re-word the
whole sentence roughly as follows:
"It will codify existing practice, provide additional features to
enable the portability of code among diverse implementations,
and facilitate the establishment of normative Common Lisp
programming practice."
-- JonL --
∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 13:29:03 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Jan 87 16:28-EST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 24905; 15 Jan 87 16:14:20-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 51643; Thu 15-Jan-87 14:31:21-EST
Date: Thu, 15 Jan 87 14:31 est
Sender: mike@acorn
To: x3j13@sail.stanford.edu
From: mike%acorn@mit-live-oak.arpa
Subject: Document 86-019
Note: You will be receiving hardcopy of the following from Bob Mathis.
----------------------------------------------------------------------
!
To: ANSI x3j13
From: Mike Beckerle, Gold Hill Computers
Date: 1/13/87
Subject: Document x3j13/86-019
Since my draft proposal which was hastily drawn up at the last x3j13
meeting, I have had time to reconsider several points in my proposal
for adding a few features to CL to support Higher-Order Functional
Programming. I have also decided to bring up the meta issue in this
forum.
The meta-issue is this: Would adding enough syntactic accommodation
to Common Lisp to make functional programming palatable defuse this
Lisp1 vs. Lisp2 debate enough? Or more optimistically, what level of
accommodation for programming with functionals would in fact defuse
this issue. For example, Would it be enough to provide the following:
Programs written in in a Lisp1 "educational/functional" dialect would
not be directly upwardly compatible with ANS Common Lisp; however,
the changes required would be straightforward to make and
syntactically convenient. (We know that they can't be automatic due
to use of EVAL.) I am particularly trying to address the issues of
Appendix B, section 6 of the "Issues..." paper.
What I'm trying to get at here is this: Why do people want a
"one-cell" lisp? Is it because it promotes/allows effective
programming using higher-order functions (style), because it is
more consistent/cleaner and therefore easier to understand and
teach (conceptual economy), because they are more familiar with a
one-cell lisp than a two cell lisp (momentum), because of a
purely aesthetic view that one cell is "better" (aesthetics),
because they don't like the name-capture problems of
common-lisp's so called "non-hygienic" macros (macrophobia), or
finally because they want political clout (politics).
My approach addresses that the push for lisp1 is due at least
partially to aesthetics but primarily is due to the style issue.
The following is a proposal for adding a small number of features
to Common Lisp to accommodate programming using higher-order
functions, or functionals. Functional programming is much easier
in a Lisp1 dialect than a Lisp2 dialect since functional
programming makes extensive use of functions as values. Common
Lisp's current (Funcall ...) and (Function ...) or #' syntax
makes functional programming particularly awkward. In addition
the fact that one cannot write an application which produces a
function in the car of a list representing an application is a
pain. [let's call this the "((f g) h)" problem.] These features
are intended to accommodate the functional style, without changing
the language too radically from the current status defined in
CLtL.
---------------------------------------------------------------------
!
Document x3j13/86-019
Accommodating Functional-Style Programming in Common Lisp.
Mike Beckerle
Gold Hill Computers
Jan. 6, 1986.
One of the primary motivations for use of Lisp1 dialects is the
ease of higher-order programming. Many of the examples of
effective programming practice in Lisp1 given in the "Issues of
Separation in Function and Value Cells" paper recently discussed
by x3j13 at the Dec. '86 meeting are exactly of this type.
Unfortunately, macro programming in Lisp1 dialects is not well
understood and is a subject of current research; nevertheless
macro programming is heavily entrenched in the Common lisp world.
As a result, the approach advocated in this proposal is to
provide some standard operators and macros which make programming
using higher-order functions in Common Lisp significantly easier.
The Changes to CL as defined in CLtL are enumerated here, after
which there are some examples.
Change 1:
To section 5.2. Functions
Function call forms should be changed to allow the lisp1 like
syntax of:
((f g) h)
((lambda (x) x) #'(lambda (y) y)) 10) => 10.
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
beginning with something other than LAMBDA it should be
interpreted as an application itself.
The forms above should, in every sense of the word except syntax,
be equivalent to:
(funcall (f g) h)
and
(funcall ((lambda (x) x) #'(lambda (y) y)) 10))
in the current CL as per CLtL.
Essentially, whenever symbols are used as functions, their
function-cell definitions are used. Lambda expressions and
function applications can also be used as functions. Lambda
expressions evaluate to functions. Function applications must
evaluate to either functions or symbols. If they evaluate to
symbols, then (recursively) the function definition of that
symbol is used.
The CL spec can explain the purpose of this special treatment for
function-positioned symbols in terms of the name-capture problem
of macros. Inadvertant name capture is, after all, the only real
reason for the special distinction for funtion-positioned symbols.
!
Change 2: Section 7.1.1.
The FUNCTION special form will be optional in front of
lambda expressions regardless of where they appear in a
program text. (The obvious exception for within quoted lists
obviously applies here, but isn't worth mention.)
It is as if the following definition was part of the CL system
(Defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
The FUNCTION special form is needed only to distinguish between
the function and value of symbols which are either globally
referenced or locally bound using one of FLET, LABELS, MACROLET,
parameter passing, LET, LET*, and MULTIPLE-VALUE-BIND.
!
Change 3: Section 20.2
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
E.g.,
(symbol-value 'mapcar) => #<compiled-function 1234>
(symbol-function 'mapcar) => #<compiled-function 1234>
This allows use of the CL symbols which name CL functions in
variable position without need for the FUNCTION special form as
in (mapcar list '(a b c) '(d e f)). If the value of the variable
"list" is locally bound to a function, possibly using let, then
the local definition will be used in accordance with the rules of
lexical scoping.
The primary change this requires is the renaming of certain
symbols of significance to the standard read-eval-print loop.
I suggest that the following renamings be used:
+ => +1
++ => +2
+++ => +3
- => -- or _ ;; this one's difficult to get a nice name for!
* => *1
** => *2
*** => *3
/ => /1
// => /2
/// =? /3
The behavior of these variables would be identical to the current
behavior of the old-named variables. I consider this change to
be simply cosmetic, aesthetic, etc. No program of any quality
(other than those written as read-eval-print loops by
implementors) ever uses these variables. (Unfortunately, the
Peter Principle dictates that the least significant point always
gets the most debate, so I'm prepared for absolute tirades on
this one! Please restrain yourselves!!!!!)
!
Change 4: Section 7.11. Use of Higher-order Functions
Organizationally, this seems to belong in the chapter 7
discussion, so I've proposed a new section for that chapter
in lieu of any guidelines for how to present standards proposals.
The text as a preliminary draft follows:
"Common Lisp provides some support for programming using higher-
order functions. These allow the programmer to partially hide the
distinction between function-cells and value-cells and to program
as if using a language where only one cell is associated with
each symbol. The objective is to make the syntax of higher-order
programs easier to read and understand. The abstraction that this
creates is not complete; it is possible for programs to detect
that there are separate function and value cells even when these
abstractions are used; however, the syntactic convenience of
using these forms where they are applicable is significant.
FUNCTIONAL Vars* {form}* [Macro]
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
For example:
(defun doublemap (f g)
(functional (f g)
(lambda (list) (f (g (mapcar f list)
(mapcar g list))))))
(defun y (f) ;; the paradoxical combinator
(functional (f)
((lambda (x)
(functional (x)
(f (x x))))
(lambda (x)
(functional (x)
(f (x x)))))))
Here, notice that "f" and "g" are used both as variables
representing functions, and also as functions, as if defined by
FLET or LABELS.
One possible definition for FUNCTIONAL is:
(defmacro functional (vars &body body)
(let* ((bindings (mapcar #'(lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
Implementation note: FUNCTIONAL can also be implemented
using MACROLET.
Care is required if FUNCTIONAL is used in programs which perform
side-effects on symbols via SYMBOL-FUNCTION or SYMBOL-VALUE. The
behavior of the resulting program can be difficult to predict."
!
Change 5: Section 7.1.1. (again)
Note: The following is the least kosher aspect of this proposal,
but I am including it anyway. Once again it is written as an
addition to section 7.1.1. Its intended use is for defining new
named functions which will be associated with both function and
value cells of symbols, thereby forming a consistent extention.
In general, use of side-effects within higher-order programs is
extremely tricky; one tends to program in a pure style out of
necessity.
SYMBOL-CONTENTS symbol [Function]
In order to facilitate programming in the functional style it is
often useful to ignore the function-cell/value-cell aspect of
symbols. Symbol-contents, if used consistently throughout an
entire program can facilitate this style of programming.
The function Symbol-contents can be used to extract or replace the
value of a symbol in a manner which is indifferent to the
normal CL distinction between function cells and value cells.
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
Symbol-contents cannot access nor assign (using setf) the value
of local symbol or function definitions created using let, flet, labels,
let*, etc. Only the global value can be accessed or modified.
It is an error to execute code which calls a function named by a symbol
where that symbol has been assigned a value other than a function object
via setf of symbol-contents.
(defun foobar (x) x)
(symbol-contents 'x) => #<unbound>
(setf (symbol-contents 'x) (lambda (x) (+ x x)))
(symbol-contents 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-function 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-value 'x) => #<function-object (lambda (x) (+ x x))>
(eq (symbol-function 'x) (symbol-value 'x)) => T
--------------------------------------------------------------------
!
Use of the Higher-order function extensions to CL.
To show the utility of these abstractions in higher order
programming, it is important to look at some example programs.
Hence, I have rewritten the examples in Appendix B of
the "Issues of Separation in Function Cells and Value Cells"
using Common Lisp with the proposed extensions.
;;;---------------------------------------------------------------------
;;; from Appendix B: "High-Order Procedures for Functional Abstractions"
;; our macro for making functional programming easier.
(defmacro functional (vars &body body)
(let* ((bindings (mapcar (lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
;; a macro which obviates #' notation.
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
;; the symbol-contents function and its setf.
(defun symbol-contents (name)
(symbol-value name))
(defun set-symbol-contents (name value)
(setf (symbol-value name) value)
(setf (symbol-function name) value))
(defsetf symbol-contents set-symbol-contents)
;; a DEFINE macro, syntactic sugar to make the examples
;; more scheme-like. Doesn't put implicit blocks on lambda's,
;; doesn't handle local defines. This could be done, but we won't bother
;; here.
(defmacro define (name value)
`(setf (symbol-contents ',name) value))
;; misc.
(defun null? (x) (null x))
(defun future (x) x)
(defun assq (x y)
(assoc x y :test 'eq))
;;--------------------------------------------------------------------
!
;; The example programs.
;; these have been translated slightly from Scheme to Common Lisp
;; plus my suggested extentions.
(define sum
(lambda (f a next b)
(functional (f next)
(if (> a b)
0
(+ (f a)
(sum f (next a) next b))))))
(define integral
(lambda (f a b dx)
(functional (f)
(* (sum f (+ a (/ dx 2)) (lambda (x) (+ x dx)) b)
dx))))
(define map
(lambda (f x)
(functional (f)
(if (null x)
nil
(cons (f (car x))
(map f (cdr x)))))))
(define reduce
(lambda (f l)
(functional (f)
(if (null? (cdr l))
(car l)
(f (car l)
(reduce f (cdr l)))))))
(define pairs
(lambda (x k)
(functional (k)
(if (or (null? x) (null? (cdr x)))
(k nil x)
(pairs (cddr x)
(lambda (p r)
(k (cons (list (car x) (cadr x))
p)
r)))))))
(define reduce
(lambda (f x)
(functional (f)
(pairs x
(lambda (p r)
(if (null? p)
(car r)
(reduce f
(append (map (lambda (z)
(future (apply f z)))
p)
r))))))))
(defstruct (table-abstraction
(:constructor make-table-abstraction
(maker looker-up inserter))
(:conc-name nil))
maker looker-up inserter)
(defun hashfunction (n)
(lambda (x)
(mod (sxhash x) n)))
(define hashify
(lambda (n table-abstraction)
(let ((hash (hashfunction n))
(bucket-make (maker table-abstraction))
(bucket-lookup (looker-up table-abstraction))
(bucket-insert! (inserter table-abstraction)))
(functional (hash bucket-make bucket-lookup bucket-insert!)
(let ((make
(lambda ()
(let ((hashtable (make-array n)))
(dotimes (i n)
(setf (aref hashtable i)
(bucket-make)))
hashtable)))
(lookup
(lambda (key table)
(bucket-lookup key
(aref table
(hash key)))))
(insert!
(lambda (key table value)
(bucket-insert! key
(aref table (hash key))
value))))
(make-table-abstraction make lookup insert!))))))
(defun make-entry (key value) (cons key value))
(defun set-value! (vcell value) (rplacd vcell value))
(define alist-table-abstraction
(make-table-abstraction
(lambda () (list '*alist-table*))
(lambda (key table)
(cdr (assq key (cdr table)))) ;; alist of cons pairs
(lambda (key table value)
(let ((vcell (assq key (cdr table))))
(if vcell
(set-value! vcell value)
(rplacd table
(cons (make-entry key value)
(cdr table))))))))
(define hash-table-of-alists-abstraction-generator
(lambda (n) (hashify n alist-table-abstraction)))
(define hash-table-of-alists
(hash-table-of-alists-abstraction-generator 16))
(define two-level-hash-table-abstraction-generator
(lambda (m n table-abstraction)
(hashify m (hashify n table-abstraction))))
(define two-level-hash-table-of-alists-abstraction-1
(two-level-hash-table-abstraction-generator
128 256 alist-table-abstraction))
;;-----------------------------------------------------------------
My observation is that using the FUNCTIONAL abstraction along with the
ability to perform applications which syntactically look like "((f g) h)"
makes the enhanced CL version pretty close to the Lisp1 version at least
as far as syntactic aesthetics are concerned.
∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jan 87 20:15:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44898; Thu 15-Jan-87 23:13:42 EST
Date: Thu, 15 Jan 87 23:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Document 86-019
To: mike%acorn@MIT-LIVE-OAK.ARPA
cc: x3j13@sail.stanford.edu
In-Reply-To: The message of 15 Jan 87 14:31 EST from mike%acorn@mit-live-oak.arpa
Message-ID: <870115231337.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 15 Jan 87 14:31 est
From: mike%acorn@mit-live-oak.arpa
I don't know if X3J13 is the right mailing list for technical discussions,
but I'd like to offer a few comments on your proposal. To avoid contributing
to total mail overload, I will abbreviate your proposal as much as possible
when referring to it.
Change 1: Function call forms should be changed to allow the lisp1 like
syntax of: ((f g) h)
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
it should be interpreted as an application itself.
I think this is a good idea. It's a kludge, of course, and creates a
small inconsistency in the language (allowing list forms but not symbol
forms), however I think the ratio of benefit to harm is favorable.
Maclisp on the pdp-10 used to have a feature similar to this, but it was
removed because it caused a lot of problems. I believe the problems can
be traced to the fact that it allowed the result of evaluating a list or
efunctuating a symbol to be another list, which was then evaluated. The
question is, in what lexical scope should that list be evaluated. Your
proposal avoids this problem by forbidding repeated evaluation.
Your proposal allows repeated efunctuation (that is, the result of
evaluating a list can be a symbol, which is then efunctuated) and you
don't specify in what lexical environment the symbol is to be
efunctuated. CLtL is not very clear on this point; p.107 says that
APPLY efunctuates in the global lexical environment if given a symbol,
but otherwise the issue is not addressed as far as I can see. This
feature may not be essential to your proposal; you might want to remove
it.
(For those who haven't seen the term before, "efunctuate" is what the
FUNCTION special form does.)
Change 2: It is as if the following definition was part of the CL system
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
This is definitely a good idea and causes no problems.
Change 3:
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
I don't think this is a good idea, because it creates an artificial
distinction between built-in CL functions and functions defined by
the user with DEFUN or LABELS. If the rule of storing the definition
in both cells applies to the latter type of functions too, then
we would just have Lisp1.
Change 4:
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
This is a good idea. To me it seems that having this eliminates the
need for your change 3.
Change 5:
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
This stands or falls with change 3. Again, I think change 4 is
a better approach.
∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 08:21:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 16 Jan 87 11:21:29-EST
Date: Fri, 16 Jan 1987 11:21 EST
Message-ID: <FAHLMAN.12271401438.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, x3j13@SAIL.STANFORD.EDU
Subject: Document 86-019
In-reply-to: Msg of 15 Jan 1987 23:13-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This discussion should probably be on the Common-Lisp mailing list, but
since I'm responding to Moon's mail to this list, I'll do it here.
I agree totally with Moon on this one -- I was just about to write a
reply with essentially the same content as his, supporting the idea
except for parts 3 and 5.
If the goal is to make functional-style programming easier without
disrupting Common Lisp too badly, I think your proposals (minus numbers
3 and 5) do the job about 90% as well as a move to Lisp1. For those
people whose goal is to merge Common Lisp with Scheme and/or Eulisp,
then only a move to Lisp1 will do. However, unless great progress is
made on the macro issue and on ways of making the conversion less
painful, I think that a move to Lisp1 is unlikely; less radical
proposals such as yours are definitely worth considering.
I like this much better than the &function idea, by the way. that
seems very confusing and irregular to me.
-- Scott
∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jan 87 11:24:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JAN 87 11:24:00 PST
Date: 16 Jan 87 11:24 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Document 86-019, &function, etc.
In-reply-to: various
To: x3j13@sail.stanford.edu
Message-ID: <870116-112400-2364@Xerox>
These proposals fail to meet what I believe is the primary goal of those
who want 1-lisp over 2-lisp, namely, to simplify and make more
consistent the programming language semantics, to reduce the number of
different kinds of references in the language.
Instead, they do the opposite. While superficially bearing some
resemblance to 1-lisp, there are more rules for evaluation rather than
fewer, the description of the language and its semantics is complex,
there are odd exceptions. (For example, in the
funcall-if-car-of-form-is-list proposal, what if the car of the form is
a macro? A macro that expands to a symbol? To a lambda?).
It does no good to pick some minor syntactic feature of 1-lisp,
implement that, and ignore the basic principle.
∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Jan 87 21:55:29 PST
Received: from tektronix.tek.com by csnet-relay.csnet id ab04827;
17 Jan 87 0:43 EST
Received: by tektronix.TEK.COM (5.31/6.18)
id AA04079; Fri, 16 Jan 87 21:25:51 PST
Received: by tekchips.TEK (5.31/6.16)
id AA12223; Fri, 16 Jan 87 14:56:26 PST
Message-Id: <8701162256.AA12223@tekchips.TEK>
To: x3j13@SU-AI.ARPA
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU
Subject: Re: Document 86-019
In-Reply-To: Your message of Thu, 15 Jan 87 14:31 est.
<8701160757.AA02526@tekchips.TEK>
Date: 16 Jan 87 14:56:21 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Mike Beckerle asked some interesting questions and suggested some possible
answers. Ultimately, he is asking for a philosophy of programming language
design. Here's mine.
* * *
Programming is hard because it's hard to know what you want the machine
to accomplish (the problem), and it's hard to know how to accomplish it
(the algorithm). If you knew these two things, it ought to be easy to
program the machine to do what you want.
It usually isn't. The reason is that you have to learn all sorts of arcane
things about the computing environment and programming language that you
use. These details have nothing to do with the problem you're trying
to solve. Even so, they may be almost as difficult to master.
Most people, being reasonable, don't try to master their programming
language completely, particularly if their programming language is big
and complicated. In my experience, the main thing that a programming
language can do for these people is to be consistent with a simple mental
model that they can use without getting into trouble. Extra features
that help people get their work done more easily are nice, but it is more
important that the language not get in their way. It is most important
that the language not be full of nasty surprises for its users.
This principle of programming language design is sometimes known as the
"Law of Least Astonishment", in waggish recognition of the fact that even
the best design efforts are ad hoc in part. Its motivation is very
pragmatic, its application very practical. It says that simplicity,
elegance, and aesthetics pay off.
* * *
In answer to some of Mike's specific questions, people prefer a single-
environment Lisp because of style, conceptual economy, and aesthetics; I
see little difference between conceptual economy and aesthetics, which is
perhaps a clue to my sense of aesthetics. Inertia can't be the reason,
since most of us who prefer the single environment were once more familiar
and comfortable with two-cell Lisps. Macros don't have anything to do with
this issue, so macrophobia can't be the reason; if anything, the problems
with Common Lisp-style macros are exacerbated by a single environment.
Speaking for myself, politics isn't the reason I prefer a single
environment; rather my preference for a single environment, the current
preponderance of political clout on the side of multiple environments,
and the use of that clout in the current push for Lisp standards are the
reasons I myself now seek political clout.
* * *
Mike's other question asks whether enough syntactic sugar could be added
to Common Lisp to make functional programming palatable. Well, Common
Lisp certainly could be improved in this respect, and I second David
Moon's remarks on changes 1 and 2.
As for changes 3, 4, and 5, these changes seem designed to make it possible
to program as though Common Lisp were a Lisp1 dialect, but they only go
part of the way. You might be able to go all the way by doing things like
defining the LAMBDA macro so it automatically wraps an equivalent of the
FUNCTIONAL macro around its body, by defining a SET! special form that
assigns to both the value and functional bindings (which, by the way, can't
easily be written in Common Lisp as it stands because only global functional
bindings can be assigned), and so on. This would amount to implementing
a Lisp1 sublanguage inside Common Lisp. Unless you're willing to go
all the way to that Lisp1 sublanguage, I think it's a bad idea to try
to paper over the fact that Common Lisp has multiple environments.
If the changes go only part of the way, and we teach people to use the
proposed syntax and encourage them to think about Common Lisp as though
it is a Lisp1 dialect, then they will probably end up getting burned
even more often than they do now. Even people who understand full well
that Common Lisp has multiple environments might slip into the cozier
Lisp1 mode of thought and get burned by the Lisp2 reality.
It's the law of least astonishment: A Lisp2 dialect that looks like a
Lisp1 dialect 98% of the time may be worse than a straightforward Lisp2
dialect.
Peace,
William Clinger
∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂10-Feb-87 0246 RPG Registration
To: x3j13@SAIL.STANFORD.EDU
Don't forget to register for the March meeting. Registration closes
in a couple of weeks and right now there are only a handful registered.
-rpg-
∂10-Feb-87 2209 RPG Reminder About March Registration Procedure
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂13-Feb-87 1948 MATHIS@ADA20.ISI.EDU plans for Palo Alto and mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 19:46:39 PST
Date: 12 Feb 1987 11:35-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: plans for Palo Alto and mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]12-Feb-87 11:35:35.MATHIS>
Today I put the following in the US mail to our physical mailing list.
Most of the documents referenced can also be had electronically. Two
items of particular interest follow -- the cover letter and the DRAFT
agenda (please send me any further detail you may have for a revised
agenda):
Doc. No.: X3J13/87-006
Date: 87-02-10
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To X3J13 (Common Lisp) participants:
Enclosed are some of the documents relating to the upcoming
meeting in Palo Alto, CA on March 16-18, 1987. Most of you are on
the electronic mailing list and should have seen most of this
earlier. In particular hotel reservations are due about the time
you will probably receive this letter.
Dick Gabriel will be sending out information relative to the
objects proposal separately and directly [documents 87-002 and
87-003].
Notice that there is a revised version of Doc: 86-020 on Purposes
included with document 86-023. This includes some of the comments
that I saw on the net reproduced in a way that will hopefully
facilitate their consideration. If you have other comments or
changes that you may want to suggest at the meeting, please bring
about 50 copies for distribution there. I expect some action will
be taken on this document at the meeting.
Documents 86-017 and 86-018 are from the infamous lost boxes of
Dallas.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Enclosures:
86-017 Excerpts from ISO/TC97/SC22 ad hoc report re Lisp
86-018 Papers from Symbolics re objects and flavors
86-019 from Mike Beckerle
86-020R included with 86-023
86-023 Comments on Purposes document 86-020
86-024 Comments on Lisp1/Lisp2 issues
87-000 Document Register for 1987
87-001 Document Register for 1986
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
SD-04 Meeting Schedule
Note: 87-002 and 87-003 being mailed separately.
Proposed Agenda X3J13/87-005
AGENDA -- Day 1
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
1 Call to Order, March 16, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda (87-005)
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-025)
5 Approval of Minutes of Dec 10-12 Meeting (Doc: 86-021)
6 Report on International Activities (Doc: 86-017)
7 Other Liaison Reports
8 Action on Goals and Objectives (Doc: 86-020R and 86-023)
9 Reports from Task Group Chairmen
10 Recess, 5:00pm
AGENDA -- Day 2
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
11 Call to Order, March 17, 9:00am
12 Discussion of Objects Proposal (87-002 and 87-003)
13 LUNCH Second Day, 12:00-1:00pm
14 Continued Objects Discussion (87-002 and 87-003)
15 Recess, 5:00pm
AGENDA -- Day 3
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
16 Call to Order, March 18, 9:00am
17 Additional Reports from Task Group Chairmen
18 Future Meeting Schedule (Doc: SD-04)
19 Review of Action Item Assignments
20 Adjournment, 12:00noon
∂27-Feb-87 1453 RPG X3 registration list 2/27/87
To: x3j13@SAIL.STANFORD.EDU
Below is the list of people I have heard from, hotel dates and
whether registration fees have been paid. Please check the
list and let me know if you disagree with any information about
yourself.
---jan---
Registration/Hotel List
02/27/87
Name Company Check In Check Out Paid
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- -
Gary Brown Digital 03/15/87 03/18/87 y
Jerome Chailloux INRIA -0- -0- -
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 -
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Kevin Layer Franz Inc. -0- -0- y
Bob Mathis DARPA 03/14/87 03/19/87 y
Ronald Ohlander USC/ISI -0- -0- y
Crispin Perdue SUN MicroSystems -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂27-Feb-87 1513 ohlander@venera.isi.edu Re: X3 registration list 2/27/87
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Feb 87 15:13:46 PST
Posted-Date: Fri 27 Feb 87 15:14:12-PST
Received: by venera.isi.edu (5.54/5.51)
id AA03315; Fri, 27 Feb 87 15:14:12 PST
Date: Fri 27 Feb 87 15:14:12-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 registration list 2/27/87
To: RPG@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 27-Feb-87 15:14:12.VENERA.ISI.EDU>
In-Reply-To: Message from "Dick Gabriel <RPG@SAIL.STANFORD.EDU>" of 27 Feb 87 1453 PST
Dick,
I will check in on the evening of the 17th of March and check out on the 18th
of March. I have made my room reservation independently.
Ron
-------
∂03-Mar-87 1251 berman@vaxa.isi.edu Re: Who's Where?
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:51:19 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17152; Tue, 3 Mar 87 12:51:59 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032051.AA17152@vaxa.isi.edu>
Date: 3 Mar 1987 1251-PST (Tuesday)
To: berman@vaxa.isi.edu (Richard Berman)
Cc: X3J13@su-ai.arpa
Subject: Re: Who's Where?
In-Reply-To: My message of 2 Mar 1987 1332-PST (Monday).
<8703022132.AA05893@vaxa.isi.edu>
A few days ago I asked for the members of the X3J13 subgroup on validation to
please send me their current net address as part of a message (as opposed to
just having the mailer automatically generate one). So far Mike Beckerle and
John Foderaro have responded. Could Jon L. White and David Slater please
respond, as well as any others???
Thanks a bunch.
RB
∂03-Mar-87 1359 berman@vaxa.isi.edu Validation
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 13:59:30 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17899; Tue, 3 Mar 87 13:59:42 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032159.AA17899@vaxa.isi.edu>
Date: 3 Mar 1987 1359-PST (Tuesday)
To: Marick@GSWD-VMS.ARPA
Cc: berman@vaxa.isi.edu, cl-validation@su-ai.arpa, X3J13@SU-AI.arpa
Subject: Validation
> I'm not going to respond to your message until you respond to mine.
> I just spent a weekend rewriting sequence function tests and,
> consequently, rewriting some sequence functions. I am more convinced
> than ever that a test suite should predate publication of a standard
> -- there's at least one other sequence function besides *ASSOC* that's
> underspecified. (Unfortunately, I didn't write it down, and I've
> forgotten which one, now.)
> Does the deafening silence mean consent?
Brian, let me know if this gets through. I have been responding to messages,
but sending them to marrick%cthulhu@gswd-vms.arpa has not worked.
I don't know that a test suite should *predate* standard publication, but it
should be part of that publication. In fact, when formally published it would
be a good idea to for the standard and the test-suite to cross reference each
other. That is, the each test should test a specific clause (or clauses?) of
the standard. The standard should also include forms which must evaluate in a
certain way where this is meaningful to the definition of some part of the
standard. In these cases the form would be part of the test suite.
HOWEVER....
I believe it is possible to have a useful test suite before the standard is
finalized and published. I am preparing a report now for the X3 meeting that
will outline some possible stages in the development of the test suite. Part
of our problem is that we are aiming at a moving target...
Best,
RB
∂07-Mar-87 1414 MATHIS@ADA20.ISI.EDU agenda update
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 14:14:45 PST
Date: 7 Mar 1987 14:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: agenda update
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 7-Mar-87 14:15:02.MATHIS>
Although I will not be making a revised agenda, on Monday, March
16, we will be having a report from Masayuki Ida on activities in
Japan, a report from Bob Balzer and Rich Berman on validation
developments, and I expect an initial report from the clean-up
committee which will probably continue on Wednesday morning. If
any of you have any last minute things to let me know about,
please send net mail before Saturday morning or contact me at the
hotel beginning Sunday. -- Bob
∂12-Mar-87 2210 RPG Final Attendee List
To: x3j13@SAIL.STANFORD.EDU
Here is the current list. See you Monday!
Registration/Hotel List
03/12/87
Name Company Check In Check Out Paid
John Allen The Lisp Co. -0- -0- y
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Richard Berman USC/ Information 03/16/87 03/19/87 y
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- y
Gary Brown Digital 03/15/87 03/18/87 y
Mike Cannon Hewlett-Packard -0- -0- y
Jerome Chailloux INRIA -0- -0- -
Chip Chapin Hewlet-Packard -0- -0- y
William Clinger Tektronics 03/16/87 03/18/87 y
Peter Coffee Aerospace Corp. 03/16/87 03/17/87 -
Pavel Curits Xerox AIS -0- -0- y
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 y
Andrew Daniels Xerox AIS -0- -0- y
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Jed Harris Intel -0- -0- y
Liz Heron IBM -0- -0- -
Carl Hewitt MIT 03/15/87 03/19/87 y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Sonya Keene Symbolics, Inc. -0- -0- y
Jim Kempf Hewlett-Packard -0- -0- y
Gregor Kiczales Xerox PARC -0- -0- -
Kevin Layer Franz Inc. -0- -0- y
Jim Lin IBM -0- -0- -
Thom Linden IBM -0- -0- y
Barry Margolin Thinking Machines 03/15/87 03/19/87 -
Larry Masinter Xerox PARC -0- -0- y
Bob Mathis 03/14/87 03/19/87 y
David Matthews Hewlett Packard -0- -0- y
David Moon Symbolics, Inc. -0- -0- y
Ronald Ohlander USC/ISI 03/17/87 03/18/87 y
Bob Pellegrino Prime Computer, 03/15/87 03/19/87 y
Crispin Perdue SUN MicroSystems -0- -0- y
Kent Pitman Symbolics -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
Angela Sodan GMD -0- -0- y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
Mark Wegman IBM T.J. Watson -0- -0- y
Dan Weinreb Symbolics, Inc. -0- -0- y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂13-Mar-87 0204 brown%bizet.DEC@decwrl.DEC.COM Technical Editor
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 13 Mar 87 02:04:49 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA08145; Fri, 13 Mar 87 02:05:31 PST
Message-Id: <8703131005.AA08145@decwrl.dec.com>
Date: Friday, 13 Mar 1987 02:03:29-PST
From: brown%bizet.DEC@decwrl.DEC.COM
To: x3j13@SAIL.STANFORD.EDU
Subject: Technical Editor
The major conclusion arrived at from thinking about writing the
standard is that a technical editor is required. This person's
job would be to convert CLTL to an approved format, distribute
copies, and incorporate approved changes and new material - basically
to control the sources to the standard. This is clearly a full-time job.
DEC is willing to hire someone to do this job for, at least, the
first year. However, before hiring someone to do it, we need to know
if this is acceptable to the committee. Please consider this offer,
and let me know when we meet next week.
-Gary Brown
∂13-Mar-87 0852 RPG Writer
To: x3j13@SAIL.STANFORD.EDU
This is the kind of spirit of volunteerism that is required to
make our task succeed. I encourage others to note this offer and
consider what they themselves can do.
Because this committee as a whole has oversight over the writer,
I can see no objections whatever. Possibly we'll want to nominate
an editor or two to work with the writer and exercise immediate
direction?
-rpg-
∂18-Mar-87 1341 MATHIS@ADA20.ISI.EDU draft minutes Palo Alto meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:40:27 PST
Date: 18 Mar 1987 13:40-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: draft minutes Palo Alto meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:40:53.MATHIS>
These are still quite rough, but Mary and I wanted to get them out fast.
Please send me your reactions and comments.
1:00pm ITEM 1 - Monday, March 16, 1987. Palo Alto meeting called to order.
ITEM 2 -Mathis - introductory remarks. New documents and missing Dallas
documents made available. Attendance book sent around. Introduction of
attendees.
ITEM 3 - March 16 agenda (X3J13/87-006) rearranged to bring forward points 8
and 9.
ITEM 4 - Sept 23-24 minutes (X3J13/86-025) sent out but had typos in names.
Corrections to other minutes will be noted in minutes of March 16-18
(X3J13/87-016)
ITEM 5 -Dec 10-12 minutes (X3J13/86-021) not yet available but should be
available by end of meeting.
ITEM 6
ISO ballot has been sent in, but the meeting is not planned until summer.
Anyone interested in joining the ISO working group is asked to contact Bob
Mathis. The size of the US delegation is planned to be about 6 people.
1:25pm ITEM 8 - Purposes of X3J13 Committee (X3J13/86-023 (revision of
X3J13/86-020))
1.
a. Guy Steele suggests changing "extensions" to "additional features".
Informal voice vote unanimously in favor.
b. Dave Moon concerned about phrase, "establishing normative practice".
Informal voice vote unanimously in favor of dropping phrase altogether.
"X3J13 is chartered to produce an American National Standard for Common
Lisp. It will codify existing practice and provide additional features to
facilitate portability of code among diverse implementations."
2.
a. Dave Matthews asks whether aesthetic criteria should exist at all.
Informal voice vote shows majority in favor of change in wording. Informal
voice vote unanimously in favor of Guy Steele's proposed wording change.
"The committee will begin with the language described in Common Lisp: The
Language by Guy L. Steele Jr. (Digital Press, 1984), which is the current
de facto standard for Common Lisp. Whenever there is a proposal for the
standard to differ from Common Lisp: The Language, the committee shall
weigh both future costs of adopting (or not adopting) a change and the
costs of conversion of existing code. Aesthetic considerations shall
also be weighed, but as subordinate criteria."
2:30pm - Comments by John McCarthy. Comments will be put into
future article for Lisp Pointers.
2:35pm - Break
ITEM 9 - Reports from Task Group Chairpeople
2:50pm - Bob Balzer, Rich Berman (ISI) - Validation Suite
Rich Berman described the current status of the test suite design. Format has
been designed and 550 tests converted into that format.
Bob Balzer described how ISI could run the test suite against a particular
implementation and produce a report of the results. The process is currently in
the Ad-hoc Stage for evaluation. Later stages will result in a managed test
suite. The effort is estimated to take 3.5 person-years to produce 25,000
normalized cases.
Discussion identified concern over the final use of the test suite (ie., for
implementors or for users), and over the extent of the effort devoted to
resolution of ambiguity in the language standard showed up by test cases.
The topic will be continued on Wednesday.
4:25pm - Professor Ida - Lisp Activities in Japan (X3J13/87-007)
4:40pm - Gary Brown (DEC)
Gary Brown has received permission from DEC to hire a technical writer to do
the actual creation of the standard, with copyright held by ANSI. The response
of the committee was enthusiastic applause.
4:50pm - Larry Masinter (Xerox) - Cleanup Committee
Current status (X3J13/87-010) describes status as of March, 1987 rather than
May, 1987. Distribution of language suggestions and changes through computer
networks was discussed, but not resolved. The discussion will be continued
Wednesday.
5:10pm - Meeting adjourned.
Tuesday, March 17, 1987. Palo Alto meeting called to order.
9:05am - Dan Bobrow, Opening Remarks
Common Lisp Object System Specification
1. Programmer Interface Concepts (X3J13/87-002)
2. Functions in the Programmer Interface (X3J13/87-002)
3. Meta Object Protocol (X3J13/87-003)
4. Glossary (X3J13/87-008)
5. Corrections and Amendments (X3J13/87-009)
9:10am - David Moon, "Common Lisp, Object System"
10:35am - Break
11:00am - Gregor Kiczales, "Programming with Meta-Objects"
1:05pm - Lunch Break
2:45pm - Dan Bobrow, "Meta Object Protocol"
4:00pm - Break
4:25pm - Questions and Answers on previous presentations
The discussion resulted in the decision to vote Wednesday morning on the X3J13
position on the work done to date on the Common Lisp Object System
Specification.
5:50pm - Meeting adjourned.
Wednesday, March 18, 1987. Palo Alto meeting called to order.
9:05am - Peter Coffee presented the wording of a motion which reflected the
discussion of Tuesday afternoon. The X3J13 committee unanimously voice voted
to have this moved. A majority voice vote determined that the motion would be
presented as three separate items with X3J13 document references.
On a motion by Peter Coffee, and a second by Mark Wegman, the
following formal motion was passed by unanimous voice vote.
Resolved by the National Technical Committee for Standardization of
Lisp (X3J13):
(1) The committee believes that object-oriented programming
will be incorporated as part of a future Common Lisp standard;
(2) The committee believes that Chapters 1 and 2 of the Common Lisp
Object System (CLOS) specification (collectively, X3J13 document 87-002)
captures the essentials of the future standard object facility.
The committee also looks forward to a refined version of CLOS
Chapter 3 (X3J13/87-003) that will similarly reflect the
essentials of a standard meta-object facility;
(3) The committee encourages experimentation with the object
system reflected in CLOS Chapters 1-3.
SUBCOMMITTEE REPORTS
9:30am - Jon L. White - Iteration Subcommittee
JonL described the work done to date of the committee on identifying several
iteration paradymes, and will create a preliminary document for distribution.
9:35am - Kent Pitman - Macros; Errors and Conditions Subcommittee
Kent described the continuing work on xx (X3J13/xxx), and felt that the work
was beginning to converge. It is expected that the converged design will
be presented at the next meeting.
9:40am - Rich Berman - Validation and Conformance Subcommittee
Rich summarized the presentation which he gave on Monday.
9:45am - Gary Brown - Presentation of Standard Subcommittee
Gary reiterated that the standard will be controlled by ANSI rules. The actual
creation of the document will be done by a technical writer who will be hired
by DEC. The text editing system used for this document will be TEX.
An editorial subcommmittee has been formed. The current volunteers are
Pavel, Margolin, Slater, Fahlman, Weinreb, Pitman, Linden, Ennis, and Ida.
Gary suggested that a formal definition of some parts of Common Lisp would
be valuable. The response of the committee indicated that further discussion
of this issue was needed.
10:05am - Dan Bobrow - Objects Subcommittee
Dan thanked the committee for their feedback on the CLOS design.
10:07am - Dick Gabriel - Lisp 1/Lisp 2 Subcommittee
The topic has been temporarily quiescent, due to subcommittee members
being involved elsewhere.
10:10am - Steve Haflich - Compiler Specification Subcommittee.
A large amount of work has been done on a specification document. The subcommittee is intending to stop and look at
the more global issues of what their task encompasses and how they should
approach the problems.
10:20am - Bob Mathis - NEXT MEETING PLANNING
The consensus of the committee was to have a two full day meeting on
Tuesday (10am - 6pm) and Wednesday (9am - 4pm), June 30th and July 1st.
Subcommittees were encouraged to meet on Monday afternoon.
10:35am - Break
11:00am - Bob Mathis - FUTURE MEETING PLANNING
Susan Ennis has agreed to act as a clearinghouse for information on
possible meeting sites and times.
ll:00am - Larry Masinter - Cleanup Subcommittee
Bob Mathis will create a message to the Common Lisp mailing list describing the
standardization process. He will reiterate that the X3J13 committee is open,
but that it is only within X3J13 that the technical discussions will occur.
The discussion considered the ways in which the cleanup proposals would be
presented to the committee for final voting. When proposals are presented
in the future, Larry will identify those which are potentially controversial.
Proposals will be presented to the committee in advance of the meeting.
After a proposal has been accepted, the editorial committee will give
direction to the technical writer for incorporation into the standard.
12:00 noon - Final Meeting Adjournment
∂18-Mar-87 1342 MATHIS@ADA20.ISI.EDU meeting documents
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:42:25 PST
Date: 18 Mar 1987 13:43-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting documents
Subject: [MATHIS@ADA20.ISI.EDU: minutes first meeting]
Subject: [MATHIS@ADA20.ISI.EDU: document register]
Subject: [MATHIS@ADA20.ISI.EDU: Purposes document]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:43:03.MATHIS>
These messages were printed and distributed Wednesday morning at the meeting.
Begin forwarded messages
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:04:40-PST
Date: 17 Mar 1987 23:04-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: minutes first meeting
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:04:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
DRAFT Minutes X3J13 Committee Meeting
Dates: September 23-24, 1986
Location: CBEMA Headquarters, Washington, DC
Chair: Bob Mathis (acting)
Secretary: Steve Haflich (acting)
Hour of opening: September 23, 1986, 9:00 AM
Hour of adjournment: September 24, 1986, 3:00 PM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None (this was first meeting)
Register of Documents: Attached
Motions seconded and not withdrawn:
Future meeting schedule:
The next meeting is scheduled for Decmeber 10-12, 1986, in
Dallas, TX. Ellen Waldrum will make the arrangements.
List of action items assigned to committee members:
Mathis will contact DEC Press about using the Steele book as a
basis for the standard
The meeting was called to order at 10:00 AM, September 23, 1986.
The agenda, X3J13/86-001, was approved without objection.
Catherine Kachuric, Director of the X3 Secretariat presented a
tutorial on the organization and operation of X3. Most of the
details are codified in the X3/SD-2 operating document which was
distributed at the meeting.
Mathis led a discussion of meeting procedures:
1. by consensus it was decided there will be no smoking in
X3J13 meeting rooms;
2. each meeting will focus on one or more technical issues
with prepared presentations, it is necessary that the
membership be well prepared technically in advance of
meetings so that final discussions and voting can be
facilitated during scarce meeting time;
3. Gabriel will set up a new mailing list which will function
as a subset of the existing COMMON-LISP@SAIL.STANFORD.EDU,
and therefore nothing should be sent to both lists. Also,
anything with a time limit for action should be sent to
X3J13, not COMMON-LISP, as not all members will read the
latter in a timely fashion. Addresses are:
X3J13@SAIL.STANFORD.EDU
X3J13-REQUEST@SAIL.STANFORD.EDU
RPG@SAIL.STANFORD.EDU
4. Mathis can be reached at MATHIS@B.ISI.EDU. Since only a
few members lack internet access, the committee will
consider using electronic mail for discussion. Mathis will
attempt to arrange network access for members in need.
All written X3 subcommittee communications are distributed to
everybody and are filed as part of the official records. There
was discussion whether this would apply to electronic mail to
x3j13@Stanford. Some people feel that network comments are made
informally and are similar to oral communications; therefore,
they should not be available as a written record. There was a
conflicting desire that the archives be publically available
(e.g. via FTP) since this has proven useful with
COMMON-LISP@STANFORD. It was provisionally agreed that the
archives would be maintained, but for now they would not be
publically accessible.
There was further discussion of how to bypass one of the
shortcomings of electronic communication -- the volume of the
archive makes it a poor reference source and decisions can get
lost. Therefore, it was oproposed that when discussion on a point
dies down there should be a summarization of discussion placed in
a small, more readable ledger and this document would be recorded
and distributed by X3J13.
Mathis requested a committee to further consider the use of
network communication: Mathis, Pitman, Fahlman, Rosenking, and
Haflich.
Mathis led a discussion of the project proposal (subsequently
given the number X3J13/SD-2.
The title is "Common Lisp" rather than "Lisp" although this could
be changed with little effort. The scope of the committee is one
of the items that will have to be decised. There was general
agreement that we are standardizing Common Lisp, not all Lisp for
all time. Gabriel informed the meeting that McCarthy objects to
our using plain "Lisp." It is intended that X3J13 will subsume
the less formal technical committee formed after the December
1985 Boston meeting.
Several parties were interested in the relationship with Digital
Press over rights to use the Steele book. Considerable discussion
occurred with the eventual result that Mathis would work directly
with Digital Press to make appropriate arrangements.
After a lunch recess, the meeting reconvened at 2:30 PM.
Dan Bobrow made an introductory presentation on Common Loops.
[The preliminary document for this presentation was 86-004 and
the slides from it were distributed as 86-006.] Discussion of
Common loops followed, particularly regarding the nature of a
specification and the best process for arriving at one. There
will be a small meeting at OOPSLA on the current proposal and a
new draft will follow.
Mathis reported that Mary van Deusen has volunteered to produce
an unedited Lisp newsletter in the same manner that she produced
the original Ada newsletter. It was also noted that Gabriel and
Steele will also be editing a professional refereed quarterly for
Kliewer. Both publications felt there was no conflict.
There was some technical discusison of removing function-value
cell separation from Common Lisp. Discussion was started
explicitly to serve a s a trial vehicle to focus on the extent to
which the committee would be willing to make changes that would
disrupt the installed base. This discussion will be continued at
future meetings.
A subcommittee, chaired by Ennis, was formed to develop a draft
document for the proposed scope and purposes of X3J13. They met
over dinner and during the evening. Their draft [86-005] was
presented the next morning.
The meeting was recessed on September 23, 1986 at 5:15 PM.
The meeting was resumed on September 24, 1986 at 9:00 AM.
Steele led a discussion of his two documents relating to SD-1
[Common Lisp: The Language] which were first distributed at the
December 1985 Common Lisp community meeting [86-002 and 86-003].
The intention is that once a version of 86-002 is approved, all
references to SD-1 will mean the Steele book "as corrected."
There was considerable discussion on the various topics, but no
specific issues were resolved at the meeting.
After a lunch recess, the meeting reconvened at 1:00 PM.
Mathis led a discussion of a potential meeting schedule. Several
offers were made including MCC Austin, MIT Boston, and TI Dallas.
After a discussion of optimizing meeting location, timing,
length, etc., it was decisded to meet in Dallas, December 10-12.
There was also sentiment expressed for the next meeting to be in
Palo Alto and the one after that in Boston.
Mathis asked the following to serve as an agenda committee for
the next meeting: Mathis, Fahlman, Gabriel, Purdue, Ennis,
Steele, and Scherlis. Furthermore, these items were suggested as
natural for the next agenda:
-- studying the possibility of merging symbol function cells
in Common Lisp with value cells (like Scheme),
-- Pitman will presnet the error system proposal,
-- further consideration of the current scoping and
declaration issues (the intention is to devise a proposal
over the network to be disteributed before the meeting),
-- the ongoing negotiations with ISO.
The meeting was adjourned on September 24, 1986 at 3:00 PM.
Respectfully Submitted,
Steve Haflich and Bob Mathis
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:10:04-PST
Date: 17 Mar 1987 23:10-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: document register
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:10:01.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
Standing Documents (date of latest revision)
SD-01 Common Lisp: The Language, Guy L. Steele Jr., Digital
Press, 1984.
SD-02 Common Lisp Project Prosal to SPARC (86.02.18)
SD-03 Current Membership List of X3J13 (in preparation)
SD-04 Meeting Schedule (87.02.10)
SD-05 Purposes of X3J13 Committee (87.03.16)
This year's Documents
87-000 Document Register for 1987 (87.03.17)
87-001 Document Register for 1986 (87.02.10)
87-002 Objects Chapter 1 & 2
87-003 Objects Chapter 3
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
87-006 Cover letter dated 87.02.10 which included 86-017,
86-018, 86-019, 86-020R, 86-023, 86-024, 87-000, 87-001,
87-004, 87-005, SD-04.
87-007 A Progress Report on the Common Lisp Related Activities
in Japan by Masayuki Ida.
87-008 Common Lisp Object System Specification Glossary
87-009 Common Lisp Object System Specification Corrections and
Amendments to the Document
87-010 Cleanup Committee Report
87-011 "Encapsulation and Inheritance in Object-Oriented
Programming Languages" by Alan Snyder, OOPSLA, 1986.
87-012 Slides from David Moon's presentation 87.03.17
87-013 Slides from Gregor Kiczales's presentation 87.03.17
87-014 Slides from Danny Bobrow's presentation 87.03.17
87-015 Further reactions to 86-019
87-016 Draft Minutes Palo Alto meeting 87.03.16-18
87-017 Cover letter dated 87.03.29 which included
87-018
87-019
Next year's Documents
88-000 Document Register for 1988
88-001 Document Register for 1987
88-002
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:14:39-PST
Date: 17 Mar 1987 23:14-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: Purposes document
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:14:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
X3J13/SD-05 Purposes of X3J13 Committee (87.03.16)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice and provide
additional features to facilitate portability of code among
diverse implementations.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic considerations shall also be weighed,
but as subordinate criteria.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
--------------------
End forwarded messages
∂20-Mar-87 1345 primerd!doug@enx.prime.pdn Windows and Graphics Subcommittee
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Mar 87 13:45:07 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA27326@EDDIE.MIT.EDU>; Fri, 20 Mar 87 16:45:27 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA00379; Fri, 20 Mar 87 15:42:59 EST
Message-Id: <8703202042.AA00379@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 20 Mar 87 14:41:51 EST
Subject: Windows and Graphics Subcommittee
To: x3j13@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 20 Mar 87 14:41:51 EST
I would like to make known that there is a mailing list for the
windows and graphics subgroup. To subscribe you can send mail
to me as dougr@eddie.mit.edu. The mailing list is
x3j13-windows@primerd.prime.com@eddie.mit.edu
Cheers,
Doug Rand
∂23-Mar-87 1130 berman@vaxa.isi.edu Gary Brown...
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 11:29:08 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA05051; Mon, 23 Mar 87 11:30:48 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703231930.AA05051@vaxa.isi.edu>
Date: 23 Mar 1987 1130-PST (Monday)
To: X3J13@SAIL
Cc:
Subject: Gary Brown...
I tried to send you mail at brown%bizet.DEC@decwrl.dec.com, but no luck, says
host not known. You got another address??
RB
∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87 00:42:15 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07982; 20 Apr 87 3:41 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab14315; 20 Apr 87 3:34 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA08435; Mon, 20 Apr 87 16:42:07 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA14916; Mon, 20 Apr 87 16:33:09+0900
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704200733.AA14916@tansei.u-tokyo.junet>
To: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the Kanji feature of Common Lisp
Dear Bob Mathis,
Please suggest your idea on the contents of this mail.
Thank you.
Masayuki
--------------------------------------------------------
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
2) Prior to do so, One of the author, namely ida, will send
the whole contents to common-lisp@sail.stanford to get
reactions of the US colleagues.
3) The proposed date of submission to CL bboard is
on the week of May 11th.
4) We are ready to send a person to the next meeting
to explain our proposal.
5) The reactions on the CL bboard will be gathered, and will
be transfered to WG members as quick as possible.
(several of them have E-mail links to ida.)
We will try to discuss on the issue by E-mails as possible as we can.
(we have no ethernet-like link to USA, so we cannot reply immediately.)
we finished the first draft of the english version.
It was mainly translated by the person of Nippon Symbolics.
(Thanks Mr.Shiota.)
The size is 12 pages long in letter sized papers.
We will revise up and send it.
Masayuki Ida
∂20-Apr-87 2253 dcm%hpfclp@hplabs.HP.COM Fall X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 22:53:25 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Mon, 20 Apr 87 21:53:46 pst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Mon, 20 Apr 87 23:52:41 mst
Received: by hpfcdcm.HP.COM; Mon, 20 Apr 87 22:53:41 mst
Date: Mon, 20 Apr 87 22:53:41 mst
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
Return-Path: <dcm@hpfcdcm>
Message-Id: <8704210553.AA03000@hpfcdcm.HP.COM>
To: +cl/x3j13@hplabs.HP.COM, x3j13@sail.stanford.edu
Subject: Fall X3J13 meeting
It probably seems a little early to start thinking about our fall meeting,
but I thought I would take an informal survey to help make the necessary
arrangements so we can confirm them at the summer meeting.
At the last X3J13 meeting, Susan Ennis volunteered to coordinate the
meeting schedule and I volunteered to host the fall meeting of X3J13
in colorful Colorado. We recently talked about the schedule for the
fall meeting and there seem to be a number of conferences that
time of year. We would like to pick a time convenient to as many
members as possible so I would like to conduct a survey.
Three months after the next meeting in late June would be late September
so I would nominally suggest September 28-30. Please fill out the
following table of available dates, listing the conflict if you believe
that others on the committee may have it also, such as OOPSLA.
Dates: MTWTF(y/n) Conflict?
------------- ----- ---------------------
Sep 21-Sep 25
Sep 28-Oct 2 yyyyy Example
Oct 5-Oct 9
Oct 12-Oct 16
Oct 19-Oct 23
Hopefully this range of dates will be sufficient for choosing 3 days.
I'll use this information to make preliminary arrangements and have a
proposal ready at the next meeting. Please return this by May 29.
Thanks,
Dave Matthews
dcm%hpfclp@hplabs.hp.com
∂21-Apr-87 0821 RWK@YUKON.SCRC.Symbolics.COM On the Kanji feature of Common Lisp
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:21:20 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195935; Tue 21-Apr-87 07:24:34 EDT
Date: Tue, 21 Apr 87 07:24 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: On the Kanji feature of Common Lisp
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
cc: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8704200733.AA14916@tansei.u-tokyo.junet>
Message-ID: <870421072404.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
Professor Ida:
I believe it doesn't do it justice to describe this extension as a
"kanji extension". I have not yet seen an English translation of the
proposal, but from what I have seen of it, it appears to address much
wider concerns. I believe the concerns are quite relevant to any
implementation which deals with extended character-sets, or even which
try to make use of Common-Lisp's unfortunate "font" features.
From what I've been able to make of the proposal, it seems you are
on the right track, and I eagerly await your proposal.
∂23-Apr-87 0106 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the character-set extension of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87 01:06:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13110; 23 Apr 87 4:02 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab04744; 23 Apr 87 3:54 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA27855; Thu, 23 Apr 87 16:04:19 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA04391; Thu, 23 Apr 87 15:55:22+0900
Date: Thu, 23 Apr 87 15:55:22+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704230655.AA04391@tansei.u-tokyo.junet>
To: RWK@SCRC-YUKON.ARPA, ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the character-set extension of Common Lisp
>Date: Tue, 21 Apr 87 07:24 EDT
>From: "Robert W. Kerns" <RWK@scrc-yukon.arpa>
>Subject: On the Kanji feature of Common Lisp
>To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
>
> Date: Mon, 20 Apr 87 16:33:09+0900
> From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
> On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
> Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
>
>Professor Ida:
>
>I believe it doesn't do it justice to describe this extension as a
>"kanji extension". I have not yet seen an English translation of the
>proposal, but from what I have seen of it, it appears to address much
>wider concerns. I believe the concerns are quite relevant to any
>implementation which deals with extended character-sets, or even which
>try to make use of Common-Lisp's unfortunate "font" features.
>
>>From what I've been able to make of the proposal, it seems you are
>on the right track, and I eagerly await your proposal.
>
>
Dear RWK,
you are right. I should have not described our conclusion on the extended
character-set manipulation as "kanji extension".
Though I myself told the WG on the Apr 17 meeting to update our document
to use the word "multi-byte character"
instead of "japanese character" or "kanji",
I myself missed to refer it as a "kanji" extension in my last mail.
Thank you
Masayuki Ida
∂15-May-87 0436 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Next Meeting
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 15 May 87 04:36:33 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 15 May 87 06:35:50-CDT
Date: Fri, 15 May 87 06:34 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Next Meeting
To: X3J13%sail.stanford.edu@MCC.COM
cc: Loeffler@MCC.COM
Message-ID: <870515063459.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
I have not seen any activity on this mailing list since the 23th of
April. What are the arrangements for the next meeting?
-- David D. Loeffler
∂31-May-87 0903 MATHIS@ADA20.ISI.EDU
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:03:19 PDT
Date: 31 May 1987 09:02-PDT
Sender: MATHIS@ADA20.ISI.EDU
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: RWS@ZERMATT.LCS.MIT.EDU
Message-ID: <[ADA20.ISI.EDU]31-May-87 09:02:47.MATHIS>
A few words about the upcoming X3J13 meeting:
The meeting is being hosted by Goldhill Computers. Maria Santos
is making the arrangements. Their phone number is (617)
492-2071. They are reserving some rooms at the Cambridge Marriott
at a rate of $115 (plus tax) per night (insead of the more usual
$135). There will be some fee for refreshments and maybe a lunch.
I don't know what it will be, but at the last two meetings we
paid $25 or $50. The meeting will be on Tuesday June 30 and
Wednesday July 1. We will be meeting from about 9am to 5pm each
day. There may be some subcommittee meetings on Monday. They are
hoping to arrange some meeting rooms at MIT, but I don't know the
specifics yet. Hope you can all make it.
I was thinking about the following agenda:
Tuesday morning -- clean-up committee
Tuesday afternoon -- X windows presentation, Japanese
characters presentation, administrative work of committee,
reports from various subcommittees and liaisons
Wednesday morning -- continuation of subcommittee reports
and other business, clean-up committee
Wednesday afternoon -- clean-up committee
We picked Tuesday and Wednesday for the main meeting so we could
use Monday for subcommittees if needed.
The X windows presentation will be by Robert Scheifler. We are
not looking at this for incorporation into the Common Lisp
standard, but as an important and relevant related application.
CLX is a proposed interface to the X Version 11 Window System
Protocol. It is intended as fairly low-level veneer, to hide
mundane details such as data encodings, network I/O, and even the
existance of an explicit inter-process communication channel.
The intent is to provide direct access to features of the
protocol, but with an effective Lisp orientation, and with
consideration given to convenience of use. A goal was to permit
efficient implementations on both conventional and Lisp-specific
architectures, and to provide reasonable semantics in both
single-process and multi-process environments. The expectation
and desire is that this X-specific interface will be wrapped by
more generic and higher-level windowing and graphics interfaces,
suitable for general application programming. However, we did
not wish to preclude an X-specific, object-oriented system built
directly on this interface. A public implementation of this
interface is underway, to serve as a mechanism for evaluating the
interface.
I am sending five relatively long messages which I recieved from
Scheifler which give the protocol and the Lisp code.
The Japanese characters proposal was sent to the general Common
Lisp mailing list. I am retransmitting it for your reference.
The cleanup committee has been hard at work and they will shortly
be sending their documents. So read what I'm sending now and save
it some place because more is coming.
-- Bob
∂31-May-87 0915 MATHIS@ADA20.ISI.EDU A multi-byte character extension proposal
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:47 PDT
Return-Path: <@USC-ECLB.ARPA,@SAIL.STANFORD.EDU,@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Date: Mon, 18 May 87 14:06:46+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180506.AA06726@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: A multi-byte character extension proposal
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
Date: Mon, 18 May 87 09:44:19 JST
From: moto@XXX.XXX.junet (MOTOYOSHI)
To: ida@tansei.cc.u-tokyo.junet
Subject: Kanji Proposal
-------------------- Beginning of text --------------------
@Comment[-*- Mode: Text -*-]
@heading[Digest]
@heading[1. Hierarcy of characters and strings]
Let the value of char-code-limit be large enough to include all
characters.
char > string-char >= internal-string-char > standard-char
string >= internal-thin-string > simple-internal-thin-string
simple-string >= simple-internal-thin-string
string = (or internal-thin-string (vector string-char))
Type internal-thin-string and (vector string-char) are
disjoint or identical.
simple-string = (or simple-internal-thin-string
(simple-array string-char (*)))
Type simple-internal-thin-string and (simple-array
string-char (*)) are disjoint or identical.
notes: A > B means B is a subtype of A,
A >= B means B is a subtype of A or B is equal to A.
@Heading[2. Print width]
Only standard characters are required to have fix-pitched
print width. Use the newly introdued function 'write-width'
to know the print width of an expression.
@Heading[3. Functions]
Functions dealing with strings should work as before,
expect ones which change the contents of internal-thin-string
to non internal-thin-char's.
Functions producing strings should create (vector
string-char), not internal-thin-string, unless they were
explicitly specified.
Funtions comaring strings should copare them elementwise.
Therefore it is possible that a (vector string-char) is equal
to an internal-thin-string.
@newpage
@Heading[1. A proposal for embedding multi-byte characters]
The Kanji Working Group (KWG) examined implementation of facilities for
multi-byte character to Common Lisp. This report is the result of many
discussions of many proposals. Of course, this report doesn't satisfy
all proposals, but it is very close.
In order to decide on a final proposal, we chose essential and
desirable characteristics of a working multi-byte character system.
Chapter 2 describes these characteristics in some detail.
Chapter 3 describes additional features to Common Lisp which will be useful
not just for multi-byte character, but also for many other kinds of character sets.
This chapter describes internal data structures. If this proposal is
accepted in Common Lisp, it will be easy for countries to add original mechanisms.
Chapters 4 describes proposed changes to @I[Common Lisp -- The Language]
(CLtL).
@Heading[2. Additional features for embedding multi-byte characters.]
This chapter describes design principles which can be used to design
multi-byte character language extensions to Common Lisp.
There are many programming languages which can multi-byte characters.
Most of them can use multi-byte character as string character data
but not as variables or function names.
It is necessary for programming languages like Lisp that use symbolic data
to be able to process not only single-byte characters but also multi-byte characters.
That is, it should be possible to use multi-byte characters in character string and
symbols, and it must be possible to store both kinds of characters in them.
Treating multi-byte characters just like other alpha-numeric characters
means that multi-byte character must be treated as a single character object.
Many of the present implementations of Lisp treat multi-byte character as
pairs of bytes. Alternatively, they use a different data type which
doesn't permit multi-byte character to be mixed with standard characters.
Such systems are not useful for user.
Thus, the basic design principles for embedding multi-byte character to Common Lisp are:
@Begin[Itemize]
Multi-byte character should be treated like single-byte character, that is,
a multi-byte character is one character object.
@End[Itemize]
@Begin[Itemize]
A program which was coded without explicit attention for multi-byte character should
handle multi-byte character data as is.
@End[Itemize]
These principles provide sufficient functionality, but we can't ignore
efficiency. So we considered the next principle:
@Begin[Itemize]
The performance of the system in terms of CPU and memory
utilization should not be consideraly affected in programs which do not use multi-byte
characters.
@End[Itemize]
This principle is contradictory to other principles, but this can't be
ignored when we consider the users of actual systems, so we have to
compromise. We think that following methods will satisfy both of these
requirements.
@Heading[3. Common parts which we implement.]
This chapter describes the implementation of multiple character sets in Common Lisp.
To treat multi-byte characters like single-byte characters, the multi-byte character must be
included in the set of possible character codes.
We consider the following implementation methods.
@Begin[Itemize]
Add multi-byte characters by setting the variable char-code-limit to a large number.
@End[Itemize]
In this case, the single-byte character set and the multi-byte character
set must be ordered into a single sequence of character codes. This means multi-byte
character set must not overlap with the single-byte character set. This method could
be satisfied within most implementations with ease.
If we use this method, it is possible to use multi-byte characters with
fonts in Common Lisp, and operations that work for single-byte
character will also work for multi-byte character without any change.
This implementation method has problems with efficiency.
In the case that the value of character code is greater than size of 1 byte
(multi-byte characters are in this category), memory utilization is
affected. A string containing only one single-byte character is 2 bytes long.
The same problem would also occur with symbol p-names. If we can solve the problem
for strings, we can solve other problems, so we will start by considering only strings.
To avoid this memory utilization problem, it is possible to optimize and
make single-byte character strings by packing internally. In other words,
to have two kinds of data types and not show it to user. There is only one type of
data from the viewpoint of users, which means that every function which uses strings
will continue to work as defined.
This can be implemented in almost everywhere without so many costs. The only
problem occurs when a function attempts to put a multi-byte character into an optimized
and packed sigle-byte-only string. To work according to the definition, the implementation
must unpack the original packed string. This presents an implementation inefficiency which
the user may find undesirable.
One solution would be to
@Begin[Itemize]
Generate errors for operations that try to use multi-byte characters into
single-byte string and presenting two string datatypes to users.
@End[Itemize]
We propose this latter implementation. Common lisp should have 2 string
types to treat multi-byte characters efficiently. The first of these is
@b[ε1stringε0], which stores any character of type @B[ε1string-charε0], i.e.,
whose @I[ε2bitsε0] and @I[ε2fontε0] are both zero. The type of string is
@B[ε1internal-thin-stringε0] which is the optimized character string.
@B[ε1internal-thin-charε0] is a subtype of @B[ε1characterε0] and can be inserted into string
@B[ε1internal-thin-stringε0]. The predicate which tests for this type of character is
@B[ε1internal-thin-char-pε0].
The type @B[ε1internal-thin-charε0] is a subtype of @B[ε1string-charε0], and is a
supertype of @B[ε1standard-charε0].
The data type hierarchy for @B[ε1characterε0] and @B[ε1stringε0] is shown in figure 1.
@b[ε1Internal-thin-charε0] and @b[ε1string-charε0] may be equal as it is possible that situations
may arise where both sets describe the same character-set.
This is equivalent to the type of system that has only one type of character from the
viewpoint of the user as discussed in the previous chapter. This proposal permits both
kinds of implementations.
@newpage
@Begin[Verbatim]
character
|
string-char
|
internal-thin-char
|
standard-char
@Center[Fig-1.a Structure of character type]
string
|
-----------------------------------
| | |
| simple-string |
| | |
internal-thin-string | (vector string-char)
| | |
-----------------------------------
| |
| |
simple-internal-thin-string (simple-array string-char (*))
@Center[Fig-1.b Structure of string type]
@End[Verbatim]
To compare @B[ε1stringε0] characters with @B[ε1internal-thin-stringε0] characters, it is
necessary to convert both to the @B[ε1string-charε0] format. This means that
the same character is the same object regardless of whether it is found
in an @B[ε1internal-thin-stringε0] or a normal @B[ε1stringε0].
Next we must discuss character input. The proposal does not discuss what is stored
in files, nor what happens between the Lispimplementation and a terminal.
Each system will implement this in itsown way. Instead, let us discuss the data
as passed to lisp programs. We think that treating all input data as @B[ε1stringε0]
is the safest possible course. Since a symbol's p-name string should not be modified,
it can be optimized.
This may cause performance problems for programs which use only
single-byte characters. The variable @B[ε1*read-default-string-type*ε0] is
provided for these programs. When its value is @B[ε1internal-thin-stringε0], the system
expects single-byte characters only. so the system will return input data
in the form of @B[ε1internal-thin-stringε0]. Though it is possible that the system may
choose to ignore this variable.
@newpage
@Heading[4 Proposed changes to CLtL to support multiple character sets.]
In this section, we list proposed modifications to CLtL. Chapters 13,
14 and 18 of CLtL are concerned very greatly with multi-byte character, so we specify
modifications to these chapters by making a list of all constants,
functions and variables. For other chapters we specify only additional
and modifying parts. Those portions which are not mentioned are
unchanged.
@b(2 Data Types)
@b(2.5.2 Strings)
@begin(equation)
"a string is a specialized vector .... type string-char"
↓
"a string is a specialized vector .... type string-char or @B[internal-thin-char]"
@end(equation)
@b(2.15 Overlap,Inclusion and Disjointness of Types)
a description of type string-char is changed to :
Type standard-char is a subtype of @B[internal-thin-char].
@B[internal-thin-char] is a subtype of string-char. string-char is a
subtype of character.
and add the following :
Type @B[internal-thin-string] is a subtype of vector because @B[internal-thin-string] means
(vector internal-thin-char).
a description of type string is changed to :
Type string is a subtype of vector because string means (or
(vector string-char) internal-thin-string). Type (vector
string-char) and @B[internal-thin-string] are disjoint or equality.
a description of type simple-vector,simple-string ... is changed to :
Type simple-vector,simple-string and simple-bit-vector are disjoint subtype of
simple-array because each one means (simple-array t (*)),
(or (simple-array string-char (*)),(or (simple-array internal-thin-char (*)) and
(simple-array bit (*)).
and add following :
Type simple-internal-thin-string means (simple-array
internal-thin-char (*)) and is a subtype of @B[internal-thin-string].
Type (simple-array string-char (*)) and simple-internal-thin-string are disjoint or
equality.
@b(4 Type Specifiers)
@b(4.1 Type Specifier Symbols)
add followings to system defined type specifiers :
simple-internal-thin-string
internal-thin-string
internal-thin-char
@b(4.5 Type Specifiers That Specialize)
"The specialized types (vector string-char) ... data types."
↓
"The specialized types (vector internal-thin-char), (vector
string-char) and (vector bit) are so useful that they have the
special names string and bit-vector. Every implementation of Common
Lisp must provide distinct representation for string and bit-vector
as distinct specialized data types."
@begin(equation)
@b(13 Characters)
@b(13.1 Character Attributes)
char-code-limit@>[constant]
char-font-limit@>[constant]
char-bits-limit@>[constant]
@b(13.2 Predicates on Characters)
standard-char-p char@>[constant]
graphic-char-p char@>[constant]
@begin(quotation)
a description "graphic characters of font 0 are all of the same width when printed" in
the CLtL changed to "standard-char without #\Newline of font 0 are all of the same
width when printed".
@end(quotation)
string-char-p char @>[function]
internal-thin-char-p char@>[function]
@begin(quotation)
this function must be added.
the argument char must be a character object. internal-thin-char-p
is true if char can be stored into a internal-thin-string, and
otherwise is false.
@end(quotation)
alpha-char-p char@>[function]
upper-case-p char@>[function]
lower-case-p char@>[function]
both-case-p char@>[function]
"If a character is either ... alphabetic."
↓
"If a character is either uppercase or lowercase, it is necessarily character
that alpha-char-p returns true."
digit-char-p char &optional (radix 10)@>[function]
alphanumericp char@>[function]
char= character &rest more-characters@>[function]
char/= character &rest more-characters@>[function]
char< character &rest more-characters@>[function]
char> character &rest more-characters@>[function]
char<= character &rest more-characters@>[function]
char>= character &rest more-characters@>[function]
char-equal character &rest more-characters@>[function]
char-not-equal character &rest more-characters@>[function]
char-lessp character &rest more-characters@>[function]
char-greaterp character &rest more-characters@>[function]
char-not-greaterp character &rest more-characters@>[function]
char-not-lessp character &rest more-characters@>[function]
@b(13.3 Character Construction and Selection)
char-code char@>[function]
char-bits char@>[function]
char-font char@>[function]
code-char char &optional (bits 0) (font 0)@>[function]
make-char char &optional (bits 0) (font 0)@>[function]
@b(13.4 Character Conversion)
character char@>[function]
char-upcase char@>[function]
char-downcase char@>[function]
digit-char weight &optional (radix 10) (font 0)@>[function]
char-int char@>[function]
int-char char@>[function]
char-name char@>[function]
name-char char@>[function]
@b(13.5 Character control-bit functions)
char-control-bit@>[constant]
char-meta-bit@>[constant]
char-super-bit@>[constant]
char-hyper-bit@>[constant]
char-bit char name@>[function]
set-char-bit char name newvalue@>[function]
@b(14 Sequence)
@b(14.1 Simple sequence functions)
elt sequence index@>[Function]
subseq sequence start &optional end@>[Function]
copy-seq sequence@>[Function]
length sequence@>[Function]
reverse sequence@>[Function]
nreverse sequence@>[Function]
make-sequence type size &key :initial-element@>[Function]
@b(14.2 Sequence connection)
concatenate result-type &rest sequences@>[Function]
map result-type function sequence &rest more-sequences@>[Function]
some predicate sequence &rest more-sequences@>[Function]
every predicate sequence &rest more-sequences@>[Function]
notany predicate sequence &rest more-sequences@>[Function]
notevery predicate sequence &rest more-sequences@>[Function]
reduce function sequence@>[Function]
&key :from-end :start :end :initial-value
@b(14.3 Sequence correction)
fill sequence item &key :start :end@>[Function]
replace sequence1 sequence2 &key :start1 :end1 :start2 :end2@>[Function]
remove item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
delete item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
delete-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
subsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
subsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
subsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
nsubsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
@b(14.4 Search)
find item sequence @>[Function]
&key :from-end :test :test-not
:start :end :key
find-if test sequence @>[Function]
&key :from-end :start :end :key
find-if-not test sequence>[Function]
&key :from-end :start :end :key
position item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
position-if test sequence@>[Function]
&key :from-end :start :end :key
position-if-not test sequence@>[Function]
&key :from-end :start :end :key
count item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
count-if item sequence@>[Function]
&key :from-end :start :end :key
count-if-not item sequence@>[Function]
&key :from-end :start :end :key
mismatch sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
search sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
@b(14.5 Sort,merge)
sort sequence predicate &key :key@>[Function]
stable-sort sequence predicate &key :key@>[Function]
merge result-type sequence1 sequence2 predicate &key :key@>[Function]
@b(18 Strings)
"the type string is identical ... (array string-char (*))."
↓
"the type string is identical to the type
(or (vector internal-thin-char) (vector string-char)),
which in turn is the same as (or (array internal-thin-char (*))
(array string-char (*)))."
@b(18.3 String Construction and Manipulation)
make-string size &key :initial-element@>[function]
@begin(quotation)
add following :
To make an internal-thin-string, you should use make-array or make-sequence.
@end(quotation)
@b(22 Input/Output)
@b(22.2 Input Functions)
@b(22.2.1 Output to Character Stream)
add following :
*read-default-string-type*@>[variables]
@begin(quotation)
The value is string or internal-thin-string. This determines string that the function
read takes whether type string or internal-thin-string.
@end(quotation)
@b(22.3 Output Functions)
@b(22.3.1 Output from Character Stream)
@begin(quotation)
add following :
@end(quotation)
write-width object@>[function]
&key :unit-type :stream :escape :radix :base
:circle :pretty :label :length :case :gensym :array
@begin(quotation)
This function returns the printed width as the value of the unit
specified by :unit-type when then printed representation of
object is written to the output stream specified by :stream. It
returns nil when object includes control characters
(#\Newline,#\Tab etc). The default of :unit-type is byte. The
value which we can specify :unit-type depends on implementation.
@end(quotation)
@end(equation)
@newpage
@Heading[Appendix Proposed Japanese character processing facilities for Common Lisp.]
In addition to the modification of CLtL, here are some suggestions for systems
including Japanese characters.
1). How should system behave for Japanese characters both
under unmodified part of CLtL and the part changed for multi-byte
processing.
2). About function that are specific to Japanese and no at all related
to multi-byte processing.
Notes: All Japanese characters are constituent. JIS is a abreviation of Japanese Industry
Standard.
@begin(equation)
@b(13. Characters)
@b(13.1. Character Attributes)
char-code-limit char @>[Function]
@begin(quotation)
The value of char-code-limit should be large enough to include Japanese characters,
e.g. 65536.
@end(quotation)
@b(13.2. Predicates on Characters)
standard-char-p char @>[Function]
@begin(quotation)
Return nil for all Japanese characters.
@end(quotation)
graphic-char-p char @>[Function]
@begin(quotation)
Return t for Japanese characters.
@end(quotation)
internal-thin-char-p char @>[Function]
@begin(quotation)
The result depends on each implementation that whether the Japanese character is in
internal-thin-string or not.
@end(quotation)
alpha-char-p char @>[Function]
@begin(quotation)
Return nil for all character except alphabets in Japanese character. It depends on
each implementation whether to return t or nil for alphabets in Japanese characters.
@end(quotation)
@newpage
jis-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. jis-char-p is true if the
argument is included in JIS C-6226, and otherwise false.
@end(quotation)
japanese-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. japanese-char-p is true if the
argument is a Japanese character and is otherwise false. All characters that satisfy
jis-char-p must satisfy japanese-char-p; other characters might.
@end(quotation)
kanji-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object. kanji-char-p is true if the
argument is one of the 6353 Kanji characters in JIS C6226(3.1.8), the repeat symbol,
the kanji numeric zero or the same as above symbol for a total of 6356 characters
that also satisfy jis-char-p.
@end(quotation)
hiragana-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object.
hiragana-char-p is true if the argument is one of the 83
hiragana characters in JIS C6226(3.1.4), the hiragana repeat
symbol, or dakuten for a total of 85 characters that also
satisfy jis-char-p.
@end(quotation)
katakana-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object.
katakana-char-p is true if the argument is one of the 86
hiragana characters in JIS C6226(3.1.5), long-sound-symbol,
katakana-repeat symbol, or katakana-dakuten for a total of 89
characters that also satisfy jis-char-p.
@end(quotation)
kana-char-p char@>[Function]
@begin(quotation)
equivalence (or (hiragana-char-p char) (katakana-char-p char))
@end(quotation)
upper-case-p char@>[Function]
lower-case-p char@>[Function]
both-case-p char@>[Function]
@begin(quotation)
These are nil if the argument does not satisfy alpha-char-p.
Japanese characters which satisfy alpha-char-p should be treated
as normal alphabetic characters.
@end(quotation)
@newpage
digit-char-p char &optional (radix 10)@>[Function]
@begin(quotation)
digit-char-p is nil if the argument is a Japanese character.
@end(quotation)
alphanumericp char@>[Function]
@begin(quotation)
equivalence (or (alpha-char-p char) (not (null (digit-char-p char))))
@end(quotation)
char= character &rest more-characters@>[Function]
char/= character &rest more-characters@>[Function]
char< character &rest more-characters@>[Function]
char> character &rest more-characters@>[Function]
char<= character &rest more-characters@>[Function]
char>= character &rest more-characters@>[Function]
@begin(quotation)
The ordering of hiragana, katakana, kanji follows the JIS ordering.
@end(quotation)
@b(13.4 character Conversions)
char-upcase char@>[Function]
char-downcast char@>[Function]
@begin(quotation)
These return the argument if the argument does not satisfy
alpha-char-p. It depends on the implementation whether these
work on the alphabets included in JIS or not. But it should be
consistent with upper-case-p, lower-case-p, both-case-p.
@end(quotation)
@end(equation)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 1 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:13:44 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 1 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095642.5.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-
;; Draft Version 3.1 (corresponds to Alpha Update protocol document)
;; Author:
;; Robert W. Scheifler
;; Laboratory for Computer Science
;; 545 Technology Square, Room 418
;; Cambridge, MA 02139
;; rws@zermatt.lcs.mit.edu
;; Contributors:
;; Dan Cerys, Texas Instruments
;; Scott Fahlman, CMU
;; Kerry Kimbrough, Texas Instruments
;; Chris Lindblad, MIT
;; Rob MacLachlan, CMU
;; Mike McMahon, Symbolics
;; David Moon, Symbolics
;; LaMott Oren, Texas Instruments
;; Daniel Weinreb, Symbolics
;; John Wroclawski, MIT
;; Richard Zippel, Symbolics
;; Note: all of the following is in the package XLIB.
;; Note: various perversions of the CL type system are used below.
;; Examples: (list elt-type) (sequence elt-type)
(proclaim '(declaration arglist values))
;; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
;; the relationships should be fairly obvious. We have no intention of writing yet
;; another moby document for this interface.
;; Types employed: display, window, pixmap, cursor, font, gcontext, colormap, color.
;; These types are defined solely by a functional interface; we do not specify
;; whether they are implemented as structures or flavors or ... Although functions
;; below are written using DEFUN, this is not an implementation requirement (although
;; it is a requirement that they be functions as opposed to macros or special forms).
;; It is unclear whether with-slots in the Common Lisp Object System must work on
;; them.
;; Windows, pixmaps, cursors, fonts, gcontexts, and colormaps are all represented as
;; compound objects, rather than as integer resource-ids. This allows applications
;; to deal with multiple displays without having an explicit display argument in the
;; most common functions. Every function uses the display object indicated by the
;; first argument that is or contains a display; it is an error if arguments contain
;; different displays, and predictable results are not guaranteed.
;; Each of window, pixmap, cursor, font, gcontext, and colormap have the following
;; five functions:
(defun make-<mumble> (display resource-id)
;; This function should almost never be called by applications, except in handling
;; events. To minimize consing in some implementations, this may use a cache in
;; the display. Make-gcontext creates with :cache-p nil. Make-font creates with
;; cache-p true.
(declare (type display display)
(type integer resource-id)
(values <mumble>)))
(defun <mumble>-display (<mumble>)
(declare (type <mumble> <mumble>)
(values display)))
(defun <mumble>-id (<mumble>)
(declare (type <mumble> <mumble>)
(values integer)))
(defun <mumble>-equal (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)))
(defun <mumble>-p (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)
(values boolean)))
;; The following functions are provided by color objects:
;; The intention is that IHS and YIQ and CYM interfaces will also exist. Note that
;; we are explicitly using a different spectrum representation than what is actually
;; transmitted in the protocol.
(defun make-color (&key red green blue &allow-other-keys) ; for expansion
(declare (type (number 0 1) red green blue)
(values color)))
(defun color-rgb (color)
(declare (type color color)
(values red green blue)))
(defun color-red (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-green (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-blue (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(deftype resource-id () 'integer)
(deftype drawable () '(or window pixmap))
;; Atoms are accepted as strings or symbols, and are always returned as keywords.
;; Protocol-level integer atom ids are hidden, using a cache in the display object.
(deftype xatom () '(or string symbol))
(deftype stringable () '(or string symbol))
(deftype fontable () '(or stringable font))
;; Nil stands for CurrentTime.
(deftype timestamp () '(or null integer))
(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype grab-status ()
'(member :success :already-grabbed :frozen :invalid-time :not-viewable))
(deftype boolean () '(or null (not null)))
;; An association list.
(deftype alist (key-type-and-name datum-type-and-name) 'list)
;; A sequence, containing zero or more repetitions of the given elements,
;; with the elements expressed as (type name).
(deftype repeat-seq (&rest elts) 'sequence)
(deftype point-seq () '(repeat-seq (integer x) (integer y)))
(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))
(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))
;; Note that we are explicitly using a different angle representation than what
;; is actually transmitted in the protocol.
(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))
(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
(angle angle1) (angle angle2)))
(deftype event-mask-class ()
'(member :key-press :key-release :owner-grab-button :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :exposure :visibility-change
:structure-notify :resize-redirect :substructure-notify :substructure-redirect
:focus-change :property-change :colormap-change :keymap-state))
(deftype event-mask ()
'(or integer (list event-mask-class)))
(deftype pointer-event-mask-class ()
'(member :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :keymap-state))
(deftype pointer-event-mask ()
'(or integer (list pointer-event-mask-class)))
(deftype device-event-mask-class ()
'(member :key-press :key-release :button-press :button-release :pointer-motion
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion))
(deftype device-event-mask ()
'(or integer (list device-event-mask-class)))
(deftype modifier-key ()
'(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))
(deftype modifier-mask ()
'(or (member :any) integer (list modifier-key)))
(deftype state-mask-key ()
'(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))
(deftype gcontext-key ()
'(member :function :plane-mask :foreground :background
:line-width :line-style :cap-style :join-style :fill-style :fill-rule
:arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
:exposures :clip-x :clip-y :clip-mask :clip-ordering
:dash-offset :dashes))
(deftype event-key ()
'(member :key-press :key-release :button-press :button-release :motion-notify
:enter-notify :leave-notify :focus-in :focus-out :keymap-notify
:exposure :graphics-exposure :no-exposure :visibility-notify
:create-notify :destroy-notify :unmap-notify :map-notify :map-request
:reparent-notify :configure-notify :gravity-notify :resize-request
:configure-request :circulate-notify :circulate-request :property-notify
:selection-clear :selection-request :selection-notify
:colormap-notify :client-message))
(deftype error-key ()
'(member :access :alloc :atom :colormap :cursor :drawable :font :gcontext :id-choice
:illegal-request :implementation :length :match :name :pixmap :property
:value :window))
(deftype draw-direction ()
'(member :left-to-right :right-to-left))
(defstruct bitmap-format
(unit <unspec> :type (member 8 16 32))
(pad <unspec> :type (member 8 16 32))
(lsb-first-p <unspec> :type boolean))
(defstruct pixmap-format
(depth <unspec> :type integer)
(bits-per-pixel <unspec> :type (member 4 8 16 32))
(pad <unspec> :type (member 8 16 32)))
(defstruct visual-info
(id <unspec> :type integer)
(class <unspec> :type (member :static-gray :static-color :true-color
:gray-scale :pseudo-color :direct-color))
(red-mask <unspec> :type integer)
(green-mask <unspec> :type integer)
(blue-mask <unspec> :type integer)
(bits-per-rgb <unspec> :type integer)
(colormap-entries <unspec> :type integer))
(defstruct screen
(root <unspec> :type window)
(device <unspec> :type integer)
(width <unspec> :type integer)
(height <unspec> :type integer)
(width-in-millimeters <unspec> :type integer)
(height-in-millimeters <unspec> :type integer)
(depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
(root-depth <unspec> :type integer)
(root-visual <unspec> :type integer)
(default-colormap <unspec> :type colormap)
(white-pixel <unspec> :type integer)
(black-pixel <unspec> :type integer)
(min-installed-maps <unspec> :type integer)
(max-installed-maps <unspec> :type integer)
(backing-stores <unspec> :type (member :never :when-mapped :always))
(save-unders-p <unspec> :type boolean)
(event-mask-at-open <unspec> :type integer))
;; To allow efficient storage representations, the type char-info is not
;; required to be a structure.
(defun char-left-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-right-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-width (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-ascent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-descent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-attributes (char-info)
(declare (type char-info char-info)
(values integer)))
;; The list contains alternating keywords and integers.
(deftype font-props () 'list)
(defstruct font-info
(name <unspec> :type string)
(direction <unspec> :type draw-direction)
(min-char <unspec> :type integer)
(max-char <unspec> :type integer)
(min-byte1 <unspec> :type integer)
(max-byte1 <unspec> :type integer)
(min-byte2 <unspec> :type integer)
(max-byte2 <unspec> :type integer)
(all-chars-exist-p <unspec> :type boolean)
(default-char <unspec> :type integer)
(min-bounds <unspec> :type char-info)
(max-bounds <unspec> :type char-info)
(ascent <unspec> :type integer)
(descent <unspec> :type integer)
(properties <unspec> :type font-props))
(defun open-display (host &key (display 0) protocol)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; and protocol are not constrained, and will likely be very system dependent. The
;; default protocol is system specific. Authorization, if any, is assumed to come
;; from the environment somehow.
(declare (type integer display)
(values display)))
(defun display-protocol-version (display)
;; Values are integers.
(declare (type display display)
(values major minor)))
(defun display-vendor (display)
;; Values are string and integer
(declare (type display display)
(values name release)))
(defun display-image-lsb-first-p (display)
(declare (type display display)
(values boolean)))
(defun display-bitmap-formap (display)
(declare (type display display)
(values bitmap-format)))
(defun display-pixmap-formats (display)
(declare (type display display)
(values (list pixmap-formats))))
(defun display-roots (display)
(declare (type display display)
(values (list screen))))
(defun display-keyboard (display)
(declare (type display display)
(values integer)))
(defun display-pointer (display)
(declare (type display display)
(values integer)))
(defun display-motion-buffer-size (display)
(declare (type display display)
(values integer)))
(defun display-max-request-length (display)
(declare (type display display)
(values integer)))
(defun close-display (display)
(declare (type display display)))
(defun display-error-handler (display)
(declare (type display display)
(values handler)))
(defsetf display-error-handler (display) (handler)
;; All errors (synchronous and asynchronous) are processed by calling an error
;; handler in the display. If handler is a sequence it is expected to contain
;; handler functions specific to each error; the error code is used to index the
;; sequence, fetching the appropriate handler. Any results returned by the handler
;; are ignored; it is assumed the handler either takes care of the error
;; completely, or else signals. For all core errors, the keyword/value argument
;; pairs are:
;; :display display
;; :error-key error-key
;; :major integer
;; :minor integer
;; :sequence integer
;; :current-sequence integer
;; For :colormap, :cursor, :drawable, :font, :gcontext, :id-choice, :pixmap, and
;; :window errors another pair is:
;; :resource-id integer
;; For :atom errors, another pair is:
;; :atom-id integer
;; For :value errors, another pair is:
;; :value integer
(declare (type display display)
(type (or (sequence (function (&rest key-vals)))
(function (&rest key-vals)))
handler)))
(defmacro define-condition (name base &body items)
;; just a place-holder here for the real thing
)
(define-condition request-error error
display
major
minor
sequence
current-sequence)
(defun default-error-handler (&rest key-vals)
;; The default display-error-handler.
;; It signals the conditions listed below.
)
(define-condition resource-error request-error
resource-id)
(define-condition access-error request-error)
(define-condition alloc-error request-error)
(define-condition atom-error request-error
atom-id)
(define-condition colormap-error resource-error)
(define-condition cursor-error resource-error)
(define-condition drawable-error resource-error)
(define-condition font-error resource-error)
(define-condition gcontext-error resource-error)
(define-condition id-choice-error resource-error)
(define-condition illegal-request-error request-error)
(define-condition implementation-error request-error)
(define-condition length-error request-error)
(define-condition match-error request-error)
(define-condition name-error request-error)
(define-condition pixmap-error resource-error)
(define-condition property-error request-error)
(define-condition value-error request-error
value)
(define-condition window-error resource-error)
(defmacro with-display ((display) &body body)
;; This macro is for use in a multi-process environment. It provides exclusive
;; access to the local display object for multiple request generation. It need not
;; provide immediate exclusive access for replies; that is, if another process is
;; waiting for a reply (while not in a with-display), then synchronization need not
;; (but can) occur immediately. Except where noted, all routines effectively
;; contain an implicit with-display where needed, so that correct synchronization
;; is always provided at the interface level on a per-call basis. Nested uses of
;; this macro will work correctly. This macro does not prevent concurrent event
;; processing; see with-event-queue.
)
(defun display-force-output (display)
;; Output is normally buffered; this forces any buffered output.
(declare (type display display)))
(defun display-finish-output (display)
;; Forces output, then causes a round-trip to ensure that all possible errors and
;; events have been received.
(declare (type display display)))
(defun display-after-function (display)
;; setf'able
;; If defined, called after every protocol request is generated, even those inside
;; explicit with-display's, but never called from inside the after-function itself.
;; The function is called inside the effective with-display for the associated
;; request. Default value is nil. Can be set, for example, to
;; #'display-force-output or #'display-finish-output.
(declare (type display display)
(values (or null (function (display))))))
(defun create-window (&key parent x y width height (depth 0) (border-width 0)
(class :copy) (visual :copy)
background border gravity bit-gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
colormap cursor)
;; Display is obtained from parent. Only non-nil attributes are passed on in the
;; request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
(declare (type window parent)
(type integer x y width height depth border-width)
(type (member :copy :input-output :input-only) class)
(type (or (member :copy) visual) visual)
(type (or null (member :none :parent-relative) integer pixmap) background)
(type (or null (member :copy) integer pixmap) border)
(type (or null win-gravity) gravity)
(type (or null bit-gravity) bit-gravity)
(type (or null (member :not-useful :when-mapped :always) backing-store))
(type (or null integer) backing-planes backing-pixel)
(type (or null event-mask) event-mask)
(type (or null device-event-mask) do-not-propagate-mask)
(type (or null (member :on :off)) save-under override-redirect)
(type (or null (member :copy) colormap) colormap)
(type (or null (member :none) cursor) cursor)
(values window)))
(defun window-class (window)
(declare (type window window)
(values (member :input-output :input-only))))
(defun window-visual (window)
(declare (type window window)
(values integer)))
(defsetf window-background (window) (background)
(declare (type window window)
(type (or (member :none :parent-relative) integer pixmap) background)))
(defsetf window-border (window) (border)
(declare (type window window)
(type (or (member :copy) integer pixmap) border)))
(defun window-gravity (window)
;; setf'able
(declare (type window window)
(values win-gravity)))
(defun window-bit-gravity (window)
;; setf'able
(declare (type window window)
(values bit-gravity)))
(defun window-backing-store (window)
;; setf'able
(declare (type window window)
(values (member :not-useful :when-mapped :always))))
(defun window-backing-planes (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-backing-pixel (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-save-under (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-event-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-do-not-propagate-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-override-redirect (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-colormap (window)
(declare (type window window)
(values (or null colormap))))
(defsetf window-colormap (window) (colormap)
(declare (type window window)
(type (or (member :copy) colormap) colormap)))
(defsetf window-cursor (window) (cursor)
(declare (type window window)
(type (or (member :none) cursor) cursor)))
(defun window-colormap-installed-p (window)
(declare (type window window)
(values boolean)))
(defun window-all-event-masks (window)
(declare (type window window)
(values integer)))
(defun window-map-state (window)
(declare (type window window)
(values (member :unmapped :unviewable :viewable))))
(defsetf drawable-x (window) (x)
(declare (type window window)
(type integer x)))
(defsetf drawable-y (window) (y)
(declare (type window window)
(type integer y)))
(defsetf drawable-width (window) (width)
;; Inside width, excluding border.
(declare (type window window)
(type integer width)))
(defsetf drawable-height (window) (height)
;; Inside height, excluding border.
(declare (type window window)
(type integer height)))
(defsetf drawable-border-width (window) (border-width)
(declare (type window window)
(type integer border-width)))
(defsetf window-priority (window &optional sibling) (mode)
;; A bit strange, but retains setf form.
(declare (type window window)
(type (or null window) sibling)
(type (member :above :below :top-if :bottom-if :opposite) mode)))
(defmacro with-state ((drawable) &body body)
;; Allows a consistent view to be obtained of data returned by GetWindowAttributes
;; and GetGeometry, and allows a coherent update using ChangeWindowAttributes and
;; ConfigureWindow. The body is not surrounded by a with-display. Within the
;; indefinite scope of the body, on a per-process basis in a multi-process
;; environment, the first call within an Accessor Group on the specified drawable
;; (the object, not just the variable) causes the complete results of the protocol
;; request to be retained, and returned in any subsequent accessor calls. Calls
;; within a Setf Group are delayed, and executed in a single request on exit from
;; the body. In addition, if a call on a function within an Accessor Group follows
;; a call on a function in the corresponding Setf Group, then all delayed setfs for
;; that group are executed, any retained accessor information for that group is
;; discarded, the corresponding protocol request is (re)issued, and the results are
;; (again) retained, and returned in any subsequent accessor calls.
;; Accessor Group A (for GetWindowAttributes):
;; window-visual, window-class, window-gravity, window-bit-gravity,
;; window-backing-store, window-backing-planes, window-backing-pixel,
;; window-save-under, window-colormap, window-colormap-installed-p,
;; window-map-state, window-all-event-masks, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect
;; Setf Group A (for ChangeWindowAttributes):
;; window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
;; window-backing-pixel, window-save-under, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect, window-colormap,
;; window-cursor
;; Accessor Group G (for GetGeometry):
;; drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
;; drawable-height, drawable-border-width
;; Setf Group G (for ConfigureWindow):
;; drawable-x, drawable-y, drawable-width, drawable-height, drawable-border-width,
;; window-priority
)
(defun destroy-window (window)
(declare (type window window)))
(defun destroy-subwindows (window)
(declare (type window window)))
(defun add-to-save-set (window)
(declare (type window window)))
(defun remove-from-save-set (window)
(declare (type window window)))
(defun reparent-window (window parent x y)
(declare (type window window parent)
(type integer x y)))
(defun map-window (window)
(declare (type window window)))
(defun map-subwindows (window)
(declare (type window window)))
(defun unmap-window (window)
(declare (type window window)))
(defun unmap-subwindows (window)
(declare (type window window)))
(defun circulate-window-up (window)
(declare (type window window)))
(defun circulate-window-down (window)
(declare (type window window)))
(defun drawable-root (drawable)
(declare (type drawable drawable)
(values drawable)))
(defun drawable-depth (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-x (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-y (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-width (drawable)
;; For windows, inside width, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-height (drawable)
;; For windows, inside height, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-border-width (drawable)
(declare (type drawable drawable)
(values integer)))
(defun query-tree (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence window) parent root)))
(defun change-property (window property data type format
&key (mode :replace) (start 0) end transform)
;; Start and end affect sub-sequence extracted from data.
;; Transform is applied to each extracted element.
(declare (type window window)
(type xatom property type)
(type (member 8 16 32) format)
(type sequence data)
(type (member :replace :prepend :append) mode)
(type integer start)
(type (or null integer) end)
(type (or null (function (t) integer)) transform)))
(defun delete-property (window property)
(declare (type window window)
(type xatom property)))
(defun get-property (window property
&key type (start 0) end delete-p (result-type 'list) transform)
;; Transform is applied to each integer retrieved.
(declare (type window window)
(type xatom property)
(type (or null xatom) type)
(type integer start)
(type (or null integer) end)
(type boolean delete-p)
(type type result-type)
(type (or null (function (integer) t)) transform)
(values data type format bytes-after)))
(defun rotate-properties (window properties &optional (delta 1))
;; Postive rotates left, negative rotates right (opposite of actual protocol request).
(declare (type window window)
(type (sequence xatom) properties)
(type integer delta)))
(defun list-properties (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence keyword))))
;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.
(defun intern-atom (display name)
(declare (type display display)
(type xatom name)
(values integer)))
(defun find-atom (display name)
(declare (type display display)
(type xatom name)
(values (or null integer))))
(defun atom-name (display atom-id)
(declare (type display display)
(type integer atom-id)
(values keyword)))
(defun selection-owner (display selection)
(declare (type display display)
(type xatom selection)
(values (or null window))))
(defsetf selection-owner (display selection &optional time) (owner)
;; A bit strange, but retains setf form.
(declare (type display display)
(type xatom selection)
(type (or null window) owner)
(type timestamp time)))
(defun convert-selection (selection type requestor &optional property time)
(declare (type xatom selection type)
(type window requestor)
(type (or null xatom) property)
(type timestamp time)))
(defun send-event (window event-key event-mask &rest args
&key propagate-p display &allow-other-keys)
;; Additional arguments depend on event-key, and are as specified further below
;; with declare-event, except that both resource-ids and resource objects are
;; accepted in the event components. The display argument is only required if the
;; window is :pointer-window or :input-focus.
(declare (type (or window (member :pointer-window :input-focus)) window)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)
(type (or null display) display)))
(defun grab-pointer (window event-mask
&key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
(declare (type window window)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)
(type timestamp time)
(values grab-status)))
(defun ungrab-pointer (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-button (window button event-mask
&key (modifiers 0)
owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)))
(defun ungrab-button (window button &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)))
(defun change-active-pointer-grab (display event-mask &optional cursor time)
(declare (type display display)
(type pointer-event-mask event-mask)
(type (or null cursor) cursor)
(type timestamp time)))
(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type timestamp time)
(values grab-status)))
(defun ungrab-keyboard (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun ungrab-key (window key &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun allow-events (display mode &optional time)
(declare (type display display)
(type (member :async-pointer :sync-pointer :reply-pointer
:async-keyboard :sync-keyboard :replay-keyboard)
mode)
(type timestamp time)))
(defun grab-server (display)
(declare (type display display)))
(defun ungrab-server (display)
(declare (type display display)))
(defmacro with-server-grabbed ((display) &body body)
;; The body is not surrounded by a with-display.
)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 2 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:09 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 2 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095718.6.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
(defun query-pointer (window)
(declare (type window window)
(values x y same-screen-p child mask root-x root-y root)))
(defun pointer-position (window)
(declare (type window window)
(values x y same-screen-p)))
(defun global-pointer-position (display)
(declare (type display display)
(values root-x root-y root)))
(defun motion-events (window &key start stop (result-type 'list))
(declare (type window window)
(type timestamp start stop)
(type type result-type)
(values (repeat-seq (integer x) (integer y) (timestamp time)))))
(defun translate-coordinates (src src-x src-y dst)
;; If src and dst are not on the same screen, nil is returned.
(declare (type window src)
(type integer src-x src-y)
(type window dst)
(values dst-x dst-y child)))
(defun warp-pointer (dst dst-x dst-y)
(declare (type window dst)
(type integer dst-x dst-y)))
(defun warp-pointer-if-inside (dst dst-x dst-y src src-x src-y
&optional src-width src-height)
;; Passing in a zero src-width or src-height is a no-op. A null src-width or
;; src-height translates into a zero value in the protocol request.
(declare (type window dst src)
(type integer dst-x dst-y src-x src-y)
(type (or null integer) src-width src-height)))
(defun set-input-focus (display focus revert-to &optional time)
;; Setf ought to allow multiple values.
(declare (type display display)
(type (or (member :none :pointer-root) window) focus)
(type (member :none :parent :pointer-root) revert-to)
(type timestamp time)))
(defun input-focus (display)
(declare (type display display)
(values focus revert-to)))
(defun query-keymap (display)
(declare (type display display)
(values (bit-vector 256))))
(defun open-font (display name &optional (cache-p t))
;; Font objects may be cached and reference counted locally within the display
;; object. This function might not execute a with-display if the font is cached.
;; The protocol QueryFont request happens on-demand under the covers. If cache-p
;; is nil, QueryFont results are never cached locally.
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(values font)))
(defun font-cache-p (font)
;; setf'able
(declare (type font font)
(values boolean)))
(defun font-font-info (font)
(declare (type font font)
(values font-info)))
;; For each component (<name> <unspec> :type <type>) of font-info,
;; there is a corresponding function:
(defun font-<name> (font)
(declare (type font font)
(values <type>)))
(defun font-property (font name)
(declare (type font font)
(type keyword name)
(values (or null integer))))
(defun font-char-infos (font)
(declare (type font font)
(values (array char-info))))
(defun font-char-info (font char)
(declare (type font font)
(type integer char)
(values (or null char-info))))
(defun font-char16-info (font first-byte second-byte)
(declare (type font font)
(type integer first-byte second-byte)
(values (or null char-info))))
(defun close-font (font)
;; This might not generate a protocol request if the font is reference counted
;; locally.
(declare (type font font)))
(defun text-extents (font string)
(declare (type (or font gcontext) font)
(type string string)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text16-extents (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text-width (font string)
(declare (type (or font gcontext) font)
(type string string)
(values integer)))
(defun text16-width (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values integer)))
(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence string))))
(defun list-fonts-with-info (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence font-info))))
(defun font-path (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence (or string pathname)))))
(defsetf font-path (display) (paths)
(declare (type display display)
(type (sequence (or string pathname)) paths)))
(defun create-pixmap (&key width height depth drawable)
(declare (type integer width height depth)
(type drawable drawable)
(values pixmap)))
(defun free-pixmap (pixmap)
(declare (type pixmap pixmap)))
(defun create-gcontext (&key drawable function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
(cache-p t))
;; Only non-nil components are passed on in the request, but for effective caching
;; assumptions have to be made about what the actual protocol defaults are. For
;; all gcontext components, a value of nil causes the default gcontext value to be
;; used. For clip-mask, this implies that an empty rect-seq cannot be represented
;; as a list. Note: use of stringable as font will cause an implicit open-font.
;; Note: papers over protocol SetClipRectangles and SetDashes special cases. If
;; cache-p is true, then gcontext state is cached locally, and changing a gcontext
;; component will have no effect unless the new value differs from the cached
;; value. Component changes (setfs and with-gcontext) are always deferred
;; regardless of the cache mode, and sent over the protocol only when required by a
;; local operation or by an explicit call to force-gcontext-changes.
(declare (type drawable drawable)
(type (or null boole-constant) function)
(type (or null integer) plane-mask foreground background line-width
ts-x ts-y clip-x clip-y dash-offset)
(type (or null (member :solid :dash :double-dash)) line-style)
(type (or null (member :not-last :butt :round :projecting)) cap-style)
(type (or null (member :miter :round :bevel)) join-style)
(type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
(type (or null (member :even-odd :winding)) fill-rule)
(type (or null (member :chord :pie-slice)) arc-mode)
(type (or null pixmap) tile stipple)
(type (or null fontable) font)
(type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
(type (or null (member :on :off)) exposures)
(type (or null (member :none) pixmap rect-seq) clip-mask)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or null (or integer (sequence integer))) dashes)
(type (or null integer) dash-offset)
(type boolean cache)
(values gcontext)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type <type> <name>), there is an accessor:
(defun gcontext-<name> (gcontext)
;; The value will be nil if the last value stored is unknown (e.g., the cache was
;; off, or the component was copied from a gcontext with unknown state).
(declare (type gcontext gcontext)
(values <type>)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type (or null <type>) <name>), there is a setf for the corresponding accessor:
(defsetf gcontext-<name> (gcontext) (value)
(declare (type gcontext gcontext)
(type <type> value)))
(defun gcontext-clip-mask (gcontext)
(declare (type gcontext gcontext)
(values (or null (member :none) pixmap rect-seq)
(or null (member :unsorted :y-sorted :yx-sorted :yx-banded)))))
(defsetf gcontext-clip-mask (gcontext &optional ordering) (clip-mask)
;; Is nil illegal here, or is it transformed to a vector?
;; A bit strange, but retains setf form.
(declare (type gcontext gcontext)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or (member :none) pixmap rect-seq) clip-mask)))
(defun force-gcontext-changes (gcontext)
;; Force any delayed changes.
(declare (type gcontext gcontext)))
(defmacro with-gcontext ((gcontext &key
function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dashes dash-offset)
&body body)
;; Changes gcontext components within the dynamic scope of the body (i.e.,
;; indefinite scope and dynamic extent), on a per-process basis in a multi-process
;; environment. The body is not surrounded by a with-display. If cache-p is nil
;; or the some component states are unknown, this will implement save/restore by
;; creating a temporary gcontext and doing copy-gcontext-components to and from it.
)
(defun copy-gcontext-components (src dst &rest keys)
(declare (type gcontext src dst)
(type (list gcontext-key) keys)))
(defun copy-gcontext (src dst)
(declare (type gcontext src dst))
;; Copies all components.
)
(defun free-gcontext (gcontext)
(declare (type gcontext gcontext)))
(defun clear-area (window &key (x 0) (y 0) width height exposures-p)
;; Passing in a zero width or height is a no-op. A null width or height translates
;; into a zero value in the protocol request.
(declare (type window window)
(type integer x y)
(type (or null integer) width height)
(type boolean exposures-p)))
(defun copy-area (src gcontext src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y width height dst-x dst-y)))
(defun copy-plane (src gcontext plane src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y plane width height dst-x dst-y)))
(defun draw-point (drawable gcontext x y)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)))
(defun draw-points (drawable gcontext points &optional relative-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p)))
(defun draw-line (drawable gcontext x1 y1 x2 y2 &optional relative-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x1 y1 x2 y2)
(type boolean relative-p)))
(defun draw-lines (drawable gcontext points &key relative-p fill-p (shape :complex))
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p fill-p)
(type (member :complex :non-convex :convex) shape)))
(defun draw-segments (drawable gcontext segments)
(declare (type drawable drawable)
(type gcontext gcontext)
(type seg-seq segments)))
(defun draw-rectangle (drawable gcontext x y width height &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height)
(type boolean fill-p)))
(defun draw-rectangles (drawable gcontext rectangles &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type rect-seq rectangles)
(type boolean fill-p)))
(defun draw-arc (drawable gcontext x y width height angle1 angle2 &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height angle1 angle2)
(type boolean fill-p)))
(defun draw-arcs (drawable gcontext arcs &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type arc-seq arcs)
(type boolean fill-p)))
;; The following image routines are bare minimum. It may be useful to define some
;; form of "image" object to hide representation details and format conversions. It
;; also may be useful to provide stream-oriented interfaces for reading and writing
;; the data.
(defun put-raw-image (drawable gcontext data
&key (start 0) depth x y width height (left-pad 0) format)
;; Data must be a sequence of 8-bit quantities, already in the appropriate format
;; for transmission; the caller is responsible for all byte and bit swapping and
;; compaction. Start is the starting index in data; the end is computed from the
;; other arguments.
(declare (type drawable drawable)
(type gcontext gcontext)
(type (sequence integer) data)
(type integer start depth x y width height left-pad)
(type (member :bitmap :xy-pixmap :z-pixmap) format)))
(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
(result-type '(vector (unsigned-byte 8))))
;; If data is given, it is modified in place (and returned), otherwise a new
;; sequence is created and returned, with a size computed from the other arguments
;; and the returned depth. The sequence is filled with 8-bit quantities, in
;; transmission format; the caller is responsible for any byte and bit swapping and
;; compaction required for further local use.
(declare (type drawable drawable)
(type (or null (sequence integer)) data)
(type integer start x y width height plane-mask)
(type (member :xy-format z-format) format)
(values (sequence integer) depth visual)))
(defun draw-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-text (drawable gcontext items)
;; For 8-bit indexes only.
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (string string)
;; :font (fontable font)
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)))
(defun draw-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached. If bytes-p is nil,
;; then array should be an array of integers to be treated as 16-bit quantities,
;; otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type array array)
(type boolean bytes-p)))
(defun draw-text16 (drawable gcontext items &key bytes-p)
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (array array)
;; :font (fontable font)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)
(type boolean bytes-p)
(type (or null integer) end)))
(defun draw-image-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-image-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type array array)
(type boolean bytes-p)
(type (or null integer) end)))
(defun create-colormap (visual window &optional alloc-p)
(declare (type integer visual)
(type window window)
(type boolean alloc-p)
(values colormap)))
(defun free-colormap (colormap)
(declare (type colormap colormap)))
(defun copy-colormap-and-free (colormap)
(declare (type colormap colormap)
(values colormap)))
(defun install-colormap (colormap)
(declare (type colormap colormap)))
(defun uninstall-colormap (colormap)
(declare (type colormap colormap)))
(defun installed-colormaps (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence colormap))))
(defun alloc-color (colormap color)
(declare (type colormap colormap)
(type (or stringable color) color)
(values pixel screen-color exact-color)))
(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors planes)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) (sequence mask))))
(defun alloc-color-planes (colormap colors
&key (reds 0) (greens 0) (blues 0)
contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors reds greens blues)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) red-mask green-mask blue-mask)))
(defun free-colors (colormap pixels &optional (plane-mask 0))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type integer plane-mask)))
(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type integer pixel)
(type (or stringable color) spec)
(type boolean red-p green-p blue-p)))
(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
;; If stringables are specified for colors, it is unspecified whether all
;; stringables are first resolved and then a single StoreColors protocol request is
;; issued, or whether multiple StoreColors protocol requests are issued.
(declare (type colormap colormap)
(type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
(type boolean red-p green-p blue-p)))
(defun query-colors (colormap pixels &key (result-type 'list))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type type result-type)
(values (sequence color))))
(defun lookup-color (colormap name)
(declare (type colormap colormap)
(type stringable name)
(values screen-color true-color)))
(defun create-cursor (&key source mask x y foreground background)
(declare (type pixmap source)
(type (or null pixmap) mask)
(type integer x y)
(type color foreground background)
(values cursor)))
(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
foreground background)
(declare (type font source-font)
(type integer source-char)
(type (or null font) mask-font)
(type (or null integer) mask-char)
(type color foreground background)
(values cursor)))
(defun free-cursor (cursor)
(declare (type cursor cursor)))
(defun recolor-cursor (cursor foreground background)
(declare (type cursor cursor)
(type color foreground background)))
(defun query-best-cursor (width height display)
(declare (type integer width height)
(type display display)
(values width height)))
(defun query-best-tile (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-best-stipple (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-extension (display name)
(declare (type display display)
(type stringable name)
(values major-opcode first-event first-error)))
(defun list-extensions (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence string))))
(defun keyboard-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(define-condition device-busy error)
(defsetf keyboard-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-keyboard-control (display &key key-click-percent
bell-percent bell-pitch bell-duration
led led-mode key auto-repeat-mode)
(declare (type display display)
(type (or null (member :default) integer) key-click-percent
bell-percent bell-pitch bell-duration)
(type (or null integer) led key)
(type (or null (member :on :off)) led-mode)
(type (or null (member :on :off :default)) auto-repeat-mode)))
(defun keyboard-control (display)
(declare (type display display)
(values key-click-percent bell-percent bell-pitch bell-duration
led-mask global-auto-repeat auto-repeats)))
(defun bell (display &optional (percent-from-normal 0))
;; It is assumed that an eventual audio extension to X will provide more complete
;; control.
(declare (type display display)
(type integer percent-from-normal)))
(defun pointer-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(defsetf pointer-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-pointer-control (display &key acceleration threshold)
;; Acceleration is rationalized if necessary.
(declare (type display display)
(type (or null (member :default) number) acceleration)
(type (or null (member :default) integer) threshold)))
(defun pointer-control (display)
(declare (type display display)
(values acceleration threshold)))
(defun set-screen-saver (display timeout interval blanking exposures)
;; Setf ought to allow multiple values.
;; Timeout and interval are in seconds, will be rounded to minutes.
(declare (type display display)
(type (or (member :default) integer) timeout interval)
(type (member :yes :no :default) blanking exposures)))
(defun screen-saver (display)
;; Returns timeout and interval in seconds.
(declare (type display display)
(values timeout interval blanking exposures)))
(defun activate-screen-saver (display)
(declare (type display display)))
(defun reset-screen-saver (display)
(declare (type display display)))
(defun add-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun remove-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun access-hosts (display &key (result-type 'list))
;; The type of host objects returned is not constrained, except that the hosts must
;; be acceptable to add-access-host and remove-access-host.
(declare (type display display)
(type type result-type)
(values (sequence host) enabled-p)))
(defun access-control (display)
;; setf'able
(declare (type display display)
(values boolean)))
(defun close-down-mode (display)
;; setf'able
;; Cached locally in display object.
(declare (type display display)
(values (member :destroy :retain-permanent :retain-temporary))))
(defun kill-client (display resource-id)
(declare (type display display)
(type resource-id resource-id)))
(defun kill-temporary-clients (display)
(declare (type display display)))
(defun make-event-mask (&rest keys)
;; This is only defined for core events.
;; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
(declare (type (list event-mask-class) keys)
(values integer)))
(defun make-event-keys (event-mask)
;; This is only defined for core events.
(declare (type integer event-mask)
(values (list event-mask-class))))
(defun make-state-mask (&rest keys)
;; Useful for constructing modifier-mask, state-mask.
(declare (type (list state-mask-key) keys)
(values integer)))
(defun make-state-keys (state-mask)
(declare (type integer mask)
(values (list state-mask-key))))
(defmacro with-event-queue ((display) &body body)
;; Grants exclusive access to event queue.
)
(defun event-listen (display &optional (timeout 0))
(declare (type display display)
(type (or null number) timeout))
;; Returns the number of events queued locally, if any, else nil. Hangs waiting
;; for events, forever if timeout is nil, else for the specified number of seconds.
)
(defun process-event (display &key handler timeout peek-p discard-p force-output-p)
;; If force-output-p is true, first invokes display-force-output. Invokes handler
;; on each queued event until handler returns non-nil, and that returned object is
;; then returned by process-event. If peek-p is true, then the event is not
;; removed from the queue. If discard-p is true, then events for which handler
;; returns nil are removed from the queue, otherwise they are left in place. Hangs
;; until non-nil is generated for some event, or for the specified timeout (in
;; seconds, if given); however, it is acceptable for an implementation to wait only
;; once on network data, and therefore timeout prematurely. Returns nil on
;; timeout. If handler is a sequence, it is expected to contain handler functions
;; specific to each event class; the event code is used to index the sequence,
;; fetching the appropriate handler. Handler is called with raw resource-ids, not
;; with resource objects. The arguments to the handler are described further below
;; using declare-event.
(declare (type display display)
(type (or (sequence (function (&rest key-vals) t))
(function (&rest key-vals) t))
handler)
(type (or null number) timeout)
(type boolean peek-p)))
(defmacro event-case ((display &key timeout peek-p discard-p force-output-p)
&body clauses)
(declare (arglist (display &key timeout peek-p discard-p force-output-p)
(event-or-events ((&rest args) |...|) &body body) |...|))
;; If force-output-p is true, first invokes display-force-output. Executes the
;; matching clause for each queued event until a clause returns non-nil, and that
;; returned object is then returned by event-case. If peek-p is true, then the
;; event is not removed from the queue. If discard-p is true, then events for
;; which the clause returns nil are removed from the queue, otherwise they are left
;; in place. Hangs until non-nil is generated for some event, or for the specified
;; timeout (in seconds, if given); however, it is acceptable for an implementation
;; to wait only once on network data, and therefore timeout prematurely. Returns
;; nil on timeout. In each clause, event-or-events is an event-key or a list of
;; event-keys (but they need not be typed as keywords) or the symbol t or otherwise
;; (but only in the last clause). The keys are not evaluated, and it is an error
;; for the same key to appear in more than one clause. Args is the list of event
;; components of interest; corresponding values (if any) are bound to variables
;; with these names (i.e., the args are variable names, not keywords, the keywords
;; are derived from the variable names). An arg can also be a (keyword var) form,
;; as for keyword args in a lambda lists. If no t/otherwise clause appears, it is
;; equivalent to having one that returns nil.
)
(defmacro declare-event (event-codes &rest declares)
;; Used to indicate the keyword arguments for handler functions in process-event
;; and event-case. All process-event handlers can have (display display) and
;; (event-key event-key) as keyword arguments, and an event-case clause can also
;; have event-key as an argument.
(declare (arglist event-key-or-keys &rest (type &rest keywords))))
(declare-event (:key-press :key-release :button-press :button-release)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
;; for key-press and key-release, code is the keycode
;; for button-press and button-release, code is the button number
(integer code))
(declare-event :motion-notify
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
(boolean hint-p))
(declare-event (:enter-notify :leave-notify)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
((member :normal :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
(boolean focus-p))
(declare-event (:focus-in :focus-out)
(resource-id window)
((member :normal :while-grabbed :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
:pointer :pointer-root :none)
kind))
(declare-event :keymap-notify
(resource-id window)
((bit-vector 256) keymap))
(declare-event :exposure
(resource-id window)
(integer x y width height)
(boolean last-p))
(declare-event :graphics-exposure
(resource-id drawable)
(integer x y width height major minor)
(boolean last-p))
(declare-event :no-exposure
(resource-id drawable)
(integer major minor))
(declare-event :visibility-notify
(resource-id window)
((member :unobscured :partially-obscured :fully-obscured) state))
(declare-event :create-notify
(resource-id window parent)
(integer x y width height border-width)
(boolean override-redirect-p))
(declare-event :destroy-notify
(resource-id event-window window))
(declare-event :unmap-notify
(resource-id event-window window)
(boolean configure-p))
(declare-event :map-notify
(resource-id event-window window)
(boolean override-redirect-p))
(declare-event :map-request
(resource-id parent window))
(declare-event :reparent-notify
(resource-id event-window window parent)
(integer x y)
(boolean override-redirect-p))
(declare-event :configure-notify
(resource-id event-window window)
(integer x y width height border-width)
((or null resource-id) above-sibling)
(boolean override-redirect-p))
(declare-event :gravity-notify
(resource-id event-window window)
(integer x y))
(declare-event :resize-request
(resource-id window)
(integer width height))
(declare-event :configure-request
(resource-id parent window)
(integer x y width height border-width)
((or null resource-id) above-sibling))
(declare-event :circulate-notify
(resource-id event-window window)
((member :top :bottom) place))
(declare-event :circulate-request
(resource-id parent window)
((member :top :bottom) place))
(declare-event :property-notify
(resource-id window)
(keyword atom)
((member :new-value :deleted) state)
(integer time))
(declare-event :selection-clear
(resource-id window)
(keyword selection)
(integer time))
(declare-event :selection-request
(resource-id window requestor)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :selection-notify
(resource-id window)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :colormap-notify
(resource-id window)
((or null resource-id) colormap)
(boolean new-p installed-p))
(declare-event :client-message
(resource-id window)
((member 8 16 32) format)
((sequence integer) data))
(defun queue-event (display event-key &rest args &key append-p &allow-other-keys)
;; The event is put at the head of the queue if append-p is nil, else the tail.
;; Additional arguments depend on event-key, and are as specified above with
;; declare-event, except that both resource-ids and resource objects are accepted
;; in the event components.
(declare (type display display)
(type event-key event-key)
(type boolean append-p)))
∂01-Jun-87 0532 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol script
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:32:24 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:31-EDT
Date: Mon, 1 Jun 87 08:31 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol script
To: x3j13@sail.stanford.edu
Message-ID: <870601083150.2.RWS@KILLINGTON.LCS.MIT.EDU>
Mathis requested that I mail out the X protocol document.
I just did, in 6 parts. If you are going to print it
out, and have access to a Unix system, below is a shell
script for generating a toc and an index. Be sure to
set the page length for your printer.
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# paginate
# addindex
# This archive created: Fri May 29 11:37:31 1987
export PATH; PATH=/bin:/usr/bin:$PATH
if test -f 'paginate'
then
echo shar: "will not over-write existing file 'paginate'"
else
cat << \SHAR_EOF > 'paginate'
#!/bin/sh
# Hack attack.
# Assuming this program is stilled called paginate, it is intended to be
# in the form
# paginate spec
# It then generates the files
# spec.paged nearly the same as foo with the exception of
# a header on the top of each page. Pages are
# assumed to be 58 lines long before the header
# gets added.
# spec.toc A page number listing of all the lines that start
# with an upper case letter in column 1, up to but
# not including the first colon.
# spec.index An index built from the x11.spec.toc lines.
today="`date`"
linesPerPage=58
infile=$1
pagedfile=$1.paged
indexfile=$1.index
tocfile=$1.toc
addindex=addindex
wordsfile=/usr/tmp/$1.words
indexinput=/usr/tmp/$1.index-input
grepscript=/usr/tmp/$1.grep-script
rm -f $pagedfile $tocfile $indexfile $wordsfile $grepscript
rm -f $indexinput
echo "Paginating $infile into $pagedfile."
awk '
BEGIN {
date = "'"$today"'";
n = split(date, dateparts);
date = dateparts[3] " " dateparts[2] " " dateparts[6]
FS = ":";
input = "'$infile'";
paged = "'$pagedfile'";
toc = "'$tocfile'";
ind = "'$indexfile'";
words = "'$wordsfile'";
page = 1;
line = 0;
}
{
if ((line == 0) && (NF > 0))
printf("\n") > paged
print > paged
line = line + 1
if (line >= '$linesPerPage') {
page = page + 1
line = 0
printf("%c\n%s%42s%23s %d\n", 12, date, "X/V11 Protocol Specification", "Page", page) > paged
}
}
/↑[A-Z]/ {
l = $1;
while ((length(l) % 4) != 0)
l = l " "
while (length(l) < 70)
l = l " ."
if (l ~ /↑SECTION/)
printf("\n") > toc
printf("%s%5d\n", l, page) > toc
if (l !~ /↑SECTION/)
printf("\"%s\"\n", $1) > words
}
' $infile
cat $addindex >> $wordsfile
echo "Sorting $wordsfile."
sort -udf $wordsfile -o $wordsfile
echo "Generating $grepscript."
awk '{print "echo",$0, "; grep -n", $0, "'$infile'" > "'$grepscript'"}' $wordsfile
echo "Executing $grepscript to generate $indexinput."
sh $grepscript > $indexinput
echo "Producing $indexfile."
awk -F: '
BEGIN {
ind = "'$indexfile'";
}
/↑[A-Z]/ {
if (length(line) > 0)
printf("%s\n", line) > ind
line = sprintf("%-25s", $0)
separator = " "
lastPage = 0
}
/↑[0-9]/ {
pagen = ($1+'$linesPerPage'-1)/'$linesPerPage'
t = split(pagen, pageparts, ".")
page = pageparts[1]
if (lastPage != page)
{
if (length(line) > 73)
{
printf("%s,\n", line) > ind
line = sprintf("%-25s %d", " ", page)
}
else
line = line separator page
separator = ", "
lastPage = page
}
}
END {
printf("%s\n", line) > ind
}
' $indexinput
echo "Cleaning up."
#rm -f $wordsfile $grepscript $indexinput
SHAR_EOF
chmod +x 'paginate'
fi
if test -f 'addindex'
then
echo shar: "will not over-write existing file 'addindex'"
else
cat << \SHAR_EOF > 'addindex'
"OwnerGrabButton"
"EnterWindow"
"LeaveWindow"
"PointerMotion"
"PointerMotionHint"
"ButtonMotion"
"VisibilityChange"
"StructureNotify"
"ResizeRedirect"
"SubstructureNotify"
"SubstructureRedirect"
"FocusChange"
"PropertyChange"
"ColormapChange"
"KeymapState"
SHAR_EOF
fi
exit 0
# End of shell archive
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 3 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:25 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 3 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082750.8.RWS@KILLINGTON.LCS.MIT.EDU>
GetGeometry
drawable: DRAWABLE
=>
root: WINDOW
depth: CARD8
x, y: INT16
width, height, border-width: CARD16
Errors: Drawable
Returns the root and (current) geometry of the drawable. Depth is the
number of bits per pixel for the object. X, y, and border-width will
always be zero for pixmaps. For a window, the x and y coordinates
specify the upper left outer corner of the window relative to its
parent's origin, and the width and height specify the inside size (not
including the border).
It is legal to pass an InputOnly window as a drawable to this request.
QueryTree
window: WINDOW
=>
root: WINDOW
parent: WINDOW or None
children: LISTofWINDOW
Errors: Window
Returns the root, the parent, and children of the window. The children
are listed in bottom-to-top stacking order.
InternAtom
name: STRING8
only-if-exists: BOOL
=>
atom: ATOM or None
Errors: Value, Alloc
Returns the atom for the given name. If only-if-exists is False, then
the atom is created if it does not exist. The string should use the
ASCII encoding, and upper/lower case matters.
The lifetime of an atom is not tied to the interning client. Atoms
remained defined until server reset (see Section 11).
GetAtomName
atom: ATOM
=>
name: STRING8
Errors: Atom
Returns the name for the given atom.
ChangeProperty
window: WINDOW
property, type: ATOM
format: {8, 16, 32}
mode: {Replace, Prepend, Append}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Value, Match, Alloc
Alters the property for the specified window. The type is
uninterpreted by the server. The format specifies whether the data
should be viewed as a list of 8-bit, 16-bit, or 32-bit quantities, so
that the server can correctly byte-swap as necessary.
If mode is Replace, the previous property value is discarded. If the
mode is Prepend or Append, then the type and format must match the
existing property value (else a Match error); if the property is
undefined, it is treated as defined with the correct type and format
with zero-length data. For Prepend, the data is tacked on to the
beginning of the existing data, and for Append it is tacked on to the
end of the existing data.
Generates a PropertyNotify event on the window.
The lifetime of a property is not tied to the storing client.
Properties remain until explicitly deleted, or the window is destroyed,
or until server reset (see Section 11).
The maximum size of a property is server dependent.
DeleteProperty
window: WINDOW
property: ATOM
Errors: Window, Atom
Deletes the property from the specified window if the property exists.
Generates a PropertyNotify event on the window unless the property does
not exist.
GetProperty
window: WINDOW
property: ATOM
type: ATOM or AnyPropertyType
long-offset, long-length: CARD32
delete: BOOL
=>
type: ATOM
format: {8, 16, 32}
bytes-after: CARD32
value: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Property, Match, Value
If the specified property does not exist for the specifed window, a
Property error is generated. Otherwise, if type AnyPropertyType is
specified, (part of) the property is returned regardless of its type;
if a type is specified, (part of) the property is returned only if its
type equals the specified type (else a Match error). The actual type
and format of the property are returned.
Define the following values:
N = actual length of the stored property in bytes
(even if the format is 16 or 32)
I = 4 * long-offset
T = N - I
L = MINIMUM(T, 4 * long-length)
A = N - (I + L)
The returned value starts at byte index I in the property (indexing
from 0), and its length in bytes is L. It is a Value error if
long-offset is given such that L is negative. The value of bytes-after
is A, giving the number of trailing unread bytes in the stored
property.
If delete is True and bytes-after is zero, the property is also deleted
from the window and a PropertyNotify event is generated on the window.
RotateProperties
window: WINDOW
delta: INT8
properties: LISTofATOM
Errors: Window, Atom, Match
If the property names in the list are viewed as being numbered starting
from zero, and there are N property names in the list, then the value
associated with property name I becomes the value associated with
property name (I + delta) mod N, for all I from zero to N - 1. The
effect is to rotate the states by delta places around the virtual ring
of property names (right for positive delta, left for negative delta).
A PropertyNotify event is generated for each property, in the order
listed.
If an atom occurs more than once in the list or no property with that
name is defined for the window, a Match error is generated. If an Atom
or Match error is generated, no properties are changed.
ListProperties
window: WINDOW
=>
atoms: LISTofATOM
Errors: Window
Returns the atoms of properties currently defined on the window.
SetSelectionOwner
selection: ATOM
owner: WINDOW or None
time: TIMESTAMP or CurrentTime
Error: Atom, Window
Changes the owner and last-change time of the specifed selection. The
request has no effect if the specified time is earlier than the current
last-change time of the specified selection or is later than the
current server time; otherwise, the last-change time is set to the
specified time, with CurrentTime replaced by the current server time.
If the new owner is not the same as the current owner of the selection,
and the current owner is a window, then the current owner is sent a
SelectionClear event.
If the owner of a selection is a window, and the window is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
The selection atom is uninterpreted by the server.
Selections are global to the server.
GetSelectionOwner
selection: ATOM
=>
owner: WINDOW or None
Errors: Atom
Returns the current owner of the specified selection, if any.
ConvertSelection
selection, target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Error: Atom, Window
If the specified selection is owned by a window, the server sends a
SelectionRequest event to the owner. If no owner for the specified
selection exists, the server generates a SelectionNotify event to the
requestor with property None. The arguments are passed on unchanged in
either event.
SendEvent
destination: WINDOW or PointerWindow or InputFocus
propagate: BOOL
event-mask: SETofEVENT
event: <normal-event-format>
Errors: Window, Value
If PointerWindow is specified, destination is replaced with the window
that the pointer is in. If InputFocus is specified, then if the focus
window contains the pointer, destination is replaced with the window
that the pointer is in, and otherwise destination is replaced with the
focus window.
If propagate is False, then the event is sent to every client selecting
on destination any of the event types in event-mask.
If propagate is True and no clients have selected on destination any of
the event types in event-mask, then destination is replaced with the
closest ancestor of destination for which some client has selected a
type in event-mask and no intervening window has that type in its
do-not-propagate-mask. If no such window exists, or if the window is
an ancestor of the focus window and InputFocus was originally specified
as the destination, then the event is not sent to any clients.
Otherwise, the event is reported to every client selecting on the final
destination any of the types specified in event-mask.
The event code must be one of the core events, or one of the events
defined by an extension, so that the server can correctly byte swap the
contents as necessary. The contents of the event are otherwise
unaltered and unchecked by the server except to force on the most
significant bit of the event code.
Active grabs are ignored for this request.
GrabPointer
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Cursor, Window, Value
Actively grabs control of the pointer. Further pointer events are only
reported to the grabbing client. The request overrides any active
pointer grab by this client.
Event-mask is always augmented to include ButtonPress and
ButtonRelease. If owner-events is False, all generated pointer events
are reported with respect to grab-window, and are only reported if
selected by event-mask. If owner-events is True, then if a generated
pointer event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window, and is only reported if selected by event-mask. For
either value of owner-events, unreported events are simply discarded.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
If a cursor is specified, then it is displayed regardless of what
window the pointer is in. If no cursor is specified, then when the
pointer is in grab-window or one of its subwindows, the normal cursor
for that window is displayed, and otherwise the cursor for grab-window
is displayed.
If a confine-to window is specified, then the pointer will be
restricted to stay contained in that window. The confine-to window
need have no relationship to the grab-window. If the pointer is not
initially in the confine-to window, then it is warped automatically to
the closest edge (and enter/leave events generated normally) just
before the grab activates. If the confine-to window is subsequently
reconfigured, the pointer will be warped automatically as necessary to
keep it contained in the window.
This request generates EnterNotify and LeaveNotify events.
The request fails with status AlreadyGrabbed if the pointer is actively
grabbed by some other client. The request fails with status Frozen if
the pointer is frozen by an active grab of another client. The request
fails with status NotViewable if grab-window or confine-to window is
not viewable. The request fails with status InvalidTime if the
specified time is earlier than the last-pointer-grab time or later than
the current server time; otherwise the last-pointer-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabPointer
time: TIMESTAMP or CurrentTime
Releases the pointer if this client has it actively grabbed (from
either GrabPointer or GrabButton or from a normal button press), and
releases any queued events. The request has no effect if the specified
time is earlier than the last-pointer-grab time or is later than the
current server time.
This request generates EnterNotify and LeaveNotify events.
An UngrabPointer is performed automatically if the event window or
confine-to window for an active pointer grab becomes not viewable.
GrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
Errors: Cursor, Window, Value, Access
This request establishes a passive grab. In the future, if the
specified button is pressed when the specified modifier keys are down
(and no other buttons or modifier keys are down), and grab-window
contains the pointer, and the confine-to window (if any) is viewable,
and these constraints are not satisfied for any ancestor, then the
pointer is actively grabbed as described in GrabPointer, the
last-pointer-grab time is set to the time at which the button was
pressed (as transmitted in the ButtonPress event), and the ButtonPress
event is reported. The interpretation of the remaining arguments is as
for GrabPointer. The active grab is terminated automatically when all
buttons are released (independent of the state of modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A button of AnyButton is equivalent to
issuing the request for all possible buttons.
An Access error is generated if some other client has already issued a
GrabButton with the same button/key combination on the same window.
When using AnyModifier or AnyButton, the request fails completely (no
grabs are established) if there is a conflicting grab for any
combination. The request has no effect on an active grab.
UngrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
Errors: Window
Releases the passive button/key combination on the specified window if
it was grabbed by this client. A modifiers of AnyModifier is
equivalent to issuing the request for all possible modifier
combinations. A button of AnyButton is equivalent to issuing the
request for all possible buttons. Has no effect on an active grab.
ChangeActivePointerGrab
event-mask: SETofPOINTEREVENT
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
Errors: Cursor
Changes the specified dynamic parameters if the pointer is actively
grabbed by the client and the specified time is no earlier than the
last-pointer-grab time and no later than the current server time. The
interpretation of event-mask and cursor are as in GrabPointer. The
event-mask is always augmented to include ButtonPress and
ButtonRelease. Has no effect on the passive parameters of a
GrabButton.
GrabKeyboard
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Window, Value
Actively grabs control of the keyboard. Further key events are
reported only to the grabbing client. The request overrides any active
keyboard grab by this client.
If owner-events is False, all generated key events are reported with
respect to grab-window. If owner-events is True, then if a generated
key event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window. Both KeyPress and KeyRelease events are always reported,
independent of any event selection made by the client.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
This request generates FocusIn and FocusOut events.
The request fails with status AlreadyGrabbed if the keyboard is
actively grabbed by some other client. The request fails with status
Frozen if the keyboard is frozen by an active grab of another client.
The request fails with status NotViewable if grab-window is not
viewable. The request fails with status InvalidTime if the specified
time is earlier than the last-keyboard-grab time or later than the
current server time; otherwise the last-keyboard-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabKeyboard
time: TIMESTAMP or CurrentTime
Releases the keyboard if this client has it actively grabbed (from
either GrabKeyboard or GrabKey), and releases any queued events. The
request has no effect if the specified time is earlier than the
last-keyboard-grab time or is later than the current server time.
This request generates FocusIn and FocusOut events.
An UngrabKeyboard is performed automatically if the event window for an
active keyboard grab becomes not viewable.
GrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
Errors: Window, Value, Access
This request establishes a passive grab on the keyboard. In the
future, if the specified key (which can itself be a modifier key) is
pressed when the specified modifier keys are down (and no other
modifier keys are down), and the KeyPress event would be generated in
grab-window or one of its inferiors, and these constraints are not
satisfied for any ancestor, then the keyboard is actively grabbed as
described in GrabKeyboard, the last-keyboard-grab time is set to the
time at which the key was pressed (as transmitted in the KeyPress
event), and the KeyPress event is reported. The interpretation of the
remaining arguments is as for GrabKeyboard. The active grab is
terminated automatically when the specified key has been released
(independent of the state of the modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A key of AnyNonModifier is equivalent
to issuing the request for all possible non-modifier key codes.
An Access error is generated if some other client has issued a GrabKey
with the same key combination on the same window. When using
AnyModifier or AnyNonModifier, the request fails completely (no grabs
are established) if there is a conflicting grab for any combination.
UngrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
Errors: Window
Releases the key combination on the specified window if it was grabbed
by this client. A modifiers of AnyModifier is equivalent to issuing
the request for all possible modifier combinations. A key of
AnyNonModifier is equivalent to issuing the request for all possible
non-modifier key codes. Has no effect on an active grab.
AllowEvents
mode: {AsyncPointer, SyncPointer, ReplayPointer,
AsyncKeyboard, SyncKeyboard, ReplayKeyboard}
time: TIMESTAMP or CurrentTime
Errors: Value
Releases some queued events if the client has caused a device to
freeze. The request has no effect if the specified time is earlier
than the last-grab time of the most recent active grab for the client,
or if the specified time is later than the current server time.
For AsyncPointer, if the pointer is frozen by the client, pointer event
processing continues normally. If the pointer is frozen twice by the
client on behalf of two separate grabs, AsyncPointer "thaws" for both.
AsyncPointer has no effect if the pointer is not frozen by the client,
but the pointer need not be grabbed by the client.
For SyncPointer, if the pointer is frozen and actively grabbed by the
client, pointer event processing continues normally until the next
ButtonPress or ButtonRelease event is reported to the client, at which
time the pointer again appears to freeze. However if the reported
event causes the pointer grab to be released, then the pointer does not
freeze. SyncPointer has no effect if the pointer is not frozen by the
client, or if the pointer is not grabbed by the client.
For ReplayPointer, if the pointer is actively grabbed by the client and
is frozen as the result of an event having been sent to the client
(either from the activation of a GrabButton, or from a previous
AllowEvents with mode SyncPointer, but not from a GrabPointer), then
the pointer grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the pointer is not grabbed by the client, or if the pointer is not
frozen as the result of an event.
For AsyncKeyboard, if the keyboard is frozen by the client, keyboard
event processing continues normally. If the pointer is frozen twice by
the client on behalf of two separate grabs, AsyncPointer "thaws" for
both. AsyncKeyboard has no effect if the keyboard is not frozen by the
client, but the keyboard need not be grabbed by the client.
For SyncKeyboard, if the keyboard is frozen and actively grabbed by the
client, keyboard event processing continues normally until the next
KeyPress or KeyRelease event is reported to the client, at which time
the keyboard again appears to freeze. However if the reported event
causes the keyboard grab to be released, then the keyboard does not
freeze. SyncKeyboard has no effect if the keyboard is not frozen by
the client, or if the keyboard is not grabbed by the client.
For ReplayKeyboard, if the keyboard is actively grabbed by the client
and is frozen as the result of an event having been sent to the client
(either from the activation of a GrabKey, or from a previous
AllowEvents with mode SyncKeyboard, but not from a GrabKeyboard), then
the keyboard grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the keyboard is not grabbed by the client, or if the keyboard is not
frozen as the result of an event.
AsyncPointer, SyncPointer, and Replay Pointer have no effect on
processing of keyboard events. AsyncKeyboard, SyncKeyboard, and
ReplayKeyboard have no effect on processing of pointer events.
It is possible for both a pointer grab and a keyboard grab to be active
simultaneously (by the same or different clients). If a device is
frozen on behalf of either grab, no event processing is performed for
the device. It is possible for a single device to be frozen due to
both grabs. In this case, the freeze must be released on behalf of
both grabs before events can again be processed.
GrabServer
Disables processing of requests and close-downs on all other
connections (than the one this request arrived on).
UngrabServer
Restarts processing of requests and close-downs on other connections.
QueryPointer
window: WINDOW
=>
root: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, win-x, win-y: INT16
mask: SETofKEYBUTMASK
Errors: Window
The root window the pointer is currently on, and pointer coordinates
relative to the root's origin, are returned. If same-screen is False,
then the pointer is not on the same screen as the argument window, and
child is None and win-x and win-y are zero. If same-screen is True,
then win-x and win-y are the pointer coordinates relative to the
argument window's origin, and child is the child containing the
pointer, if any. The current state of the modifier keys and the
buttons are also returned.
GetMotionEvents
start, stop: TIMESTAMP or CurrentTime
window: WINDOW
=>
events: LISTofTIMECOORD
where
TIMECOORD: {x, y: CARD16
time: TIMESTAMP}
Error: Window
Returns all events in the motion history buffer that fall between the
specified start and stop times (inclusive) and that have coordinates
that lie within (including borders) the specified window at its present
placement. The x and y coordinates are reported relative to the origin
of the window.
TranslateCoordinates
src-window, dst-window: WINDOW
src-x, src-y: INT16
=>
same-screen: BOOL
child: WINDOW or None
dst-x, dst-y: INT16
Errors: Window
The src-x and src-y coordinates are taken relative to src-window's
origin, and returned as dst-x and dst-y coordinates relative to
dst-window's origin. If same-screen is False, then src-window and
dst-window are on different screens, and dst-x and dst-y are zero. If
the coordinates are contained in a mapped child of dst-window, then
that child is returned.
WarpPointer
src-window: WINDOW or None
dst-window: WINDOW
src-x, src-y: INT16
src-width, src-height: CARD16
dst-x, dst-y: INT16
Errors: Window
Moves the pointer to [dst-x, dst-y] relative to dst-window's origin.
If src-window is None, the move is independent of the current pointer
position, but if a window is specified, the move only takes place if
the pointer is currently contained in a visible portion of the
specified rectangle of the src-window.
The src-x and src-y coordinates are relative to src-window's origin.
If src-height is zero, it is replaced with the current height of
src-window minus src-y. If src-width is zero, it is replaced with the
current width of src-window minus src-x.
This request cannot be used to move the pointer outside the confine-to
window of an active pointer grab; an attempt will only move the pointer
as far as the closest edge of the confine-to window.
SetInputFocus
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
time: TIMESTAMP or CurrentTime
Errors: Window, Value
Changes the input focus and the last-focus-change time. The request
has no effect if the specified time is earlier than the current
last-focus-change time or is later than the current server time;
otherwise, the last-focus-change time is set to the specified time,
with CurrentTime replaced by the current server time.
If None is specified as the focus, all keyboard events are discarded
until a new focus window is set. In this case, the revert-to argument
is ignored.
If a window is specified as the focus, it becomes the keyboard's focus
window. If a generated keyboard event would normally be reported to
this window or one of its inferiors, the event is reported normally;
otherwise, the event is reported with respect to the focus window.
If PointerRoot is specified as the focus, the focus window is
dynamically taken to be the root window of whatever screen the pointer
is on at each keyboard event. In this case, the revert-to argument is
ignored.
This request generates FocusIn and FocusOut events.
If the focus window becomes not viewable, the new focus window depends
on the revert-to argument. If revert-to is Parent, the focus reverts
to the parent (or the closest viewable ancestor) and the new revert-to
value is take to be None. If revert-to is PointerRoot or None, the
focus reverts to that value. When the focus reverts, FocusIn and
FocusOut events are generated, but the last-focus-change time is not
affected.
GetInputFocus
=>
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
Returns the current focus state.
QueryKeymap
=>
keys: LISTofCARD8
Returns a bit vector for the keyboard; each one bit indicates that the
corresponding key is currently pressed. The vector is represented as
32 bytes. Byte N (from 0) contains the bits for keys 8N to 8N+7, with
the least significant bit in the byte representing key 8N.
OpenFont
fid: FONT
name: STRING8
Errors: IDChoice, Name, Alloc
Loads the specified font, if necessary, and associates identifier fid
with it. The font can be used as a source for any drawable. The font
name should use the ASCII encoding, and upper/lower case does not
matter.
CloseFont
font: FONT
Errors: Font
Deletes the association between the resource id and the font. The font
itself will be freed when no other resource references it.
∂01-Jun-87 0530 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 5 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:29:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 5 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082843.0.RWS@KILLINGTON.LCS.MIT.EDU>
PolyArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
Draws circular or elliptical arcs. Each arc is specified by a
rectangle and two angles. The x and y coordinates are relative to the
origin of the drawable, and define the upper left corner of the
rectangle. The center of the circle or ellipse is the center of the
rectangle, and the major and minor axes are specified by the width and
height, respectively. The angles are signed integers in degrees scaled
by 64, with positive indicating counterclockwise motion and negative
indicating clockwise motion. The start of the arc is specified by
angle1 relative to the three-oclock position from the center, and the
path and extent of the arc is specified by angle2 relative to the start
of the arc. If the magnitude of angle2 is greater than 360 degrees, it
is truncated to 360 degrees.
The arcs are drawn in the order listed. If the last point in one arc
coincides with the first point in the following arc, the two arcs will
join correctly. If the first point in the first arc coincides with the
last point in the last arc, the two arcs will join correctly. For any
given arc, no pixel is drawn more than once. If two arcs join
correctly and the line-width is greater than zero and the arcs
intersect, no pixel is drawn more than once. Otherwise, the
intersecting pixels of intersecting arcs are drawn multiple times.
Specifying an arc with one endpoint and a clockwise extent draws the
same pixels as specifying the other endpoint and an equivalent
counterclockwise extent, except as it affects joins.
By specifying one axis to be zero, a horizontal or vertical line can be
drawn.
Angles are computed based solely on the coordinate system, ignoring the
aspect ratio.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
FillPoly
drawable: DRAWABLE
gc: GCONTEXT
shape: {Complex, Nonconvex, Convex}
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Match, Value
Fills the region closed by the specified path. The path is closed
automatically if the last point in the list does not coincide with the
first point. No pixel of the region is drawn more than once.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
The shape parameter may be used by the server to improve performance.
Complex means the path may self-intersect.
Nonconvex means the path does not self-intersect, but the shape is not
wholly convex. If known by the client, specifying Nonconvex over
Complex may improve performance. If Nonconvex is specified for a
self-intersecting path, the graphics results are undefined.
Convex means the path is wholly convex. If known by the client,
specifying Convex can improve performance. If Convex is specified for
a path that is not convex, the graphics results are undefined.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Fills the specified rectangles. The x and y coordinates of each
rectangle are relative to the drawable's origin, and define the upper
left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
For each arc, fills the region closed by the specified arc and one or
two line segments, depending on the arc-mode. For Chord, the single
line segment joining the endpoints of the arc is used. For PieSlice,
the two line segments joining the endpoints of the arc with the center
point are used. The arcs are as specified in the PolyArc request.
The arcs are filled in the order listed. For any given arc, no pixel
is drawn more than once. If regions intersect, the intersecting pixels
are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
arc-mode, subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PutImage
drawable: DRAWABLE
gc: GCONTEXT
depth: CARD8
width, height: CARD16
dst-x, dst-y: INT16
left-pad: CARD8
format: {Bitmap, XYPixmap, ZPixmap}
bits: <bits>
Errors: Drawable, GContext, Match, Value, Alloc
Combines an image with a rectangle of the drawable. The dst-x and
dst-y coordinates are relative to the drawable's origin.
If Bitmap format is used, then depth must be one (else a Match error)
and the image must be in XYFormat. The foreground pixel in gc defines
the source for one bits in the image, and the background pixel defines
the source for the zero bits.
For XYPixmap and ZPixmap, depth must match the depth of drawable (else
a Match error). For XYPixmap, the image must be sent in XYFormat. For
ZPixmap, the image must be sent in the ZFormat defined for the given
depth.
The left-pad must be zero for ZPixmap format. For Bitmap and XYPixmap
format, left-pad must be less than bitmap-format-scanline-pad (as given
in the server connection setup info). The first left-pad bits in every
scanline are to be ignored by the server; the actual image begins that
many bits into the data. The width argument defines the width of the
actual image, and does not include left-pad.
GC components: alu-function, plane-mask, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background
GetImage
drawable: DRAWABLE
x, y: INT16
width, height: CARD16
plane-mask: CARD32
format: {XYFormat, ZFormat}
=>
depth: CARD8
visual: VISUALID or None
bits: <bits>
Errors: Drawable, Value, Match
Returns the contents of the given rectangle of the drawable in the
given format. The x and y coordinates are relative to the drawable's
origin, and define the upper left corner of the rectangle. If XYFormat
is specified, only the bit planes specified in plane-mask are
transmitted. If ZFormat is specified, then bits in all planes not
specified in plane-mask transmitted as zero. The returned depth
specifies the number of bits per pixel of the image. If the drawable
is a window, its visual type is returned; if the drawable is a pixmap,
the visual is None.
If the drawable is a window, the window must be mapped, and it must be
the case that, if there were no inferiors or overlapping windows, the
specified rectangle of the window would be fully visible on the screen
(else a Match error). The returned image will include any visible
portions of inferiors or overlapping windows contained in the
rectangle, but if these windows are of different depth than the
specified window, the contents returned for them are not defined by the
core protocol.
PolyText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM8
where
TEXTITEM8: TEXTELT8 or FONT
TEXTELT8: [delta: INT8
string: STRING8]
Errors: Drawable, GContext, Match, Font
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). Each
text item is processed in turn. A font item causes the font to be
stored in gc, and to be used for subsequent text; switching among fonts
with differing draw-directions is permitted. A text element delta
specifies an additional change in the position along the x axis before
the string is drawn; the delta is always added to the character origin
(not added or subtracted based on the draw-direction of the current
font). Each character image, as defined by the font in gc, is treated
as an additional mask for a fill operation on the drawable.
All contained FONTs are always transmitted most significant byte first.
If a Font error is generated for an item, the previous items may have
been drawn.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: alu-function, plane-mask, fill-style, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM16
where
TEXTITEM16: TEXTELT16 or FONT
TEXTELT16: [delta-x: INT8
string: STRING16]
Errors: Drawable, GContext, Match, Font
Just like PolyText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
ImageText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING8
Errors: Drawable, GContext, Match
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). The
effect is to first fill a destination rectangle with the background
pixel defined in gc, and then paint the text with the foreground pixel.
The upper left corner of the filled rectangle is at
[x + overall-left, y - font-ascent]
the width is
overall-right - overall-left
and the height is
font-ascent + font-descent
where overall-left, overall-right, font-ascent, and font-descent are as
would be returned by a QueryTextExtents call using gc and string.
The alu-function and fill-style defined in gc are ignored for this
request; the effective alu-function is Copy and the effective
fill-style Solid.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: plane-mask, foreground, background, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
ImageText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING16
Errors: Drawable, GContext, Match
Just like ImageText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
CreateColormap
mid: COLORMAP
visual: VISUALID
window: WINDOW
alloc: {None, All}
Errors: IDChoice, Window, Value, Match, Alloc
Creates a colormap of the specified visual type for the screen on which
the window resides, and associates the identifier mid with it. The
visual type must be one supported by the screen, and cannot be of class
TrueColor (else a Match error). The initial values of the colormap
entries are undefined for classes GrayScale, PseudoColor, and
DirectColor; for StaticGray, StaticColor, and TrueColor, the entries
will have defined values, but those values are specific to the visual
and are not defined by the core protocol. For StaticGray, StaticColor,
and TrueColor, alloc must be specified as None (else a Match error).
For the other classes, if alloc is None, the colormap initially has no
allocated entries, and clients can allocate entries. If alloc is All,
then the entire colormap is "allocated" writable, but entries cannot be
freed with FreeColors, and no relationships among entries is defined;
the client must understand whether the colormap is GrayScale,
PseudoColor, or DirectColor to know how to store into entries.
FreeColormap
cmap: COLORMAP
Errors: Colormap
Deletes the association between the resource id and the colormap. If
the colormap is an installed map for a screen, it is uninstalled (see
UninstallColormap). If the colormap is defined as the colormap for a
window (via CreateWindow or ChangeWindowAttributes), the colormap for
the window is changed to None, and a ColormapNotify event is generated.
The colors displayed for a window with a colormap of None are not
defined by the protocol.
Has no effect on a default colormap for a screen.
CopyColormapAndFree
mid, src-cmap: COLORMAP
Errors: Colormap, Alloc
Creates a colormap for the same screen as src-cmap, and associates
identifier mid with it. Moves all of the client's existing allocations
from src-cmap to the new colormap, and frees those entries in src-cmap.
Values in other entries in the new colormap are undefined.
InstallColormap
cmap: COLORMAP
Errors: Colormap
Makes this colormap an installed map for its screen. All windows
associated with this colormap immediately display with true colors. As
a side-effect, previously installed colormaps may be uninstalled, and
other windows may display with false colors. Which colormaps get
uninstalled is server dependent, except that it is guaranteed that the
M-1 most recently client-installed colormaps will not be uninstalled,
where M is the min-installed-maps specified for the screen in the
connection setup.
If cmap is not already an installed map, a ColormapNotify event is
generated on every window having cmap as an attribute. If a colormap
is uninstalled as a result of the install, a ColormapNotify event is
generated on every window having that colormap as an attribute.
Initially only the default colormap for a screen is installed.
UninstallColormap
cmap: COLORMAP
Errors: Colormap
If cmap is an installed map for its screen, one or more colormaps are
installed in its place; the choice is server dependent, except that if
the screen's default colormap is not installed and can be installed
(without forcing other colormaps out), then the default colormap is
used.
If cmap is an installed map, a ColormapNotify event is generated on
every window having this colormap as an attribute. If a colormap is
installed as a result of the uninstall, a ColormapNotify event is
generated on every window having that colormap as an attribute.
ListInstalledColormaps
window: WINDOW
=>
cmaps: LISTofCOLORMAP
Errors: Window
Returns a list of the currently installed colormaps for the screen of
the specified window.
AllocColor
cmap: COLORMAP
red, green, blue: CARD16
=>
pixel: CARD32
red, green, blue: CARD16
Errors: Colormap, Alloc
Allocates a read-only colormap entry corresponding to the closest RGB
values provided by the hardware. Returns the pixel and the RGB values
actually used.
AllocNamedColor
cmap: COLORMAP
name: STRING8
=>
pixel: CARD32
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name, Alloc
Looks up the named color with respect to the screen associated with the
colormap, then does an AllocColor on cmap. The name should use the
ASCII encoding, and upper/lower case does not matter. The exact RGB
values specify the "true" values for the color, and the screen values
specify the values actually used in the colormap.
AllocColorCells
cmap: COLORMAP
colors, planes: CARD16
contiguous: BOOL
=>
pixels, masks: LISTofCARD32
Errors: Colormap, Value, Alloc
The number of colors must be positive, the number of planes
non-negative. If C colors and P planes are requested, then C pixels
and P masks are returned. No mask will have any bits in common with
any other mask, or with any of the pixels. By ORing together masks and
pixels, C*(2↑P) distinct pixels can be produced; all of these are
allocated writable by the request. For GrayScale or PseudoColor, each
mask will have exactly one bit, and for DirectColor each will have
exactly three bits. If contiguous is True, then if all masks are ORed
together, a single contiguous set of bits will be formed for GrayScale
or PseudoColor, and three contiguous sets of bits (one within each
pixel subfield) for DirectColor. The RGB values of the allocated
entries are undefined.
AllocColorPlanes
cmap: COLORMAP
colors, reds, greens, blues: CARD16
contiguous: BOOL
=>
pixels: LISTofCARD32
red-mask, green-mask, blue-mask: CARD32
Errors; Colormap, Value, Alloc
The number of colors must be positive, the reds, greens, and blues
non-negative. If C colors, R reds, G greens, and B blues are
requested, then C pixels are returned, and the masks have R, G, and B
bits set respectively. If contiguous is True, then each mask will have
a contiguous set of bits. No mask will have any bits in common with
any other mask, or with any of the pixels. For DirectColor, each mask
will lie within the corresponding pixel subfield. By ORing together
subsets of masks with pixels, C*(2↑(R+G+B)) distinct pixels can be
produced; all of these are allocated by the request. The initial RGB
values of the allocated entries are undefined. In the colormap there
are only C*(2↑R) independent red entries, C*(2↑G) independent green
entries, and C*(2↑B) independent blue entries. This is true even for
PseudoColor. When the colormap entry for a pixel value is changed
using StoreColors or StoreNamedColor, the pixel is decomposed according
to the masks and the corresponding independent entries are updated.
FreeColors
cmap: COLORMAP
pixels: LISTofCARD32
plane-mask: CARD32
Errors: Colormap, Access, Value
The plane-mask should not have any bits in common with any of the
pixels. The set of all pixels is produced by ORing together subsets of
plane-mask with the pixels. The request frees all of these pixels.
Note that freeing an individual pixel obtained from AllocColorPlanes
may not actually allow it to be reused until all of its "related"
pixels are also freed.
All specified pixels that are allocated by the client in cmap are
freed, even if one or more pixels produce an error. A Value error is
generated if a specified pixel is not a valid index into cmap, and an
Access error is generated if a specified pixel is not allocated by the
client (i.e., is unallocated or is only allocated by another client).
If more than one pixel is in error, which one is reported is arbitrary.
StoreColors
cmap: COLORMAP
items: LISTofCOLORITEM
where
COLORITEM: [pixel: CARD32
do-red, do-green, do-blue: BOOL
red, green, blue: CARD16]
Errors: Colormap, Access, Value
Changes the colormap entries of the specified pixels. The do-red,
do-green, and do-blue fields indicate which components should actually
be changed. If the colormap is an installed map for its screen, the
changes are visible immediately.
All specified pixels that are allocated writable in cmap (by any
client) are changed, even if one or more pixels produce an error. A
Value error is generated if a specified pixel is not a valid index into
cmap, and an Access error is generated if a specified pixel is
unallocated or is allocated read-only. If more than one pixel is in
error, which one is reported is arbitrary.
StoreNamedColor
cmap: COLORMAP
pixel: CARD32
name: STRING8
do-red, do-green, do-blue: BOOL
Errors: Colormap, Name, Access, Value
Looks up the named color with respect to the screen associated with
cmap, then does a StoreColors in cmap. The name should use the ASCII
encoding, and upper/lower case does not matter.
QueryColors
cmap: COLORMAP
pixels: LISTofCARD32
=>
colors: LISTofRGB
where
RGB: [red, green, blue: CARD16]
Errors: Colormap, Value
Returns the color values stored in cmap for the specified pixels. The
values returned for an unallocated entry are undefined. A Value error
is generated if a pixel is not a valid index into cmap. If more than
one pixel is in error, which one is reported is arbitrary.
LookupColor
cmap: COLORMAP
name: STRING8
=>
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name
Looks up the string name of a color with respect to the screen
associated with cmap, and returns both the exact the color values and
the closest values provided by the hardware. The name should use the
ASCII encoding, and upper/lower case does not matter.
CreateCursor
cid: CURSOR
source: PIXMAP
mask: PIXMAP or None
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
x, y: CARD16
Errors: IDChoice, Bitmap, Match, Value, Alloc
Creates a cursor and associates identifier cid with it. Foreground and
background RGB values must be specified, even if the server only has a
monochrome screen. The foreground is used for the one bits in the
source, and the background is used for the zero bits. Both source and
mask (if specified) must have depth one (else a Match error), but can
have any root. The mask pixmap defines the shape of the cursor; that
is, the one bits in the mask define which source pixels will be
displayed. If no mask is given, all pixels of the source are
displayed. The mask, if present, must be the same size as source (else
a Match error). The x and y coordinates define the hotspot, relative
to the source's origin, and must be a point within the source (else a
Match error).
The components of the cursor may be transformed arbitrarily to meet
display limitations.
The pixmaps can be freed immediately if no further explicit references
to them are to be made.
Subsequent drawing in the source or mask pixmap has an undefined effect
on the cursor; the server might or might not make a copy of the pixmap.
CreateGlyphCursor
cid: CURSOR
source-font: FONT
mask-font: FONT or None
source-char, mask-char: CARD16
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: IDChoice, Font, Value, Alloc
Similar to CreateCursor, but the source and mask bitmaps are obtained
from the specified font glyphs. The mask font and character are
optional. The origin of the source glyph defines the hotspot, and the
mask is positioned such that the origins are coincident. The source
and mask need not have the same bounding box metrics. If no mask is
given, all pixels of the source are displayed. Note that source-char
and mask-char are CARD16 (not CHAR2B); for two-byte matrix fonts, the
16-bit value should be formed with byte1 in the most significant byte
and byte2 in the least significant byte.
FreeCursor
cursor: CURSOR
Errors: Cursor
Deletes the association between the resource id and the cursor. The
cursor storage will be freed when no other resource references it.
RecolorCursor
cursor: CURSOR
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: Cursor
Changes the color of a cursor. If the cursor is being displayed on a
screen, the change is visible immediately.
QueryBestSize
class: {Cursor, Tile, Stipple}
drawable: DRAWABLE
width, height: CARD16
=>
width, height: CARD16
Errors: Drawable, Value, Match
Returns the "best" size that is "closest" to the argument size. For
Cursor, this is the largest size that can be fully displayed. For
Tile, this is the size that can be tiled "fastest". For Stipple, this
is the size that can be stippled "fastest".
For Cursor, the drawable indicates the desired screen. For Tile and
Stipple, the drawable indicates screen, and also possibly window class
and depth; an InputOnly window cannot be used as the drawable for Tile
or Stipple (else a Match error).
QueryExtension
name: STRING8
=>
present: BOOL
major-opcode: CARD8
first-event: CARD8
first-error: CARD8
Determines if the named extension is present. If so, the major opcode
for the extension is returned, if it has one, otherwise zero is
returned. Any minor opcode and the request formats are specific to the
extension. If the extension involves additional event types, the base
event type code is returned, otherwise zero is returned. The format of
the events is specific to the extension. If the extension involves
additional error codes, the base error code is returned, otherwise
zero is returned. The format of additional data in the errors is
specific to the extension.
The extension name should be in the ASCII encoding, and upper/lower
case matters.
ListExtensions
=>
names: LISTofSTRING8
Returns a list of all extensions supported by the server.
SetKeyboardMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the keyboard. Elements of the list are indexed
starting from one. The list must be of length 255. The index is a
"core" keycode, and the element of the list defines the "effective"
keycode.
A zero element disables a key, no elements can have values 1 through 7,
and no two elements (with index larger than 7) can have the same
non-zero value. If the keyboard does not really generate a given
keycode, specifying a non-zero value for that core keycode has no
effect.
Elements 6 and 7 of the map must always be zero. The first five
elements are special: they specify the keycodes (if any) that
correspond to the Mod1 through Mod5 modifiers. Setting one of these
entries to zero disables use of that modifier bit. No two of the first
five elements can have the same non-zero value.
A server can impose restrictions on how keyboards get remapped, e.g.,
if certain keys do not generate up transitions in hardware.
If any of the keys or modifiers to be altered are currently in the down
state, the status reply is Busy and the mapping is not changed.
GetKeyboardMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the keyboard. Elements of the list are
indexed starting from one. The length of the list is 255.
The nominal mapping for a keyboard is almost the identity mapping,
except that map[i]=0 for keycodes that have no corresponding physical
key, and the first five entries indicate the keycodes (if any)
corresponding to the Mod1 through Mod5 modifier bits.
ChangeKeyboardControl
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Match, Value
Controls various aspects of the keyboard. The value-mask and
value-list specify which controls are to be changed. The possible
values are:
key-click-percent: INT8
bell-percent: INT8
bell-pitch: INT16
bell-duration: INT16
led: CARD8
led-mode: {On, Off}
key: KEYCODE
auto-repeat-mode: {On, Off, Default}
Key-click-percent sets the volume for key clicks between 0 (off) and
100 (loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-percent sets the base volume for the bell between 0 (off) and 100
(loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-pitch sets the pitch (specified in Hz) of the bell, if possible.
Setting to -1 restores the default. Other negative values generate a
Value error.
Bell-duration sets the duration (specified in milliseconds) of the
bell, if possible. Setting to -1 restores the default. Other negative
values generate a Value error.
If both led-mode and led are specified, then the state of that LED is
changed, if possible. If only led-mode is specified, then the state of
all LEDs are changed, if possible. At most 32 LEDs are supported,
numbered from one. It is a Match error if an led is specified without
an led-mode.
If both auto-repeat-mode and key are specified, then the auto-repeat
mode of that key is changed, if possible. If only auto-repeat-mode is
specified, then the global auto-repeat mode for the entire keyboard is
changed, if possible, without affecting the per-key settings. It is a
Match error if a key is specified without an auto-repeat-mode.
A bell generator connected with the console but not directly on the
keyboard is treated as if it were part of the keyboard.
The order in which controls are verified and altered is server
dependent. If an error is generated, a subset of the controls may have
been altered.
GetKeyboardControl
=>
key-click-percent: CARD8
bell-percent: CARD8
bell-pitch: CARD16
bell-duration: CARD16
led-mask: CARD32
global-auto-repeat: {On, Off}
auto-repeats: LISTofCARD8
Errors: Match
Returns the current control values for the keyboard. For the LEDs, the
least significant bit of led-mask corresponds to LED one, and each one
bit in led-mask indicates an LED that is lit. Auto-repeats is a bit
vector; each one bit indicates that auto-repeat is enabled for the
corresponding key. The vector is represented as 32 bytes. Byte N
(from 0) contains the bits for keys 8N to 8N+7, with the least
significant bit in the byte representing key 8N.
Bell
percent: INT8
Errors: Match, Value
Rings the bell on the keyboard at the specified volume relative to the
base volume for the keyboard, if possible. Percent, which can range
from -100 to 100 inclusive, is added to the base volume, and the sum
limited to the range 0 to 100 inclusive.
∂01-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 1 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:21 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 1 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082645.6.RWS@KILLINGTON.LCS.MIT.EDU>
X WINDOW SYSTEM PROTOCOL, VERSION 11
Alpha Update
April 1987
Copyright (c) 1986, 1987 Massachusetts Institute of Technology
X Window System is a trademark of M.I.T.
Permission to use, copy, modify, and distribute this document for any purpose
and without fee is hereby granted, provided that the above copyright notice
appear in all copies and that both that copyright notice and this permission
notice are retained, and that the name of M.I.T. not be used in advertising or
publicity pertaining to this document without specific, written prior
permission. M.I.T. makes no representations about the suitability of this
document or the protocol defined in this document for any purpose. It is
provided "as is" without express or implied warranty.
Author: Robert W. Scheifler
Laboratory for Computer Science
545 Technology Square, Room 418
Cambridge, MA 02139
Contributors:
Dave Carver (Digital HPW)
Branko Gerovac (Digital HPW)
Jim Gettys (MIT/Project Athena, Digital)
Phil Karlton (Digital WSL)
Scott McGregor (Digital SSG)
Ram Rao (Digital UEG)
David Rosenthal (Sun)
Dave Winchell (Digital UEG)
Implementors of initial server who provided useful input:
Susan Angebranndt (Digital)
Raymond Drewry (Digital)
Todd Newman (Digital)
Invited reviewers who provided useful input:
Andrew Cherenson (Berkeley)
Burns Fisher (Digital)
Dan Garfinkel (HP)
Leo Hourvitz (Next)
Brock Krizan (HP)
David Laidlaw (Stellar)
Dave Mellinger (Interleaf)
Ron Newman (MIT)
John Ousterhout (Berkeley)
Andrew Palay (ITC CMU)
Ralph Swick (MIT)
Craig Taylor (Sun)
Jeffery Vroom (Stellar)
This document does not attempt to provide the rationale or pragmatics required
to fully understand the protocol or to place it in perspective within a
complete system. Knowledge of X Version 10 will certainly aid in
understanding this document.
The protocol contains many management mechanisms that are not intended for
normal applications. Not all mechanisms are needed to build a particular user
interface. It is important to keep in mind that the protocol is intended to
provide mechanism, not policy.
This document does not attempt to define precise formats or bit encodings.
-------------------------------------------------------------------------------
SECTION 1. TERMINOLOGY
Access control list
X maintains a list of hosts from which client programs may be run. By
default, only programs on the local host may use the display, plus any
hosts specified in an initial list read by the server. This "access
control list" can be changed by clients on the local host. Some server
implementations may also implement other authorization mechanisms.
Active grab
A grab is "active" when the pointer or keyboard is actually owned by
the single grabbing client.
Ancestors
If W is an inferior of A, then A is an "ancestor" of W.
Atom
An "atom" is a unique id corresponding to a string name. Atoms are
used to identify properties, types, and selections.
Backing store
When a server maintains the contents of a window, the off-screen saved
pixels are known as a "backing store".
Bit gravity
When a window is resized, the contents of the window are not
necessarily discarded. It is possible to request the server (though no
guarantees are made) to relocate the previous contents to some region
of the window. This attraction of window contents for some location of
a window is known as "bit gravity".
Bitmap
A "bitmap" is a pixmap of depth one.
Button grabbing
Buttons on the pointer may be passively "grabbed" by a client. When
the button is pressed, the pointer is then actively grabbed by the
client.
Byte order
For image (pixmap/bitmap) data, byte order is defined by the server,
and clients with different native byte ordering must swap bytes as
necessary. For all other parts of the protocol, the byte order is
defined by the client, and the server swaps bytes as necessary.
Children
The "children" of a window are its first-level subwindows.
Client
An application program connects to the window system server by some
interprocess communication (IPC) path, such as a TCP connection or a
shared memory buffer. This program is referred to as a "client" of the
window system server. More precisely, the client is the IPC path
itself; a program with multiple paths open to the server is viewed as
multiple clients by the protocol. Resource lifetimes are controlled by
connection lifetimes, not by program lifetimes.
Clipping regions
In a graphics context, a bitmap or list of rectangles can be specified
to restrict output to a particular region of the window. The image
defined by the bitmap or rectangles is called a "clipping region".
Color cell
An entry in a colormap is known as a "color cell". An entry contains
three values specifying red, green and blue intensities. These values
are always viewed as 16 bit unsigned numbers, with zero being minimum
intensity. The values are scaled by the server to match the display
hardware. The components of a cell are coincident with components of
other cells in DirectColor and TrueColor colormaps.
Colormap
A "colormap" consists of a set of color cells. A pixel value indexes
the color map to produce intensities to be displayed. Depending on
hardware limitations, one or more colormaps may be installed at one
time, such that windows associated with those maps display with true
colors.
Connection
The IPC path between the server and client program is known as a
"connection". A client program typically (but not necessarily) has one
connection to the server over which requests and events are sent.
Containment
A window "contains" the pointer if the window is viewable and the
hotspot of the cursor is within a visible region of the window or a
visible region of one of its inferiors. The border of the window is
included as part of the window for containment. The pointer is "in" a
window if the window contains the pointer but no inferior contains the
pointer.
Coordinate system
The coordinate system has X horizontal and Y vertical, with the origin
[0, 0] at the upper left. Coordinates are discrete, and in terms of
pixels. Each window and pixmap has its own coordinate system. For a
window, the origin is at the inside upper left, inside the border.
Cursor
A "cursor" is the visible shape of the pointer on a screen. It
consists of a hot spot, a source bitmap, a shape bitmap, and a pair of
colors. The cursor defined for a window controls the visible
appearance when the pointer is in that window.
Depth
The "depth" of a window or pixmap is number of bits per pixel it has.
The depth of a gcontext is the depth of the root of the gcontext.
Device
Keyboards, mice, tablets, track-balls, button boxes, etc. are all
collectively known as input "devices". The core protocol only deals
with two devices, "the keyboard" and "the pointer".
Drawable
Both windows and pixmaps may be used as sources and destinations in
graphics operations. These are collectively known as "drawables".
However, an InputOnly window cannot be used as a source or destination
in a graphics operation.
Event
Clients are informed of information asynchronously via "events". These
events may be either asynchronously generated from devices, or
generated as side effects of client requests. Events are grouped into
types; events are never sent to a client by the server unless the
client has specificially asked to be informed of that type of event,
but other clients can force events to be sent to other clients. Events
are typically reported relative to a window.
Event mask
Events are requested relative to a window. The set of event types a
client requests relative to a window described using an "event mask".
Event sychronization
There are certain race conditions possible when demultiplexing device
events to clients (in particular deciding where pointer and keyboard
events should be sent when in the middle of window management
operations). The event synchronization mechanism allows synchronous
processing of device events.
Event propagation
Device-related events "propagate" from the source window to ancestor
windows until some client has expressed interest in handling that type
of event, or until the event is discarded explicitly.
Event source
The smallest window containing the pointer is the "source" of a device
related event.
Exposure event
Servers do not guarantee to preserve the contents of windows when
windows are obscured or reconfigured. "Exposure" events are sent to
clients to inform them when contents of regions of windows have been
lost.
Extension
Named "extensions" to the core protocol can be defined to extend the
system. Extension to output requests, resources, and event types are
all possible, and expected.
Font
A "font" is an array of glyphs (typically characters). The protocol
does no translation or interpretation of character sets. The client
simply indicates values used to index the glyph array. A font contains
additional metric information to determine inter-glyph and inter-line
spacing.
Glyph
A "glyph" is an image, typically of a character, in a font.
Grab
Keyboard keys, the keyboard, pointer buttons, the pointer, and the
server can be "grabbed" for exclusive use by a client. In general,
these facilities are not intended to be used by normal applications,
but are intended for various input and window managers to implement
various styles of user interfaces.
Graphics context
Various information for graphics output is stored in "GC"'s, such as
foreground pixel, background pixel, line width, clipping region, etc.
Hotspot
A cursor has an associated "hot spot" which defines a point in the
cursor that corresponds to the coordinates reported for the pointer.
Identifier
Each resource has an "identifier", a unique value associated with it
that clients use to name the resource. An identifier can be used over
any connection to name the resource.
Inferiors
The "inferiors" of a window are all of the subwindows nested below it:
the children, the children's children, etc.
Input focus
The "input focus" is nominally where keyboard input goes. Keyboard
events are by default sent to the client expressing interest on the
window the pointer is in. This is said to be a "real estate driven"
input focus. It is also possible to attach the keyboard input to a
specific window; events will then be sent to the appropriate client
independent of the pointer position.
Input manager
Control over keyboard input is typically provided by an "input manager"
client.
InputOnly window
A window that cannot be used for graphics requests. InputOnly windows
are "invisible", and can be used to control such things as cursors,
input event generation, and grabbing.
InputOutput window
The "normal" kind of opaque window, used for both input and output.
Key grabbing
Keys on the keyboard may be passively "grabbed" by a client. When the
key is pressed, the keyboard is then actively grabbed by the client.
Keyboard grabbing
A client can actively "grab" control of the keyboard, and key events
will be sent to that client rather than the client the events would
normally have been sent to.
Mapping
A window is said to be "mapped" if a map call has been performed on it.
Unmapped windows are never viewable or visible.
Modifier keys
Shift, Control, Meta, Super, Hyper, ALT, Compose, Apple, CapsLock,
ShiftLock, and similar keys are called "modifier" keys.
Obscures
Window A "obscures" window B if both are viewable InputOutput windows
and A is higher in the global stacking order, and the rectangle defined
by the outside edges of A intersects the rectangle defined by the
outside edges of B. Note the (fine) distinction with "occludes". Also
note that window borders are included in the calculation.
Occludes
Window A "occludes" window B if both are mapped and A is higher in the
global stacking order, and the rectangle defined by the outside edges
of A intersects the rectangle defined by the outside edges of B. Note
the (fine) distinction with "obscures". Also note that window borders
are included in the calculation.
Padding
Some padding bytes are inserted in the data stream to maintain
alignment of the protocol requests on natural boundaries. This
increases ease of portability to some machine architectures.
Parent window
If C is a child of P, then P is the "parent" of C.
Passive grab
Grabbing a key or button is a "passive" grab. The grab activates when
the key or button is actually pressed.
Pixel value
A "pixel" is an N-bit value, where N is the number of bit planes used
in a particular window or pixmap. For a window, a pixel value indexes
a colormap to derive an actual color to be displayed.
Pixmap
A "pixmap" is a three dimensional array of bits. A pixmap is normally
thought of as a two dimensional array of pixels, where each pixel can
be a value from 0 to (2↑N)-1, where N is the depth (z axis) of the
pixmap. A pixmap can also be thought of as a stack of N bitmaps.
Plane mask
Graphics operations can be restricted to only affect a subset of bit
planes of a destination. A "plane mask" is a bit mask describing which
planes are to be modified, and is stored in a graphics context.
Pointer
The "pointer" is the pointing device attached to the cursor, and
tracked on the screens.
Pointer grabbing
A client can actively "grab" control of the pointer, and button and
motion events will be sent to that client rather than the client the
events would normally have been sent to.
Pointing device
A "pointing device" is typically a mouse or tablet, or some other
device with effective dimensional motion. There is only one visible
cursor is defined by the core protocol, and it tracks whatever pointing
device is attached as the pointer.
Property
Windows may have associated "properties", consisting of a name, a type,
a data format, and some data. The protocol places no interpretation on
properties, they are intended as a general-purpose naming mechanism for
clients. For example, clients might share information such as resize
hints, program names, and icon formats with a window manager via
properties.
Property list
The "property list" of a window is the list of properties that have
been defined for the window.
Redirecting control
Window managers (or client programs) may wish to enforce window layout
policy in various ways. When a client attempts to change the size or
position of a window, the operation may be "redirected" to a specified
client, rather than the operation actually being performed.
Reply
Information requested by a client program is sent back to the client
with a "reply". Both events and replys are multipexed on the same
connection. Most requests do not generate replies.
Request
A command to the server is called a "request". It is a single block of
data sent over a connection.
Resource
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
known as "resources". They all have unique identifiers associated with
them for naming purposes. The lifetime of a resource is bounded by the
lifetime of the connection over which the resource was created.
Root
The "root" of a pixmap or gcontext is the same as the root of whatever
drawable was used when the pixmap or gcontext was created. The "root"
of a window is the root window under which the window was created.
Root window
Each screen has a "root window" covering it. It cannot be reconfigured
or unmapped, but otherwise acts as a full fledged window. A root
window has no parent.
Save set
The "save set" of a client is a list of other client's windows which,
if they are inferiors of one of the client's windows at connection
close, should not be destroyed, and which should be remapped if it is
unmapped. Save sets are typically used by window managers to avoid
lost windows if the manager should terminate abnormally.
Screen
A server may provide several independent "screens", which typically
have physically independent monitors. This would be the expected
configuration when there is only a single keyboard and pointer shared
among the screens.
Server
The "server" provides the basic windowing mechanism. It handles IPC
connections from clients, demultipexes graphics requests onto the
screens, and multiplexes input back to the appropriate clients.
Server grabbing
The server can be "grabbed" by a single client for exclusive use. This
prevents processing of any requests from other client connections until
the grab is complete. This is typically only a transient state for
such things as rubber-banding and pop-up menus, or to execute requests
indivisibly.
Sibling
Children of the same parent window are known as "sibling" windows.
Stacking order
Sibling windows may "stack" on top of each other. Windows above both
obscure and occlude lower windows. This is similar to paper on a desk.
The relationship between sibling windows is known as the "stacking
order".
Stipple
A "stipple pattern" is a bitmap that is used to tile a region to serve
as an additional clip mask for a fill operation with the foreground
color.
Tile
A pixmap can be replicated in two dimensions to "tile" a region. The
pixmap itself is also known as a "tile".
Timestamp
A time value, expressed in milliseconds, typically since the last
server reset. Timestamp values wrap around (after about 49.7 days).
The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the
timestamp space as being earlier in time than T, and half of the
timestamp space as being later in time than T. One timestamp value
(named CurrentTime) is never generated by the server; this value is
reserved for use in requests to represent the current server time.
Type
A type is an arbitrary atom used to identify the interpretation of
property data. Types are completely uninterpreted by the server; they
are solely for the benefit of clients.
Unviewable
A window is "unviewable" if it is mapped but some ancestor is unmapped.
Viewable
A window is "viewable" if it and all of its ancestors are mapped. This
does not imply that any portion of the window is actually visible.
Visible
A region of a window is "visible" if someone looking at the screen can
actually "see" it: the window is viewable and the region is not
occluded by any other window.
Window gravity
When windows are resized, subwindows may be repositioned automatically
relative to some position in the window. This attraction of a
subwindow to some part of its parent is known as "window gravity".
Window manager
Manipulation of windows on the screen, and much of the user interface
(policy) is typically provided by a "window manager" client.
XYFormat
The data for a pixmap is said to be in "XYFormat" if it is organized as
a set of bitmaps representing individual bit planes.
ZFormat
The data for a pixmap is said to be in "ZFormat" if it is organized as
a set of pixel values in scanline order.
SECTION 2. PROTOCOL FORMATS
Request Format
Every request contains an 8-bit "major" opcode, and a 16-bit length field
expressed in units of 4 bytes. Every request consists of 4 bytes of header
(containing the major opcode, the length field, and a data byte) followed by
zero or more additional bytes of data; the length field defines the total
length of the request, including the header. The length field in a request
must equal the minimum length required to contain the request; if the
specified length is smaller or larger than the required length, an error is
generated. Unused bytes in a request are not required to be zero. Major
opcodes 128 through 255 are reserved for extensions. Extensions are intended
to contain multiple requests, so extension requests typically have an
additional minor opcode encoded in the "spare" data byte in the request
header, but the placement and interpretation of this minor opcode, and all
other fields in extension requests, are not defined by the core protocol.
Every request is implicitly assigned a sequence number, starting with one,
used in replies, errors, and events.
Reply Format
Every reply contains a 32-bit length field expressed in units of 4 bytes.
Every reply consists of 32 bytes, followed by zero or more additional bytes of
data, as specified in the length field. Unused bytes within a reply are not
guaranteed to be zero. Every reply also contains the least significant 16
bits of the sequence number of the corresponding request.
Error Format
Error reports are 32 bytes long. Every error includes an 8-bit error code.
Error codes 128 through 255 are reserved for extensions. Every error also
includes the major and minor opcodes of the failed request, and the least
significant 16 bits of the sequence number of the request. For the following
errors (see Section 5), the failing resource id is also returned: Colormap,
Cursor, Drawable, Font, GContext, IDChoice, Pixmap, and Window. For Atom
errors, the failing atom is returned. For Value errors, the failing value is
returned. Other core errors return no additional data. Unused bytes within
an error are not guaranteed to be zero.
Event Format
Events are 32 bytes long. Unused bytes within an event are not guaranteed to
be zero. Every event contains an 8-bit type code. The most significant bit
in this code is set if the event was generated from a SendEvent request.
Event codes 64 through 127 are reserved for extensions, although the core
protocol does not define a mechanism for selecting interest in such events.
Every core event (with the exception of KeymapNotify) also contains the least
significant 16 bits of the sequence number of the last request issued by the
client that was (or is currently being) processed by the server.
SECTION 3. SYNTAX
The syntax {...} encloses a set of alternatives.
The syntax [...] encloses a set of structure components.
In general, TYPEs are in upper case and AlternativeValues are capitalized.
Requests in Section 10 are described in the following format:
RequestName
arg1: type1
...
argN: typeN
=>
result1: type1
...
resultM: typeM
Errors: kind1, ..., kindK
Description.
If no => is present in the description, then the request has no reply (it is
asynchronous), although errors may still be reported.
Events in Section 12 are described in the following format:
EventName
value1: type1
...
valueN: typeN
Description.
SECTION 4. COMMON TYPES
LISTofFOO
A type name of the form LISTofFOO means a counted list of elements of type
FOO; the size of the length field may vary (it is not necessarily the same
size as a FOO), in some cases may be implicit, and is not fully specified in
this document.
BITMASK and LISTofVALUE
The types BITMASK and LISTofVALUE are somewhat special. Various requests
contain arguments of the form:
value-mask: BITMASK
value-list: LISTofVALUE
used to allow the client to specify a subset of a heterogeneous collection of
"optional" arguments. The value-mask specifies which arguments are to be
provided; each such argument is assigned a unique bit position. The
representation of the BITMASK will typically contain more bits than there are
defined arguments; unused bits in the value-mask must be zero (or the server
generates a Value error). The value-list contains one value for each one bit
in the mask, from least to most significant bit in the mask. Each value is
represented with 4 bytes, but the actual value occupies only the least
significant bytes as required; the values of the unused bytes do not matter.
Or Types
A type of the form "T1 or ... or Tn" means the union of the indicated types; a
single-element type is given as the element without enclosing braces.
DEVICE: 32-bit id (<class,model,manufacturer,unit> 8 bits each)
WINDOW: 32-bit id
PIXMAP: 32-bit id
CURSOR: 32-bit id
FONT: 32-bit id
GCONTEXT: 32-bit id
COLORMAP: 32-bit id
DRAWABLE: WINDOW or PIXMAP
ATOM: 32-bit id (top 3 bits guaranteed to be zero)
VISUALID: 32-bit id (top 3 bits guaranteed to be zero)
VALUE: 32-bit quantity (used only in LISTofVALUE)
INT8: 8-bit signed integer
INT16: 16-bit signed integer
INT32: 32-bit signed integer
CARD8: 8-bit unsigned integer
CARD16: 16-bit unsigned integer
CARD32: 32-bit unsigned integer
TIMESTAMP: CARD32
BITGRAVITY: {Forget, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
WINGRAVITY: {Unmap, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
BOOL: {True, False}
EVENT: {KeyPress, KeyRelease,
OwnerGrabButton,
ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
Exposure, VisibilityChange,
StructureNotify, ResizeRedirect,
SubstructureNotify, SubstructureRedirect,
FocusChange,
PropertyChange, ColormapChange,
KeymapState}
POINTEREVENT: {ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
KeymapState}
DEVICEEVENT: {KeyPress, KeyRelease,
ButtonPress, ButtonRelease,
PointerMotion,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion}
KEYCODE: CARD8
BUTTON: CARD8
KEYMASK: {Shift, CapsLock, Control, Mod1, Mod2, Mod3, Mod4, Mod5}
BUTMASK: {Button1, Button2, Button3, Button4, Button5}
KEYBUTMASK: KEYMASK or BUTMASK
STRING8: LISTofCARD8
STRING16: LISTofCHAR2B
CHAR2B: [byte1, byte2: CARD8]
POINT: [x, y: INT16]
RECTANGLE: [x, y: INT16,
width, height: CARD16]
ARC: [x, y: INT16,
width, height: CARD16,
angle1, angle2: INT16]
HOST: [family: {Internet, NS, ECMA, Datakit, DECnet}
address: LISTofCARD8]
The [x,y] coordinates of a RECTANGLE specify the upper left corner.
The primary interpretation of "large" characters in a STRING16 is that they
are composed of two bytes used to index a 2-D matrix; hence the use of CHAR2B
rather than CARD16. This corresponds to the JIS/ISO method of indexing
two-byte characters. It is expected that most "large" fonts will be defined
with two-byte matrix indexing. For large fonts constructed with linear
indexing, a CHAR2B can be interpreted as a 16-bit number by treating byte1 as
the most significant byte; this means that clients should always transmit such
16-bit character values most significant byte first, as the server will never
byte-swap CHAR2B quantities.
The length, format, and interpretation of a HOST address are specific to the
family.
SECTION 5. ERRORS
In general, when a request terminates with an error, the request has no side
effects (i.e., there is no partial execution). The only requests for which
this is not true are ChangeWindowAttributes, ChangeGC, PolyText8, PolyText16,
FreeColors, StoreColors, and ChangeKeyboardControl.
The following error codes can be returned by the various requests:
Access
An attempt to grab a key/button combination already grabbed by another
client.
An attempt to free a colormap entry not allocated by the client.
An attempt to store into a read-only or an unallocated colormap entry.
An attempt to modify the access control list from other than the local
(or otherwise authorized) host.
An attempt to select an event type, that at most one client can
select at a time, when another client has already selected it.
Alloc
The server failed to allocate the requested resource.
Note that this only covers allocation errors at a very coarse level,
and is not intended to (nor can it in practice hope to) cover all cases
of a server running out of allocation space in the middle of service.
The semantics when a server runs out of allocation space are left
unspecified.
Atom
A value for an ATOM argument does not name a defined ATOM.
Colormap
A value for a COLORMAP argument does not name a defined COLORMAP.
Cursor
A value for a CURSOR argument does not name a defined CURSOR.
Drawable
A value for a DRAWABLE argument does not name a defined WINDOW or
PIXMAP.
Font
A value for a FONT or <FONT or GCONTEXT> argument does not name a
defined FONT.
GContext
A value for a GCONTEXT argument does not name a defined GCONTEXT.
IDChoice
The value chosen for a resource identifier is either not included
in the range assigned to the client, or is already in use.
Implementation
The server does not implement some aspect of the request. A server
which generates this error for a core request is deficient. As such,
this error is not listed for any of the requests, but clients should be
prepared to receive such errors, and handle or discard them.
Length
The length of a request is shorter or longer than that required
to minimally contain the arguments.
Match
An InputOnly window is used as a DRAWABLE.
Some argument (or pair of arguments) has the correct type and range,
but fails to "match" in some other way required by the request.
Name
A font or color of the specified name does not exist.
Pixmap
A value for a PIXMAP argument does not name a defined PIXMAP.
Property
The requested property does not exist for the specified window.
Request
The major or minor opcode does not specify a valid request.
Value
Some numeric value falls outside the range of values accepted by the
request. Unless a specific range is specified for an argument, the
full range defined by the argument's type is accepted. Any argument
defined as a set of alternatives can generate this error.
Window
A value for a WINDOW argument does not name a defined WINDOW.
Note: the Atom, Colormap, Cursor, Drawable, Font, GContext, Pixmap, and Window
errors are also used when the argument type is extended by union with a set of
fixed alternatives, e.g., <Window or PointerRoot or None>.
∂01-Jun-87 0529 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 4 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 4 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082815.9.RWS@KILLINGTON.LCS.MIT.EDU>
QueryFont
font: FONT or GCONTEXT
=>
font-info: FONTINFO
char-infos: LISTofCHARINFO
where
FONTINFO: [draw-direction: {LeftToRight, RightToLeft}
min-char-or-byte2, max-char-or-byte2: CARD16
min-byte1, max-byte1: CARD8
all-chars-exist: BOOL
default-char: CARD16
min-bounds: CHARINFO
max-bounds: CHARINFO
font-ascent: INT16
font-descent: INT16
properties: LISTofFONTPROP]
FONTPROP: [name: ATOM
value: INT32 or CARD32]
CHARINFO: [left-side-bearing: INT16
right-side-bearing: INT16
character-width: INT16
ascent: INT16
descent: INT16
attributes: CARD16]
Errors: Font
Returns logical information about a font.
The draw-direction is essentially just a hint, indicating whether most
char-infos have a positive (LeftToRight) or a negative (RightToLeft)
character-width metric. The core protocol defines no support for
vertical text.
If min-byte1 and max-byte1 are both zero, then min-char-or-byte2
specifies the linear character index corresponding to the first elementb
of char-infos, and max-char-or-byte2 specifies the linear character
index of the last element. If either min-byte1 or max-byte1 are
non-zero, then both min-char-or-byte2 and max-char-or-byte2 will be
less than 256, and the two-byte character index values corresponding to
char-infos element N (counting from 0) are
byte1 = N/D + min-byte1
byte2 = N\D + min-char-or-byte2
where
D = max-char-or-byte2 - min-char-or-byte2 + 1
/ = integer division
\ = integer modulus
If char-infos has length zero, then min-bounds and max-bounds will be
identical, and the effective char-infos is one filled with this
char-info, of length
L = D * (max-byte1 - min-byte1 + 1)
That is, all glyphs in the specified linear or matrix range have the
same information, as given by min-bounds (and max-bounds). If
all-chars-exist is True, then all characters in char-infos have
non-zero bounding boxes.
The default-char specifies the character that will be used when an
undefined or non-existent character is used. Note that default-char is
a CARD16 (not CHAR2B); for a font using two-byte matrix format, the
default-char has byte1 in the most significant byte, and byte2 in the
least significant byte. If the default-char itself specifies an
undefined or non-existent character, then no printing is performed for
an undefined or non-existent character.
The min-bounds and max-bounds contain the minimum and maximum values of
each individual CHARINFO component over all char-infos (ignoring
non-existent characters). The bounding box of the font, i.e., the
smallest rectangle enclosing the shape obtained by superimposing all
characters at the same origin [x,y], has its upper left coordinate at
[x + min-bounds.left-side-bearing, y - max-bounds.ascent]
with a width of
max-bounds.right-side-bearing - min-bounds.left-side-bearing
and a height of
max-bounds.ascent + max-bounds.descent
The font-ascent is the logical extent of the font above the baseline,
for determining line spacing. Specific characters may extend beyond
this. The font-descent is the logical extent of the font at or below
the baseline, for determining line spacing. Specific characters may
extend beyond this. If the baseline is at Y-coordinate y, then the
logical extent of the font is inclusive between the Y-coordinate values
(y - font-ascent) and (y + font-descent - 1).
A font is not guaranteed to have any properties. Whether a property
value is signed or unsigned must be derived from a priori knowledge of
the property. When possible, fonts should have at least the following
properties (note that the trailing colon is not part of the name, and
that upper/lower case matters).
MinSpace: CARD32
The minimum interword spacing, in pixels.
NormSpace: CARD32
The normal interword spacing, in pixels.
MaxSpace: CARD32
The maximum interword spacing, in pixels.
EndSpace: CARD32
The additional spacing at the end of sentences, in pixels.
SuperscriptX: INT32
SuperscriptY: INT32
Offsets from the character origin where superscripts should begin,
in pixels. If the origin is at [x,y], then superscripts should
begin at [x + SuperscriptX, y - SuperscriptY].
SubscriptX: INT32
SubscriptY: INT32
Offsets from the character origin where subscripts should begin, in
pixels. If the origin is at [x,y], then subscripts should begin at
[x + SubscriptX, y + SubscriptY].
UnderlinePosition: INT32
Y offset from the baseline to the top of an underline, in pixels.
If the baseline is Y-coordinate y, then the top of the underline is
at (y + UnderlinePosition).
UnderlineThickness: CARD32
Thickness of the underline, in pixels.
StrikeoutAscent: INT32
StrikeoutDescent: INT32
Vertical extents for boxing or voiding characters, in pixels. If
the baseline is at Y-coordinate y, then the top of the strikeout
box is at (y - StrikeoutAscent), and the height of the box is
(StrikeoutAscent + StrikeoutDescent).
ItalicAngle: INT32
The angle of characters in the font, in degrees scaled by 64,
relative to the three-oclock position from the character origin,
with positive indicating counterclockwise motion (as in Arc
requests).
XHeight: INT32
"1 ex" as in TeX, but expressed in units of pixels. Often the
height of lowercase x.
QuadWidth: INT32
"1 em" as in TeX, but expressed in units of pixels. Often the
width of the digits 0-9.
Weight: CARD32
The weight or boldness of the font, expressed as a value between 0
and 1000.
PointSize: CARD32
The point size, expressed in 1/10ths, of this font at the ideal
resolution. There are 72.27 points to the inch.
Resolution: CARD32
The number of pixels per point, expressed in 1/100ths, at which
this font was created.
For a character origin at [x,y], the bounding box of a character, i.e.,
the smallest rectangle enclosing the character's shape, described in
terms of CHARINFO components, is a rectangle with its upper left corner
at
[x + left-side-bearing, y - ascent]
with a width of
right-side-bearing - left-side-bearing
and a height of
ascent + descent
and the origin for the next character is defined to be
[x + character-width, y]
Note that the baseline is logically viewed as being just below
non-descending characters (when descent is zero, only pixels with
Y-coordinates less than y are drawn), and that the origin is logically
viewed as being coincident with the left edge of a non-kerned character
(when left-side-bearing is zero, no pixels with X-coordinate less than
x are drawn).
Note that CHARINFO metric values can be negative.
A non-existent character is represented with all CHARINFO components
zero.
The interpretation of the per-character attributes field is undefined
by the core protocol.
QueryTextExtents
font: FONT or GCONTEXT
items: STRING16
=>
draw-direction: {LeftToRight, RightToLeft}
font-ascent: INT16
font-descent: INT16
overall-ascent: INT16
overall-descent: INT16
overall-width: INT32
overall-left: INT32
overall-right: INT32
Errors: Font
Returns the logical extents of the specified string of characters in
the specified font. Draw-direction, font-ascent, and font-descent are
as described in QueryFont. Overall-ascent is the maximum of the ascent
metrics of all characters in the string, and overall-descent is the
maximum of the descent metrics. Overall-width is the sum of the
character-width metrics of all characters in the string. For each
character in the string, let W be the sum of the character-width
metrics of all characters preceding it in the string, let L be the
left-side-bearing metric of the character plus W, and let R be the
right-side-bearing metric of the character plus W. Overall-left is the
minimum L of all characters in the string, and overall-right is the
maximum R.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
If the font has no defined default-char, then undefined characters in
the string are taken to have all zero metrics.
ListFonts
pattern: STRING8
max-names: CARD16
=>
names: LISTofSTRING8
Returns a list of length at most max-names, of names of fonts matching
the pattern. The pattern should use the ASCII encoding, and
upper/lower case does not matter. In the pattern, the '?' character
(octal value 77) will match any single character, and the character '*'
(octal value 52) will match any number of characters. The returned
names are in lower case.
ListFontsWithInfo
pattern: STRING8
max-names: CARD16
=>
fonts: LISTofFONTDATA
where
FONTDATA: [name: STRING8
info: FONTINFO]
FONTINFO: <same type definition as in QueryFont>
Like ListFonts, but also returns information about each font. The
information returned for each font is identical to what QueryFont would
return (except that the per-character metrics are not returned).
SetFontPath
path: LISTofSTRING8
Errors: Value
Defines the search path for font lookup. There is only one search path
per server, not one per client. The interpretation of the strings is
operating system dependent, but they are intended to specify
directories to be searched in the order listed.
Setting the path to the empty list restores the default path defined
for the server.
As a side-effect of executing this request, the server is guaranteed to
flush all cached information about fonts for which there currently are
no explicit resource ids allocated.
The meaning of an error from this request is system specific.
GetFontPath
=>
path: LISTofSTRING8
Returns the current search path for fonts.
CreatePixmap
pid: PIXMAP
drawable: DRAWABLE
depth: CARD8
width, height: CARD16
Errors: IDChoice, Drawable, Value, Alloc
Creates a pixmap, and assigns the identifier pid to it. Width and
height must be non-zero. Depth must be one of the depths supported by
root of the specified drawable. The initial contents of the pixmap are
undefined.
It is legal to pass an InputOnly window as a drawable to this request.
FreePixmap
pixmap: PIXMAP
Errors: Pixmap
Deletes the association between the resource id and the pixmap. The
pixmap storage will be freed when no other resource references it.
CreateGC
cid: GCONTEXT
drawable: DRAWABLE
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Drawable, Pixmap, Font, Match, Value, Alloc
Creates a graphics context, and assigns the identifier cid to it. The
gcontext can be used with any destination drawable having the same root
and depth as the specified drawable.
The value-mask and value-list specify which components are to be
explicitly initialized. The context components are:
alu-function: {Clear, And, AndReverse, Copy, AndInverted, Noop,
Xor, Or, Nor, Equiv, Invert, OrReverse,
CopyInverted, OrInverted, Nand, Set}
plane-mask: CARD32
foreground: CARD32
background: CARD32
line-width: CARD16
line-style: {Solid, OnOffDash, DoubleDash}
cap-style: {NotLast, Butt, Round, Projecting}
join-style: {Miter, Round, Bevel}
fill-style: {Solid, Tiled, OpaqueStippled, Stippled}
fill-rule: {EvenOdd, Winding}
arc-mode: {Chord, PieSlice}
tile: PIXMAP
stipple: PIXMAP
tile-stipple-x-origin: INT16
tile-stipple-y-origin: INT16
font: FONT
subwindow-mode: {ClipByChildren, IncludeInferiors}
graphics-exposures: BOOL
clip-x-origin: INT16
clip-y-origin: INT16
clip-mask: PIXMAP or None
dash-offset: CARD16
dash-list: CARD8
In graphics operations, given a source and destination pixel, the
result is computed bitwise on corresponding bits of the pixels. That
is, a boolean operation is performed in each bit plane. The plane-mask
restricts the operation to a subset of planes. That is, the result is
((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))
Range checking is not performed on the values for foreground,
background, or plane-mask; they are simply truncated to the appropriate
number of bits.
The meanings of the alu-functions are:
Clear 0
And src AND dst
AndReverse src AND (NOT dst)
Copy src
AndInverted (NOT src) AND dst
NoOp dst
Xor src XOR dst
Or src OR dst
Nor (NOT src) AND (NOT dst)
Equiv (NOT src) XOR dst
Invert NOT dst
OrReverse src OR (NOT dst)
CopyInverted NOT src
OrInverted (NOT src) OR dst
NAnd (NOT src) OR (NOT dst)
Set 1
Line-width is measured in pixels and can be greater than or equal to
one (a "wide" line) or the special value zero (a "thin" line).
Wide lines are drawn centered on the path described by the graphics
request. Unless otherwise specified by the join or cap style, the
bounding box of a wide line with endpoints [x1, y1], [x2, y2], and
width w is a rectangle with vertices at the following real coordinates:
[x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
[x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]
where sn is the sine of the angle of the line and cs is the cosine of
the angle of the line. A pixel is part of the line (and hence drawn)
if the center of the pixel is fully inside the bounding box (which is
viewed as having infinitely thin edges). If the center of the pixel is
exactly on the bounding box, it is part of the line if and only if the
interior is immediately to its right (x increasing direction). Pixels
with centers on a horizontal edge are a special case and are part of
the line if and only if the interior is immediately below (y increasing
direction). Note that this description is a mathematical model
describing the pixels that are drawn for a wide line and does not imply
that trigonometry is required to implement such a model. Real or fixed
point arithmetic is recommended for computing the corners of the line
endpoints for lines greater than one pixel in width.
Thin lines (zero line-width) are "one pixel wide" lines drawn using an
unspecified, device dependent algorithm (for example, Bresenham).
There are only two constraints on this algorithm. First, if a line is
drawn unclipped from [x1,y1] to [x2,y2] and another line is drawn
unclipped from [x1+dx,y1+dy] to [x2+dx,y2+dy], then a point [x,y] is
touched by drawing the first line if and only if the point [x+dx,y+dy]
is touched by drawing the second line. Second, the effective set of
points comprising a line cannot be affected by clipping; that is, a
point is touched in a clipped line if and only if the point lies inside
the clipping region and the point would be touched by the line when
drawn unclipped.
Note that a wide line drawn from [x1,y1] to [x2,y2] always draws the
same pixels as a wide line drawn from [x2,y2] to [x1,y1], not counting
cap and join styles, but this property is not guaranteed for thin
lines. Also note that "jags" in adjacent wide lines will always line
up properly, but this property is not guaranteed for thin lines. A
line-width of zero differs from a line-width of one in which pixels are
drawn. In general, drawing a thin line will be faster than drawing a
wide line of width one, but thin lines may not mix well aesthetically
with wide lines because of the different drawing algorithms. If it is
desirable to obtain precise and uniform results across all displays, a
client should always use a line-width of one, rather than a line-width
of zero.
The line-style defines which segments of a line are drawn:
Solid: the full path of the line is drawn
DoubleDash: the full path of the line is drawn, but the segments
defined by the even dashes are filled differently than
the segments defined by the odd dashes (see fill-style)
OnOffDash: only the segments defined by the even dashes are drawn,
and cap-style applies to each individual segment (except
NotLast is treated as Butt for internal caps)
The cap-style defines how the endpoints of a path are drawn:
NotLast: equivalent to Butt, except that for a line-width
of zero or one the final endpoint is not drawn
Butt: square at the endpoint, with no projection beyond
Round: a circular arc with diameter equal to the line-width,
centered on the endpoint; equivalent to Butt for line-width
zero or one
Projecting: square at the end, but the path continues beyond the
endpoint for a distance equal to half the line-width;
equivalent to Butt for line-width zero or one
The join-style defines how corners are drawn for wide lines:
Miter: the outer edges of the two lines extend to meet at an
angle
Round: a circular arc with diameter equal to the line-width,
centered on the joinpoint
Bevel: Butt endpoint styles, and then the triangular "notch" filled
The tile/stipple and clip origins are interpreted relative to the
origin of whatever destination drawable is specified in a graphics
request.
The tile pixmap must have the same root and depth as the gcontext (else
a Match error). The stipple pixmap must have depth one, and must have
the same root as the gcontext (else a Match error). For stipple
operations, the stipple pattern is tiled in a single plane, and acts as
an additional clip mask to be ANDed with the clip-mask. Any size
pixmap can be used for tiling or stippling, although some sizes may be
faster to use than others.
The fill-style defines the contents of the source for line, text, and
fill requests. For all text and fill requests (PolyText8, PolyText16,
PolyFillRectangle, FillPoly, PolyFillArc), for line requests (PolyLine,
PolySegment, PolyRectangle, PolyArc) with line-style Solid, and for the
even dashes for line requests with line-style OnOffDash or DoubleDash:
Solid: foreground
Tiled: tile
OpaqueStippled: a tile with the same width and height as stipple,
but with background everywhere stipple has a zero
and with foreground everywhere stipple has a one
Stippled: foreground masked by stipple
For the odd dashes for line requests with line-style DoubleDash:
Solid: background
Tiled: same as for even dashes
OpaqueStippled: same as for even dashes
Stippled: background masked by stipple
The dash-list value allowed here is actually a simplified form of the
more general patterns that can be set with SetDashes. Specifying a
value of N here is equivalent to specifying the two element list [N, N]
in SetDashes. The value must be non-zero. The meaning of dash-offset
and dash-list are explained in the SetDashes request.
The clip-mask restricts writes to the destination drawable; only pixels
where the clip-mask has a one bit are drawn. It affects all graphics
requests. The clip-mask does not clip sources. The clip-mask origin
is interpreted relative to the origin of whatever destination drawable
is specified in a graphics request. If a pixmap is specified as the
clip-mask, it must have depth one and have the same root as the
gcontext (else a Match error). The clip-mask can also be set with the
SetClipRectangles request.
For ClipByChildren, both source and destination windows are
additionally clipped by all viewable InputOutput children. For
IncludeInferiors, neither source nor destination window is clipped by
inferiors; this will result in drawing through subwindow boundaries.
The use of IncludeInferiors on a window of one depth with mapped
inferiors of differing depth is not illegal, but the semantics is
undefined by the core protocol.
The fill-rule defines what pixels are inside (i.e., are drawn) for
paths given in FillPoly requests. EvenOdd means a point is inside if
an infinite ray with the point as origin crosses the path an odd number
of times. For Winding, a point is inside if an infinite ray with the
point as origin crosses an unequal number of clockwise and
counterclockwise directed path segments. For both rules, a "point" is
infinitely small, and the path is an infinitely thin line. A pixel is
inside if the center point of the pixel is inside and the center point
is not on the boundary. If the center point is on the boundary, the
pixel is inside if and only if the polygon interior is immediately to
its right (x increasing direction). Pixels with centers along a
horizontal edge are a special case and are inside if and only if the
polygon interior is immediately below (y increasing direction).
The arc-mode controls filling in the PolyFillArc request.
The graphics-exposures flag controls GraphicsExposure event generation
for CopyArea and CopyPlane requests (and any similar requests defined
by extensions).
The default component values are:
function: Copy
plane-mask: all ones
foreground: 0
background: 1
line-width: 0
line-style: Solid
cap-style: Butt
join-style: Miter
fill-style: Solid
full-rule: EvenOdd
arc-mode: PieSlice
tile: pixmap of unspecified size filled with foreground pixel
(i.e., client specified pixel if any, else 0)
stipple: pixmap of unspecified size filled with ones
tile-stipple-x-origin: 0
tile-stipple-y-origin: 0
font: <implementation dependent>
subwindow-mode: ClipByChildren
graphics-exposures: True
clip-x-origin: 0
clip-y-origin: 0
clip-mask: None
dash-offset: 0
dash-list: 4 (i.e., the list [4, 4])
Storing a pixmap in a gcontext might or might not result in a copy
being made. If the pixmap is later used as the destination for a
graphics request, the change might or might not be reflected in the
gcontext. If the pixmap is used simultaneously in a graphics request
as both a destination and as a tile or stipple, the results are not
defined.
It is quite likely that some amount of gcontext information will be
cached in display hardware, and that such hardware can only cache a
small number of gcontexts. Given the number and complexity of
components, clients should view switching between gcontexts with nearly
identical state as significantly more expensive than making minor
changes to a single gcontext.
ChangeGC
gc: GCONTEXT
value-mask: BITMASK
value-list: LISTofVALUE
Errors: GContext, Pixmap, Font, Match, Value, Alloc
Changes components in gc. The value-mask and value-list specify which
components are to be changed. The values and restrictions are the same
as for CreateGC.
Changing the clip-mask also overrides any previous SetClipRectangles
request on the context. Changing the dash-offset or dash-list
overrides any previous SetDashes request on the context.
The order in which components are verified and altered is server
dependent. If an error is generated, a subset of the components may
have been altered.
CopyGC
src-gc, dst-gc: GCONTEXT
value-mask: BITMASK
Errors: GContext, Value, Match, Alloc
Copies components from src-gc to dst-gc. The value-mask specifies
which components to copy, as for CreateGC. The two gcontexts must have
the same root and the same depth (else a Match error).
SetDashes
gc: GCONTEXT
dash-offset: CARD16
dash-list: LISTofCARD8
Errors: GContext, Value, Alloc
Sets the dash-offset and dash-list in gc for dashed line styles. The
initial and alternating elements of the dash-list are the "even"
dashes, the others are the "odd" dashes. All of the elements must be
non-zero. The dash-offset defines the phase of the pattern, specifying
how many pixels into the dash-list the pattern should actually begin in
any single graphics request. Dashing is continuous through path
segments combined with a join-style, but is reset to the dash-offset
each time a cap-style is applied.
SetClipRectangles
gc: GCONTEXT
clip-x-origin, clip-y-origin: INT16
rectangles: LISTofRECTANGLE
ordering: {UnSorted, YSorted, YXSorted, YXBanded}
Errors: GContext, Value, Alloc, Match
Changes clip-mask in gc to the specified list of rectangles and sets
the clip origin. Output will be clipped to remain contained within the
rectangles. The clip origin is interpreted relative to the origin of
whatever destination drawable is specified in a graphics request. The
rectangle coordinates are interpreted relative to the clip origin. The
rectangles should be non-intersecting, or graphics results will be
undefined.
If known by the client, ordering relations on the rectangles can be
specified with the ordering argument; this may provide faster operation
by the server. If an incorrect ordering is specified, the server may
generate a Match error, but is not required to do so; if no error is
generated, the graphics results are undefined. UnSorted means the
rectangles are in arbitrary order. YSorted means that the rectangles
are non-decreasing in their Y origin. YXSorted additionally constrains
YSorted order in that all rectangles with an equal Y origin are
non-decreasing in their X origin. YXBanded additionally constrains
YXSorted by requiring that for every possible Y scanline, all
rectangles that include that scanline have identical Y origins and Y
extents.
FreeGC
gc: GCONTEXT
Errors: GContext
Deletes the association between the resource id and the gcontext, and
destroys the gcontext.
ClearToBackground
window: WINDOW
x, y: INT16
width, height: CARD16
exposures: BOOL
Errors: Window, Value, Match
The x and y coordinates are relative to the window's origin, and
specify the upper left corner of the rectangle. If width is zero, it
is replaced with the current width of the window minus x. If height is
zero, it is replaced with the current height of the window minus y. If
the window has a defined background tile, the rectangle is tiled with a
plane-mask of all ones and alu-function of Copy. If the window has
background None, the contents of the window are not changed. In either
case, if exposures is True, then one or more exposure events are
generated for regions of the rectangle that are either visible or are
being retained in a backing store.
It is a Match error to use an InputOnly window in this request.
CopyArea
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
Errors: Drawable, GContext, Match
Combines the specified rectangle of src-drawable with the specified
rectangle of dst-drawable. The src-x and src-y coordinates are
relative to src-drawable's origin, dst-x and dst-y are relative to
dst-drawable's origin, each pair specifying the upper left corner of
the rectangle. Src-drawable must have the same root and the same depth
as dst-drawable (else a Match error).
If regions of the source rectangle are obscured and have not been
retained by the server, or if regions outside the boundaries of the
source drawable are specified, then the following occurs. If the
dst-drawable is a window with a background of other than None, the
corresponding regions of the destination are tiled (with plane-mask of
all ones and alu-function Copy) with that background. Regardless, if
graphics-exposures in gc is True, GraphicsExposure events for the
corresponding destination regions are generated.
If graphics-exposures is True but no regions are exposed, then a
NoExposure event is generated.
GC components: alu-function, plane-mask, subwindow-mode,
graphics-exposures, clip-x-origin, clip-y-origin, clip-mask
CopyPlane
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
bit-plane: CARD32
Errors: Drawable, GContext, Value, Match
Src-drawable must have the same root as dst-drawable (else a Match
error), but need not have the same depth. Bit-plane must have exactly
one bit set. Effectively, that plane of the src-drawable and the
foreground/background pixels in gc are combined to form a pixmap of the
same depth as dst-drawable, and the equivalent of a CopyArea is
performed, with all the same exposure semantics.
GC components: alu-function, plane-mask, foreground, background,
subwindow-mode, graphics-exposures, clip-x-origin, clip-y-origin,
clip-mask
PolyPoint
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Combines the foreground pixel in gc with the pixel at each point in the
drawable. The points are drawn in the order listed.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, foreground, subwindow-mode,
clip-x-origin, clip-y-origin, clip-mask
PolyLine
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Draws lines between each pair of points (point[i], point[i+1]). The
lines are drawn in the order listed. The lines join correctly at all
intermediate points, and if the first and last points coincide, the
first and last lines also join correctly.
For any given line, no pixel is drawn more than once. If thin (zero
line-width) lines intersect, the intersecting pixels are drawn multiple
times. If wide lines intersect, the intersecting pixels are drawn only
once, as though the entire PolyLine were a single filled shape.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolySegment
drawable: DRAWABLE
gc: GCONTEXT
segments: LISTofSEGMENT
where SEGMENT: [x1, y1, x2, y2: INT16]
Errors: Drawable, GContext, Match
For each segment, draws a line between [x1, y1] and [x2, y2]. The
lines are drawn in the order listed. No joining is performed at
coincident end points. For any given line, no pixel is drawn more than
once. If lines intersect, the intersecting pixels are drawn multiple
times.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolyRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Draws the outlines of the specified rectangles, as if a five-point
PolyLine were specified for each rectangle. The x and y coordinates of
each rectangle are relative to the drawable's origin, and define the
upper left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, line-width, line-style,
join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 2 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:59 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 2 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082720.7.RWS@KILLINGTON.LCS.MIT.EDU>
SECTION 6. KEYBOARDS
Keycodes are always in the inclusive range [8,255].
For keyboards with both left-side and right-side modifier keys (e.g., Shift
and Control), the mask bits in the protocol always define the OR of the keys.
If electronically distinguishable, they can have separate up/down events
generated, and clients that want to distinguish can track the individual
states manually.
<As part of the core we need to define a universal association between keycaps
and keycodes. A keycap is the graphical information imprinted on a keyboard
key, e.g., "$ 4", "T", "+ =".>
SECTION 7. POINTERS
Buttons are always numbered starting with one.
SECTION 8. PREDEFINED ATOMS
Predefined atoms are not strictly necessary, and may not be useful in all
environments, but will eliminate many InternAtom requests in most
applications. The core protocol imposes no semantics on these names, except
as they are used in FONTPROP structures (see QueryFont). Note that
upper/lower case matters.
BITMAP ICON_SIZE RGB_GREEN_MAP
COMMAND ITALIC_ANGLE RGB_RED_MAP
COPYRIGHT MAX_SPACE SECONDARY
CUT_BUFFER0 MIN_SPACE SIZE_HINTS
CUT_BUFFER1 NAME STRIKEOUT_ASCENT
CUT_BUFFER2 NORMAL_HINTS STRIKEOUT_DESCENT
CUT_BUFFER3 NORM_SPACE STRING
CUT_BUFFER4 PIXMAP SUBSCRIPT_X
CUT_BUFFER5 POINT_SIZE SUBSCRIPT_Y
CUT_BUFFER6 PRIMARY SUPERSCRIPT_X
CUT_BUFFER7 QUAD_WIDTH SUPERSCRIPT_Y
DEFAULT_CHAR RECTANGLE UNDERLINE_POSITION
END_SPACE RESIZE_HINT UNDERLINE_THICKNESS
FACE_NAME RESOLUTION WEIGHT
FAMILY_NAME RGB_BEST_MAP WINDOW
FONT_ASCENT RGB_BLUE_MAP WM_HINTS
FONT_DESCENT RGB_COLOR_MAP X_HEIGHT
ICON RGB_DEFAULT_MAP ZOOM_HINTS
ICON_NAME
SECTION 9. CONNECTION SETUP
For remote clients, the X protocol can be built on top of any reliable byte
stream. For TCP connections, displays on a given host a numbered starting
from 0, and the server for display N listens and accepts connections on port
6000+N.
The client must send an initial byte of data to identify the byte order to be
employed. The value of the byte must be octal 102 or 154. The value 102
(ASCII uppercase B) means values are transmitted most significant byte first,
and value 154 (ASCII lowercase l) means values are transmitted least
significant byte first. Except where explicitly noted in the protocol, all
16-bit and 32-bit quantities sent by the client must be transmitted with this
byte order, and all 16-bit and 32-bit quantities returned by the server will
be transmitted with this byte order.
Following the byte-order byte, the following information is sent by the client
at connection setup:
protocol-major-version: CARD16
protocol-minor-version: CARD16
authorization-protocol-name: STRING8
authorization-protocol-data: STRING8
The version numbers indicate what version of the protocol the client
expects the server to implement. See below for an explanation.
The authorization name indicates what authorization protocol the client
expects the server to use, and the data is specific to that protocol.
Specification of valid authorization mechanisms is not part of the core
X protocol. It is hoped that eventually one authorization protocol
will be agreed upon. In the mean time, a server that implements a
different protocol than the client expects, or a server that only
implements the host-based mechanism, will simply ignore this
information.
Received by the client at connection setup:
success: BOOL
protocol-major-version: CARD16
protocol-minor-version: CARD16
length: CARD16
Length is the amount of additional data to follow, in units of 4 bytes.
The version numbers are an escape hatch in case future revisions of the
protocol are necessary. In general, the major version would increment
for incompatible changes, and the minor version would increment for
small upward compatible changes. Barring changes, the major version
will be eleven, and the minor version will be zero. The protocol
version numbers returned indicate the protocol the server actually
supports. This might not equal the version sent by the client. The
server can (but need not) refuse connections from clients that offer a
different version than the server supports. A server can (but need
not) support more than one version simultaneously.
Additional data received if authorization fails:
reason: STRING8
Additional data received if authorization is accepted:
vendor: STRING8
release-number: CARD32
resource-id-base, resource-id-mask: CARD32
image-byte-order: {LSBFirst, MSBFirst}
bitmap-format-scanline-unit: {8, 16, 32}
bitmap-format-scanline-pad: {8, 16, 32}
bitmap-format-bit-order: {LeastSignificant, MostSignificant}
pixmap-formats: LISTofFORMAT
roots: LISTofSCREEN
keyboard: DEVICE
pointer: DEVICE
motion-buffer-size: CARD32
maximum-request-length: CARD16
where
FORMAT: [depth: CARD8,
bits-per-pixel: {4, 8, 16, 24, 32}
scanline-pad: {8, 16, 32}]
SCREEN: [root: WINDOW
device: DEVICE
width-in-pixels, height-in-pixels: CARD16
width-in-millimeters, height-in-millimeters: CARD16
allowed-depths: LISTofDEPTH
root-depth: CARD8
root-visual: VISUALID
default-colormap: COLORMAP
white-pixel, black-pixel: CARD32
min-installed-maps, max-installed-maps: CARD16
backing-stores: {Never, WhenMapped, Always}
save-unders: BOOL
current-input-masks: SETofEVENT]
DEPTH: [depth: CARD8
visuals: LISTofVISUALTYPE]
VISUALTYPE: [visual-id: VISUALID
class: {StaticGray, StaticColor, TrueColor,
GrayScale, PseudoColor, DirectColor}
red-mask, green-mask, blue-mask: CARD32
bits-per-rgb-value: CARD8
colormap-entries: CARD16]
Per server information:
The vendor string gives some indentification of the owner of the server
implementation. The semantics of the release-number is controlled by
the vendor.
The resource-id-mask contains a single contiguous set of bits (at least
18); the client allocates resource ids by choosing a value with (only)
some subset of these bits set, and ORing it with resource-id-base.
Only values constructed in this way can be used to name newly created
resources over this connection. Resource ids never have the top 3 bits
set. The client is not restricted to linear or contiguous allocation
of resource ids. Once an id has been freed, it can be reused, but this
should not be necessary. An id must be unique with respect to the ids
of all other resources, not just other resources of the same type.
Although the server is in general responsible for byte swapping data to
match the client, images are always transmitted and received in formats
(including byte order) specified by the server. The byte order for
images is given by image-byte-order, and applies to each scanline unit
in XYFormat (bitmap) format, and to each pixel value in ZFormat.
A bitmap is represented in scanline order. Each scanline is padded to
a multiple of bits as given by bitmap-format-scanline-pad. The pad
bits are of arbitrary value. The scanline is quantized in multiples of
bits as given by bitmap-format-scanline-unit. Within each unit, the
leftmost bit in the bitmap is either the least or most significant bit
in the unit, as given by bitmap-format-bit-order. If a pixmap is
represented in XYFormat, each plane is represented as a bitmap, and the
planes appear from most to least significant in bit order.
For each pixmap depth supported by some screen, pixmap-formats lists
the ZFormat used to represent images of that depth. In ZFormat, the
pixels are in scanline order, left to right within a scanline. The
number of bits used to hold each pixel is given by bits-per-pixel, and
may be larger than strictly required by the depth. When the
bits-per-pixel is 4, the order of nibbles in the byte is the same as
the image byte-order. Each scanline is padded to a multiple of bits as
given by scanline-pad.
How a pointing device roams the screens is up to the server
implementation, and is transparent to the protocol. No geometry among
screens is defined.
The server may retain the recent history of pointer motion, and to a
finer granularity than is reported by MotionNotify events. Such
history is available via the GetPointerMotions request. The
approximate size of the history buffer is given by motion-buffer-size.
Maximum-request-length specifies the maximum length of a request, in
4-byte units, accepted by the server; i.e., this is the maximum value
that can appear in the length field of a request. Requests larger than
this generate a Length error, and the server will read and simply
discard the entire request. Maximum-request-length will always be at
least 4096 (i.e., requests of length up to and including 16384 bytes
will be accepted by all servers).
Per screen information:
The allowed-depths specifies what pixmap and window depths are
supported. Pixmaps are supported for each depth listed, and windows of
that depth are supported if at least one visual type is listed for the
depth. A pixmap depth of one is always supported and listed, but
windows of depth one might not be supported. A depth of zero is never
listed, but zero-depth InputOnly windows are always supported.
Root-depth and root-visual specify the depth and visual type of the
root window. Width-in-pixels and height-in-pixels specify the size of
the root window (which cannot be changed). The class of the root
window is always InputOutput. Width-in-millimeters and
height-in-millimeters can be used to determine the physical size and
the aspect ratio.
The default-colormap is the one initially associated with the root
window. Clients with minimal color requirements creating windows of
the same depth as the root may want to allocate from this map by
default.
Black-pixel and white-pixel can be used in implementing a "monochrome"
application. These pixel values are for permanently allocated entries
in the default-colormap; the actual RGB values may be settable on some
screens.
The border of the root window is initially a pixmap filled with the
black-pixel. The initial background of the root window is a pixmap
filled with some unspecified two-color pattern using black-pixel and
white-pixel.
Min-installed-maps specifies the number of maps that can be guaranteed
to installed simultaneously (with InstallColormap), regardless of the
number of entries allocated in each map. Max-installed-maps specifies
the maximum number of maps that might possibly be installed
simultaneously, depending on their allocations. For the typical case
of a single hardware colormap, both values will be one.
Backing-stores indicates when the server supports backing stores for
this screen, although it may be storage limited in the number of
windows it can support at once. If save-unders is True, then the
server can support the save-under mode in CreateWindow and
ChangeWindowAttributes, although again it may be storage limited.
The current-input-events is what GetWindowAttributes would return for
the all-event-masks for the root window.
Per visual-type information:
A given visual type might be listed for more than one depth, or for
more than one screen.
For PseudoColor, a pixel value indexes a colormap to produce
independent RGB values; the RGB values can be changed dynamically.
GrayScale is treated the same as PseudoColor, except which primary
drives the screen is undefined, so the client should always store the
same value for red, green, and blue in colormaps. For DirectColor, a
pixel value is decomposed into separate RGB subfields, and each
subfield separately indexes the colormap for the corresponding value;
The RGB values can be changed dynamically. TrueColor is treated the
same as DirectColor, except the colormap has predefined read-only RGB
values, which are server-dependent, but provide (near-)linear ramps in
each primary. StaticColor is treated the same as PseudoColor, except
the colormap has predefined read-only RGB values, which are
server-dependent. StaticGray is treated the same as StaticColor,
except the red, green, and blue values are equal for any single pixel
value, resulting in shades of gray. StaticGray with a two-entry
colormap can be thought of as "monochrome".
The red-mask, green-mask, and blue-mask are only defined for
DirectColor and TrueColor; each has one contiguous set of bits, with no
intersections.
The bits-per-rgb-value specifies the log base 2 of the approximate
number of distinct color values (individually) of red, green, and blue.
Actual RGB values are always passed in the protocol within a 16-bit
spectrum.
The colormap-entries defines the number of available colormap entries
in a newly created colormap. For DirectColor and TrueColor, this will
usually be the size of an individual pixel subfield.
SECTION 10. REQUESTS
CreateWindow
wid, parent: WINDOW
class: {InputOutput, InputOnly, CopyFromParent}
depth: CARD8
visual: VISUALID or CopyFromParent
x, y: INT16
width, height, border-width: CARD16
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Window, Pixmap, Colormap, Cursor, Match, Value, Alloc
Creates an unmapped window, and assigns the identifier wid to it.
A class of CopyFromParent means the class is taken from the parent. A
depth of zero for class InputOutput or CopyFromParent means the depth
is taken from the parent. A visual of CopyFromParent means the visual
type is taken from the parent. For class InputOutput, the visual type
and depth must be a combination supported for the screen (else a Match
error); the depth need not be the same as the parent, but the parent
must not be of class InputOnly (else a Match error). For class
InputOnly, the depth must be zero (else a Match error), and the visual
must be one supported for the screen (else a Match error), but the
parent may have any depth and class.
The server essentially acts as if InputOnly windows do not exist for
the purposes of graphics requests, exposure processing, and
VisibilityNotify events. An InputOnly window cannot be used as a
drawable (as a source or destination for graphics requests). InputOnly
and InputOutput windows act identically in other respects (properties,
grabs, input control, and so on).
The window is placed on top in the stacking order with respect to
siblings. The x and y coordinates are relative to the parent's origin,
and specify the position of the upper left outer corner of the window
(not the origin). The width and height specify the inside size, not
including the border, and must be non-zero. The border-width for an
InputOnly window must be zero (else a Match error).
The value-mask and value-list specify attributes of the window that are
to be explicitly initialized. The possible values are:
background-pixmap: PIXMAP or None or ParentRelative
background-pixel: CARD32
border-pixmap: PIXMAP or CopyFromParent
border-pixel: CARD32
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
colormap: COLORMAP or CopyFromParent
cursor: CURSOR or None
The default values, when attributes are not explicitly initialized,
are:
background-pixmap: None
border-pixmap: CopyFromParent
bit-gravity: Forget
win-gravity: NorthWest
backing-store: NotUseful
backing-bit-planes: all ones
backing-pixel: zero
save-under: False
event-mask: {} (empty set)
do-not-propagate-mask: {} (empty set)
override-redirect: False
colormap: CopyFromParent
cursor: None
Only the following attributes are defined for InputOnly windows:
win-gravity, event-mask, do-not-propagate-mask, and cursor. It is a
Match error to specify any other attributes for InputOnly windows.
If background-pixmap is given, it overrides the default
background-pixel. The background pixmap and the window must have the
same root and the same depth (else a Match error). Any size pixmap can
be used, although some sizes may be faster than others. If background
None is specifed, the window has no defined background. If background
ParentRelative is specified, the parent's background is used, but the
window must have the same depth as the parent (else a Match error); if
the parent has background None, then the window will also have
background None. A copy of the parent's background is not made; the
parent's background is reexamined each time the window background is
required. If background-pixel is given, it overrides the default and
any background-pixmap given, and a pixmap of undefined size filled with
background-pixel is used for the background. For a ParentRelative
background, the background tile origin always aligns with the parent's
background tile origin; otherwise the background tile origin is always
the window origin.
When regions of the window are exposed and the server has not retained
the contents, the server automatically tiles the regions with the
window's background unless the window has a background of None, in
which case the previous screen contents are simply left in place.
Exposure events are then generated for the regions, even if the
background is None.
The border tile origin is always the same as the background tile
origin. If border-pixmap is given, it overrides the default
border-pixel. The border pixmap and the window must have the same root
and the same depth (else a Match error). Any size pixmap can be used,
although some sizes may faster than others. If CopyFromParent is
given, the parent's border pixmap is copied (subsequent changes to the
parent do not affect the child), but the window must have the same
depth as the parent (else a Match error). If border-pixel is given, it
overrides the default and any border-pixmap given, and a pixmap of
undefined size filled with border-pixel is used for the border.
Output to a window is always clipped to the inside of the window, so
that the border is never affected.
The bit-gravity defines which region of the window should be retained
if the window is resized, and win-gravity defines how the window should
be repositioned if the parent is resized; see ConfigureWindow.
A backing-store of WhenMapped advises the server that maintaining
contents of obscured regions when the window is mapped would be
beneficial. A backing-store of Always advises the server that
maintaining contents even when the window is unmapped would be
beneficial. Note that, even if the window is larger than its parent,
the server should maintain complete contents, not just the region
within the parent boundaries. If the server maintains contents,
Exposure events will not be generated, but the server may stop
maintaining contents at any time. A value of NotUseful advises the
server that maintaining contents is unnecessary, although a server may
still choose to maintain contents.
Backing-bit-planes indicates (with one bits) which bit planes of the
window hold dynamic data that must be preserved in backing-stores.
Backing-pixel specifies what value to use in planes not covered by
backing-bit-planes. The server is free to only save the specified bit
planes in the backing-store, and regenerate the remaining planes with
the specified pixel value.
If save-under is True, the server is advised that, when this window is
mapped, saving the contents of windows it obscures would be beneficial.
The event-mask defines which events the client is interested in for
this window (or, for some event types, inferiors of the window). The
do-not-propagate-mask defines which events should not be propagated to
ancestor windows when no client has the event type selected in this
window.
Override-redirect specifies whether map and configure requests on this
window should override a SubstructureRedirect on the parent, typically
to inform a window manager not to tamper with the window.
The colormap specifies the colormap, that best reflects the "true"
colors of the window. Servers capable of supporting multiple hardware
colormaps may use this information, and window managers may use it for
InstallColormap requests. The colormap must have the same visual type
as the window (else a Match error). If CopyFromParent is specified,
the parent's colormap is copied (subsequent changes to the parent do
not affect the child), but the window must have the same visual type as
the parent (else a Match error) and the parent must not have a colormap
of None (else a Match error).
If a cursor is specified, it will be used whenever the pointer is in
the window. If None is specified, the parent's cursor will be used
when the pointer is in the window, and any change in the parent's
cursor will cause an immediate change in the displayed cursor.
This request generates a CreateNotify event.
The background and border pixmaps and the cursor may be freed
immediately if no further explicit references to them are to be made.
Subsequent drawing into the background or border pixmap has an
undefined effect on the window state; the server might or might not
make a copy of the pixmap.
ChangeWindowAttributes
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Pixmap, Colormap, Cursor, Match, Value, Access
The value-mask and value-list specify which attributes are to be
changed. The values and restrictions are the same as for CreateWindow.
Changing the background does not cause the window contents to be
changed. Setting the border, or changing the background such that the
border tile origin changes, causes the border to be repainted.
Changing the background of a root window to None or ParentRelative
restores the default background pixmap. Changing the border of a root
window to CopyFromParent restores the default border pixmap.
Changing the win-gravity does not affect the current position of the
window.
Changing the backing-store of an obscured window to WhenMapped or
Always, or changing the backing-bit-planes, backing-pixel, or
save-under of a mapped window, may have no immediate effect.
Multiple clients can select input on the same window; their event-masks
are disjoint. When an event is generated it will be reported to all
interested clients. However, at most one client at a time can select
for SubstructureRedirect, at most one client at a time can select for
ResizeRedirect, and at most one client at a time can select for
ButtonPress.
There is only one do-not-propagate-mask for a window, not one per
client.
Changing the colormap of a window (i.e., defining a new map, not
changing the contents of the existing map) generates a ColormapNotify
event. Changing the colormap of a visible window may have no immediate
effect on the screen; see InstallColormap.
Changing the cursor of a root window to None restores the default
cursor.
The order in which attributes are verified and altered is server
dependent. If an error is generated, a subset of the attributes may
have been altered.
GetWindowAttributes
window: WINDOW
=>
visual: VISUALID
class: {InputOutput, InputOnly}
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
colormap: COLORMAP or None
map-is-installed: BOOL
map-state: {Unmapped, Unviewable, Viewable}
all-event-masks, your-event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
Errors: Window
Returns current attributes of the window. All-event-masks is the
inclusive-OR of all event masks selected on the window by clients.
Your-event-mask is the event mask selected by the querying client.
DestroyWindow
window: WINDOW
Errors: Window
If the argument window is mapped, an UnmapWindow request is performed
automatically. The window and all inferiors are then destroyed, and a
DestroyNotify event is generated for each window, in order from the
argument window downwards, with unspecified order among siblings at
each level.
Normal exposure processing on formerly obscured windows is performed.
If the window is a root window, this request has no effect.
DestroySubwindows
window: WINDOW
Errors: Window
Performs a DestroyWindow on all children of the window, in bottom to
top stacking order.
ChangeSaveSet
window: WINDOW
mode: {Insert, Delete}
Errors: Window, Match, Value
Adds or removes the specified window from the client's "save-set". The
window must have been created by some other client (else a Match
error). The use of the save-set is described in Section 11.
Windows are removed automatically from the save-set by the server when
they are destroyed.
ReparentWindow
window, parent: WINDOW
x, y: INT16
Errors: Window, Match
If the window is mapped, an UnmapWindow request is performed
automatically first. The window is then removed from its current
position in the hierarchy, and is inserted as a child of the specified
parent. The x and y coordinates are relative to the parent's origin,
and specify the new position of the upper left outer corner of the
window. The window is placed on top in the stacking order with respect
to siblings. A ReparentNotify event is then generated. The
override-redirect attribute of the window is passed on in this event; a
value of True indicates that a window manager should not tamper with
this window. Finally, if the window was originally mapped, a MapWindow
request is performed automatically.
Normal exposure processing on formerly obscured windows is performed.
The server might not generate exposure events for regions from the
initial unmap that are immediately obscured by the final map.
A Match error is generated if the new parent is not on the same screen
as the old parent, or if the new parent is the window itself or an
inferior of the window, or if the window has a ParentRelative
background and the new parent is not the same depth as the window.
MapWindow
window: WINDOW
Errors: Window
If the window is already mapped, this request has no effect.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
MapRequest event is generated, but the window remains unmapped.
Otherwise, the window is mapped and a MapNotify event is generated.
If the window is now viewable and its contents had been discarded, then
the window is tiled with its background (if no background is defined,
the existing screen contents are not altered) and one or more exposure
events are generated. If a backing-store has been maintained while the
window was unmapped, no exposure events are generated. If a
backing-store will now be maintained, a full-window exposure is always
generated; otherwise only visible regions may be reported. Similar
tiling and exposure take place for any newly viewable inferiors.
MapSubwindows
window: WINDOW
Errors: Window
Performs a MapWindow request on all unmapped children of the window, in
top to bottom stacking order.
UnmapWindow
window: WINDOW
Errors: Window
If the window is already unmapped, this request has no effect.
Otherwise, the window is unmapped and an UnmapNotify event is
generated. Normal exposure processing on formerly obscured windows is
performed.
UnmapSubwindows
window: WINDOW
Errors: Window
Performs an UnmapWindow request on all mapped children of the window,
in bottom to top stacking order.
ConfigureWindow
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Match, Value
Changes the configuration of the window. The value-mask and value-list
specify which values are to be given. The possible values are:
x: INT16
y: INT16
width: CARD16
height: CARD16
border-width: CARD16
sibling: WINDOW
stack-mode: {Above, Below, TopIf, BottomIf, Opposite}
The x and y coordinates are relative to the parent's origin, and
specify the position of the upper left outer corner of the window. The
width and height specify the inside size, not including the border, and
must be non-zero. It is a Match error to attempt to make the
border-width of an InputOnly window non-zero.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
ConfigureRequest event is generated, and no further processing is
performed. Otherwise, the following is performed.
If some other client has selected ResizeRedirect on the window and the
width or height of the window is being changed, then a ResizeRequest
event is generated, and the current width and height are used instead
in the following.
The geometry of the window is changed as specified and the window is
restacked among siblings as described below, and a ConfigureNotify
event is generated. If the width or height of the window has actually
changed, then children of the window are affected as described below.
Exposure processing is performed on formerly obscured windows.
Changing the width or height of the window causes its contents to be
moved or lost, depending on the bit-gravity of the window, and causes
children to be reconfigured, depending on their win-gravity. For a
change of width and height of W and H, we define the [x, y] pairs:
NorthWest: [0, 0]
North: [W/2, 0]
NorthEast: [W, 0]
West: [0, H/2]
Center: [W/2, H/2]
East: [W, H/2]
SouthWest: [0, H]
South: [W/2, H]
SouthEast: [W, H]
When a window with one of these bit-gravities is resized, the
corresponding pair defines the change in position of each pixel in the
window. When a window with one of these win-gravities has its parent
window resized, the corresponding pair defines the change in position
of the window within the parent. When a window is so repositioned, a
GravityNotify event is generated.
A gravity of Static indicates that the contents or origin should not
move relative to the origin of the root window. If the change in size
of the window is coupled with a change in position of [X, Y], then for
bit-gravity the change in position of each pixel is [-X, -Y], and for
win-gravity the change in position of a child when its parent is so
resized is [-X, -Y]. Note that Static gravity still only takes effect
when the width or height of the window is changed, not when the window
is simply moved.
A bit-gravity of Forget indicates that the window contents are always
discarded after a size change; the window is tiled with its background
(if no background is defined, the existing screen contents are not
altered) and one or more exposure events are generated. A server may
also ignore the specified bit-gravity and use Forget instead.
A win-gravity of Unmap is like NorthWest, but the child is also
unmapped when the parent is resized, and an UnmapNotify event is
generated.
If a sibling and a stack-mode is specified, the window is restacked as
follows:
Above: window is placed just above sibling
Below: window is placed just below sibling
TopIf: if sibling occludes window, then window is placed
at the top of the stack
BottomIf: if window occludes sibling, then window is
placed at the bottom of the stack
Opposite: if sibling occludes window, then window is placed at the
top of the stack, else if window occludes sibling, then
window is placed at the bottom of the stack
If a stack-mode is specified but no sibling is specified, the window is
restacked as follows:
Above: window is placed at the top of the stack
Below: window is placed at the bottom of the stack
TopIf: if any sibling occludes window, then window is placed at
the top of the stack
BottomIf: if window occludes any sibling, then window is placed at
the bottom of the stack
Opposite: if any sibling occludes window, then window is placed at
the top of the stack, else if window occludes any
sibling, then window is placed at the bottom of the stack
It is a Match error if a sibling is specified without a stack-mode, or
if the window is not actually a sibling.
Note that the computations for BottomIf, TopIf, and Opposite are
performed with respect to the window's final geometry (as controlled by
the other arguments to the request), not its initial geometry.
CirculateWindow
window: WINDOW
direction: {RaiseLowest, LowerHighest}
Errors: Window, Value
If some other client has selected SubstructureRedirect on the window,
then a CirculateRequest event is generated, and no further processing
is performed. Otherwise, the following is performed, and then a
CirculateNotify event is generated if the window is actually restacked.
For RaiseLowest, raises the lowest mapped child (if any) that is
occluded by another child to the top of the stack. For LowerHighest,
lowers the highest mapped child (if any) that occludes another child to
the bottom of the stack. Exposure processing is performed on formerly
obscured windows.
∂01-Jun-87 0531 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 6 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:31:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 6 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082914.1.RWS@KILLINGTON.LCS.MIT.EDU>
SetPointerMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the pointer. Elements of the list are indexed
starting from one. The length of the list must be the same as
GetPointerMapping would return. The index is a "core" button number,
and the element of the list defines the "effective" number.
A zero element disables a button, and elements are not restricted in
value by the number of physical buttons, but no two elements can have
the same non-zero value.
If any of the buttons to be altered are currently in the down state,
the status reply is Busy and the mapping is not changed.
GetPointerMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the pointer. Elements of the list are
indexed starting from one. The length of the list indicates the number
of physical buttons.
The nominal mapping for a pointer is the identity mapping; map[i]=i.
ChangePointerControl
do-acceleration, do-threshold: BOOL
acceleration-numerator, acceleration-denominator: INT16
threshold: INT16
Errors: Match, Value
Defines how the pointer moves. The acceleration is a multiplier for
movement, expressed as a fraction. For example, specifying 3/1 means
the pointer moves three times as fast as normal. The fraction may be
rounded arbitrarily by the server. Acceleration only takes effect if
the pointer moves more than threshold pixels at once, and only applies
to the amount beyond the threshold. Setting a value to -1 restores the
default. Other negative values generate a Value error, as does a zero
value for acceleration-denominator.
GetPointerControl
=>
acceleration-numerator, acceleration-denominator: CARD16
threshold: CARD16
Errors: Match
Returns the current acceleration and threshold for the pointer.
SetScreenSaver
timeout, interval: INT16
prefer-blanking: {Yes, No, Default}
allow-exposures: {Yes, No, Default}
Errors: Value
Timeout and interval are specified in minutes; setting a value to -1
restores the default. Other negative values generate a Value error.
If the timeout value is zero, screen-saver is disabled. If the timeout
value is non-zero, screen-saver is enabled. Once screen-saver is
enabled, if no input from the keyboard or pointer is generated for
timeout minutes, screen-saver is activated. For each screen, if
blanking is preferred and the hardware supports video blanking, the
screen will simply go blank. Otherwise, if either exposures are
allowed or the screen can be regenerated without sending exposure
events to clients, the screen is tiled with the root window background
tile, randomly re-origined each interval minutes if the interval value
is non-zero. Otherwise, the state of the screen does not change and
screen-saver is not activated. Screen-saver is deactivated, and all
screen states are restored, at the next keyboard or pointer input or at
the next ForceScreenSaver with mode Reset.
GetScreenSaver
=>
timeout, interval: CARD16
prefer-blanking: {Yes, No}
allow-exposures: {Yes, No}
Returns the current screen-saver control values.
ForceScreenSaver
mode: {Activate, Reset}
If the mode is Activate and screen-saver is currently deactivated, then
screen-saver is activated (even if screen-saver has been disabled with
a timeout value of zero). If the mode is Reset and screen-saver is
currently enabled, then screen-saver is deactivated (if it was
activated), and then the activation timer is reset to its initial
state, as if device input had just been received.
ChangeHosts
mode: {Insert, Delete}
host: HOST
Errors: Access, Value
Adds or removes the specified host from the access control list. When
the access control mechanism is enabled and a host attempts to
establish a connection to the server, the host must be in this list or
the server will refuse the connection.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
An initial access control list can be specified, typically by naming a
file that the server reads at startup and reset.
ListHosts
=>
mode: {Enabled, Disabled}
hosts: LISTofHOST
Returns the hosts on the access control list, and whether use of the
list at connection setup is currently enabled or disabled.
Each HOST is padded to a multiple of four bytes.
ChangeAccessControl
mode: {Enable, Disable}
Errors: Value, Access
Enables or disables the use of the access control list at connection
setups.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
ChangeCloseDownMode
mode: {Destroy, RetainPermanent, RetainTemporary}
Errors: Value
Defines what will happen to the client's resources at connection close.
A connection starts in Destroy mode. The meaning of the close-down
mode is described in Section 11.
KillClient
resource: CARD32 or AllTemporary
Errors: Value
If a valid resource is specified, forces a close-down of the client
that created the resource. If the client has already terminated in
either RetainPermanent or RetainTemporary mode, all of the client's
resources are destroyed (see Section 11). If AllTemporary is
specified, then the resources of all clients that have terminated in
RetainTemporary are destroyed.
NoOperation
This request has no arguments and no results, but the request length
field can be non-zero, allowing the request to be any multiple of 4
bytes in length. The bytes contained in the request are uninterpreted
by the server.
This request can be used in its minimum 4 byte form as "padding" where
necessary by client libraries that find it convenient to force requests
to begin on 64-bit boundaries.
SECTION 11. CONNECTION CLOSE
What happens at connection close:
All event selections made by the client are discarded. If the client
has the pointer actively grabbed, an UngrabPointer is performed. If
the client has the keyboard actively grabbed, an UngrabKeyboard is
performed. All passive grabs by the client are released. If the
client has the server grabbed, and UngrabServer is performed. If
close-down mode (see ChangeCloseDownMode) is RetainPermanent or
RetainTemporary, then all resources (including colormap entries)
allocated by the client are marked as "permanent" or "temporary",
respectively (but this does not prevent other clients from explicitly
destroying them). If the mode is Destroy, then all of the client's
resources are destroyed as described below.
What happens when a client's resources are destroyed:
For each window in the client's save-set, if the window is an inferior
of a window created by the client, the save-set window is reparented to
the closest ancestor such that the save-set window is not an inferior
of a window created by the client. If the save-set window is unmapped,
a MapWindow request is performed on it. After save-set processing, all
windows created by the client are destroyed. For each non-window
resource created by the client, the appropriate Free request is
performed. All colors and colormap entries allocated by the client are
freed.
What happens when the last connection to a server closes:
A server goes through a cycle, of having no connections and having some
connections. At every transition to the state of having no
connections, the server "resets" its state, as if it had just been
started. This starts by destroying all lingering resources from
clients that have terminated in RetainPermanent or RetainTemporary
mode. It additionally includes deleting all but the predefined atom
identifiers, deleting all properties on all root windows, resetting all
device maps and attributes (key click, bell volume, acceleration),
resetting the access control list, restoring the standard root tiles
and cursors, restoring the default font path, and restoring the input
focus to state PointerRoot.
SECTION 12. EVENTS
When a button is pressed with the pointer in some window W, and no active
pointer grab is in progress, then the ancestors of W are searched from the
root down, looking for a passive grab to activate. If no matching passive
grab on the button exists, then an active grab is started automatically for
the client receiving the event, and the last-pointer-grab time is set to the
current server time. The effect is essentially equivalent to a GrabButton
with arguments:
event-window: the event window
event-mask: the client's selected events on the event window
pointer-mode and keyboard-mode: Asynchronous
owner-events: True if the client has OwnerGrabButton selected on the
event window, else False
confine-to: None
cursor: None
The grab is terminated automatically when all buttons are released.
UngrabPointer and ChangeActiveGrab can both be used to modify the active grab.
KeyPress
and
KeyRelease
and
ButtonPress
and
ButtonRelease
and
MotionNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
detail: <see below>
state: SETofKEYBUTMASK
time: TIMESTAMP
Generated when a key or button changes state, or the pointer moves.
The "source" of the event is the window the pointer is in. The window
with respect to which the event is normally reported is found by
looking up the hierarchy (starting with the source window) for the
first window on which any client has selected interest in the event,
provided no intervening window prohibits event generation by including
the event type in its do-not-propagate-mask. The actual window used
for reporting can be modified by active grabs and the focus window.
The window the event is reported with respect to is called the "event"
window.
Root is the root window of the "source" window, and root-x and root-y
are the pointer coordinates relative to root's origin at the time of
the event. Event is the "event" window. If the event window is on the
same screen as root, then event-x and event-y are the pointer
coordinates relative to the event window's origin; otherwise event-x
and event-y are zero. If the source window is an inferior of the event
window, then child is set to the child of the event window that is an
ancestor of the source window. The state component gives the state of
the buttons and modifier keys just before the event. The detail
component varies with the event type:
KeyPress, KeyRelease: KEYCODE
ButtonPress, ButtonRelease: BUTTON
MotionNotify: {Normal, Hint}
MotionNotify events are only generated when the motion begins and ends
in the window. The granularity of motion events is not guaranteed, but
a client selecting for motion events is guaranteed to get at least one
event when the pointer moves and comes to rest. Selecting
PointerMotion receives events independent of the state of the pointer
buttons. By selecting some subset of Button[1-5]Motion instead,
MotionNotify events will only be received when one or more of the
specified buttons are pressed. By selecting ButtonMotion, MotionNotify
events will received only when at least one button is pressed. The
events are always of type MotionNotify, independent of the selection.
If PointerMotionHint is selected, the server is free to send only one
MotionNotify event (with detail Hint) to the client for the event
window, until either the key or button state changes, or the pointer
leaves the event window, or the client issues a QueryPointer or
GetMotionEvents request.
EnterNotify
and
LeaveNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
mode: {Normal, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual}
focus: BOOL
state: SETofKEYBUTMASK
time: TIMESTAMP
If pointer motion causes the pointer to be in a different window than
before, EnterNotify and LeaveNotify events are generated instead of a
MotionNotify event. Only clients selecting EnterWindow on a window
receive EnterNotify events, and only clients selection LeaveNotify
receive LeaveNotify events. The pointer position reported in the event
is always the "final" position, not the "initial" position of the
pointer. In a LeaveNotify event, if a child of the event window
contains the "initial" position of the pointer, then the child
component is set to that child, otherwise it is None. For an
EnterNotify event, if a child of the event window contains the "final"
pointer position, then the child component is set to that child,
otherwise it is None. If the the event window is the focus window or
an inferior of the focus window, then focus is True, and otherwise
focus is False.
Normal pointer motion events have mode Normal; pseudo-motion events
when a grab actives have mode Grab, and pseudo-motion events when a
grab deactivates have mode Ungrab.
Normal events are generated as follows:
When the pointer moves from window A to window B, and A is an inferior
of B:
LeaveNotify with detail Ancestor is generated on A
LeaveNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Inferior is generated on B
When the pointer moves from window A to window B, and B is an inferior
of A:
LeaveNotify with detail Inferior is generated on A
EnterNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Ancestor is generated on B
When the pointer moves from window A to window B, with window C being
their least common ancestor:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
EnterNotify with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
EnterNotify with detail Nonlinear is generated on B
When the pointer moves from window A to window B, on different screens:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
EnterNotify with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
EnterNotify with detail Nonlinear is generated on B
When a pointer grab activates (but after any initial warp into a confine-to
window), with G the grab-window for the grab and P the window the pointer
is in:
EnterNotify and LeaveNotify events with mode Grab are generated (as for
Normal above) as if the pointer were to suddenly warp from its current
position in P to some position in G. However, the pointer does not
warp, and the pointer position is used as both the "initial" and
"final" positions for the events.
When a pointer grab deactivates, with G the grab-window for the grab and P
the window the pointer is in:
EnterNotify and LeaveNotify events with mode Ungrab are generated (as
for Normal above) as if the pointer were to suddenly warp from from
some position in G to its current position in P. However, the pointer
does not warp, and the current pointer position is used as both the
"initial" and "final" positions for the events.
FocusIn
and
FocusOut
event: WINDOW
mode: {Normal, WhileGrabbed, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual,
Pointer, PointerRoot, None}
Generated when the input focus changes. Reported to clients selecting
FocusChange on the window. Events generated by SetInputFocus when the
keyboard is not grabbed have mode Normal; events generated by
SetInputFocus when the keyboard is grabbed have mode WhileGrabbed;
events generated when a keyboard grab actives have mode Grab, and
events generated when a keyboard grab deactivates have mode Ungrab.
Normal and WhileGrabbed events are generated as follows:
When the focus moves from window A to window B, and A is an inferior of B,
with the pointer in window P:
FocusOut with detail Ancestor is generated on A
FocusOut with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Inferior is generated on B
If P is an inferior of B, but P is not A or an inferior of A or an
ancestor of A, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, and B is an inferior of A,
with the pointer in window P:
If P is an inferior of A, but P is not A or an inferior of B or an
ancestor of B, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Inferior is generated on A
FocusIn with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Ancestor is generated on B
When the focus moves from window A to window B, with window C being their
least common ancestor, and with the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
FocusIn with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, on different screens, with
the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to PointerRoot (or None)
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail PointerRoot (or None) is generated on all root
windows
When the focus moves from PointerRoot (or None) to window A:
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail NonlinearVirtual is generated on each window from
A's root down to but not including A (in order)
FocusIn with detail Nonlinear is generated on A
If P is an inferior of A, FocusIn with detail Pointer is generated on
each window below A down to and including P (in order)
When the focus moves from PointerRoot to None (or vice versa):
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail None (or PointerRoot) is generated on all root
windows
When a keyboard grab activates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Grab are generated (as for Normal
above) as if the focus were to change from F to G
When a keyboard grab deactivates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Ungrab are generated (as for
Normal above) as if the focus were to change from G to F
KeymapNotify
keys: LISTofCARD8
The value is a bit vector, as described in QueryKeymap. Reported to
clients selecting KeymapState on a window. Generated immediately after
every EnterNotify and FocusIn.
Expose
window: WINDOW
x, y, width, height: CARD16
last-in-series: BOOL
Reported to clients selecting Exposure on the window. Possibly
generated when a region of the window becomes viewable, but might only
be generated when a region becomes visible. All of the regions exposed
by a given "action" are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
Expose events are never generated on InputOnly windows.
GraphicsExposure
drawable: DRAWABLE
x, y, width, height: CARD16
last-in-series: BOOL
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a destination region could not be computed due to an
obscured or out-of-bounds source region. All of the regions exposed by
a given graphics request are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
NoExposure
drawable: DRAWABLE
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a graphics request that might produce GraphicsExposure
events does not produce any. The drawable specifies the destination
used for the graphics request.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
VisibilityNotify
window: WINDOW
state: {Unobscured, PartiallyObscured, FullyObscured}
Reported to clients selecting VisibilityChange on the window. In the
following, the state of the window is calculated ignoring all of the
window's subwindows. When a window changes state from partially or
fully obscured or not viewable to viewable and completely unobscured,
an event with Unobscured is generated. When a window changes state
from a) viewable and completely unobscured or b) not viewable, to
viewable and partially obscured, an event with PartiallyObscured is
generated. When a window changes state from a) viewable and completely
unobscured or b) viewable and partially obscured or c) not viewable, to
viewable and fully obscured, an event with FullyObscured is generated.
VisibilityNotify events are never generated on InputOnly windows.
CreateNotify
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on the parent.
Generated when the window is created. The arguments are as in the
CreateWindow request.
DestroyNotify
event, window: WINDOW
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is destroyed. "Event" is the window on which the event was
generated, and "window" is the window that is destroyed.
UnmapNotify
event, window: WINDOW
from-configure: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from mapped to unmapped. "Event" is the window on
which the event was generated, and "window" is the window that is
unmapped. The from-configure flag is True if the event was generated
as a result of the window's parent being resized when the window itself
had a win-gravity of Unmap.
MapNotify
event, window: WINDOW
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from unmapped to mapped. "Event" is the window on
which the event was generated, and "window" is the window that is
mapped. The override-redirect flag is from the window's attribute.
MapRequest
parent, window: WINDOW
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a MapWindow request is issued on an unmapped window with
an override-redirect attribute of False.
ReparentNotify
event, window, parent: WINDOW
x, y: INT16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on either the old or
the new parent, and to clients selecting StructureNotify on the window.
Generated when the window is reparented. "Event" is the window on
which the event was generated, "window" is the window that has been
re-rooted, and "parent" specifies the new parent. The x and y
coordinates are relative to the new parent's origin, and specify the
position of the upper left outer corner of the window. The
override-redirect flag is from the window's attribute.
ConfigureNotify
event, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when a
ConfigureWindow request actually changes the state of the window.
"Event" is the window on which the event was generated, and "window" is
the window that is changed. If above-sibling is None, then the window
is on the bottom of the stack with respect to siblings; otherwise, the
window is immediately on top of the specified sibling. The
override-redirect flag is from the window's attribute.
GravityNotify
event, window: WINDOW
x, y: INT16
Reported to clients selecting SubstructureNotify on the parent, and to
clients selecting StructureNotify on the window. Generated when a
window is moved because of a change in size of the parent. "Event" is
the window on which the event was generated, and "window" is the window
that is moved.
ResizeRequest
window: WINDOW
width, height: CARD16
Reported to the client selecting ResizeRedirect on the window.
Generated when a ConfigureWindow request by some other client on the
window attempts to change the size of the window. The width and height
are the inside size, not including the border.
ConfigureRequest
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a ConfigureWindow request is issued on the window by
some other client. The geometry is as derived from the request. The
above-sibling is the sibling the window should be placed directly on
top of; if None, then the window should be placed on the bottom.
CirculateNotify
event, window: WINDOW
place: {Top, Bottom}
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is actually restacked from a CirculateWindow request. "Event"
is the window on which the event was generated, and "window" is the
window that is restacked. If place is Top, the window is now on top of
all siblings; otherwise it is below all siblings.
CirculateRequest
parent, window: WINDOW
place: {Top, Bottom}
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a CirculateWindow request is issued on the parent and a
window actually needs to be restacked. The window specifies the window
to be restacked, and place specifies what the new position in the
stacking order should be.
PropertyNotify
window: WINDOW
atom: ATOM
state: {NewValue, Deleted}
time: TIMESTAMP
Reported to clients selecting PropertyChange on the window. Generated
when a property of the window is changed. The timestamp indicates the
server time when the property was changed.
SelectionClear
owner: WINDOW
selection: ATOM
time: TIMESTAMP
Reported to the current owner of a selection. Generated on the window
losing ownership when a new owner is being defined. The timestamp is
the last-change time recorded for the selection.
SelectionRequest
owner: WINDOW
selection: ATOM
target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Reported to the owner of a selection. Generated when a client issues a
ConvertSelection request. The arguments are as in the request.
The owner should convert the selection based on the specified target
type. If a property is specified, the owner should store the result as
that property on the requestor window, and then send a SelectionNotify
event to the requestor using SendEvent. If the selection cannot be
converted as requested, the owner should send a SelectionNotify with
the property set to None.
SelectionNotify
requestor: WINDOW
selection, target: ATOM
property: ATOM or None
time: TIMESTAMP or CurrentTime
This event is only generated by clients using SendEvent. The owner of
a selection should send this event to a requestor when a selection has
been converted and stored as a property, or when a selection conversion
could not be performed (indicated with property None).
ColormapNotify
window: WINDOW
colormap: COLORMAP or None
new: BOOL
state: {Installed, Uninstalled}
Reported to clients selecting ColormapChange on the window. Generated
with value True for new when the colormap attribute of the window is
changed. Generated with value False for new when the colormap of a
window is installed or uninstalled. In either case, state indicates
whether the colormap is currently installed.
ClientMessage
window: WINDOW
type: ATOM
format: {8, 16, 32}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
This event is only generated by clients using SendEvent. The type
specifies how the data is to be interpreted by the receiving client;
the server places no interpretation on the type or the data. The
format specifies whether the data should be viewed as a list of 8-bit,
16-bit, or 32-bit quantities, so that the server can correctly
byte-swap as necessary. The data always consists of either 20 8-bit
values or 10 16-bit values or 5 32-bit values, although particular
message types might not make use of all of these values.
SECTION 12. FLOW CONTROL AND CONCURRENCY
Whenever the server is writing to a given connection, it is permissible for
the server to stop reading from that connection (but if the writing would
block it must continue to service other connections). The server is not
required to buffer more than a single request per connection at one time. For
a given connection to the server, a client can block while reading from the
connection, but should undertake to read (events and errors) when writing
would block. Failure on the part of a client to obey this rule could result
in a deadlocked connection, although deadlock is probably unlikely unless the
transport layer has very little buffering, or unless the client attempts to
send large numbers of requests without ever reading replies or checking for
errors and events.
If a server is implemented with internal concurrency, the overall effect must
be as if individual requests are executed to completion in some serial order,
and that requests from a given connection are executed in delivery order
(i.e., the total execution order is a shuffle of the individual streams). The
"execution" of a request includes validating all arguments, collecting all
data for any reply, and generating (and queueing) all required events, but
does not include the actual transmission of the reply and the events. In
addition, the effect of any other "cause" (e.g., activation of a grab, pointer
motion) that can generate multiple events must effectively generate (and
queue) all required events indivisibly with respect to all other causes and
requests.
∂11-Jun-87 1121 Masinter.pa@Xerox.COM Issues from the cleanup committee
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 11:20:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 11:15:28 PDT
Date: 11 Jun 87 11:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issues from the cleanup committee
To: X3J13@Sail.stanford.edu
Message-ID: <870611-111528-1358@Xerox>
The cleanup committee has been hard at work. We have produced a number
of issues for presentation at the next meeting. I will mail drafts of
the issues which seem ready to release to this list over the next
several days. I will then mail out a summary. A hardcopy of the issues
will also be mailed to the X3J13 mailing list.
Discussion is still on-going in cl-cleanup. There are a few proposals
that are in the last rounds of revisions which we will try finalize in
the next few days.
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue DEFVAR-INIT-TIME (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:34:46 PDT
Date: 11 Jun 87 13:33 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue DEFVAR-INIT-TIME (Version 2)
To: x3j13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-133446-1639@Xerox>
!
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
29-Mar-87, Version 2 by Masinter
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating the
form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
is not evaluated unless it is used; this fact is useful if evaluation of
the INITIAL-VALUE form does something expensive like create a large data
structure.''
At least one implementation interpreted the "unless it is used" to mean
"unless the variable is used" rather than "unless the initial-value is
to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
interpreted as a kind of lazy initialization that happened upon the
variable's first unbound reference. (This interpretation appears to have
been further supported by the additional wording in CLtL about not
creating expensive structures that are not needed.)
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all). The cause of the confusion
is the statement that the initial value form is not evaluated unless "it
is used". Better to say that INITIAL-VALUE is evaluated if and only if
the variable does not already have a value. Then there would be no
confusion about the time of evaluation.
Rationale:
This clarification follows the intent of the original Common Lisp
designers.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
None, for most implementations; very small for any the implementation
that adopted delayed evaluation.
Benefits:
This clarification makes the semantics of an important primitive more
well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:03:36 PDT
Date: 11 Jun 87 13:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Format for proposals to the cleanup committee (Version 11)
To: X3J13@Sail.stanford.edu
Line-fold: no
Message-ID: <870611-130336-1594@Xerox>
!
Format for proposals to the cleanup committee (Version 11)
June 11, 1987
Replace the text below in >> double inverted angle-brackets <<. Be brief; leave testimonials and personal opinions to the discussion at the end. Be complete; do not expect someone else to fix or redesign parts. Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp symbols (DEFUN rather than Defun). I like it better if you write in the third person rather than first.
Issue: >>A short descriptive label, which starts with a name which occurs in the index of CLtL, and be a suitable symbol in the Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being discussed, or other references.<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an ambiguity or case of under-specified situation in CLtL, where this ambiguity interferes with portability of code. CHANGE -- proposal for an incompatible change to the language. ADDITION -- proposal for a compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation unclear or unsatisfactory? Avoid describing the proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as possible what you are proposing. Ideally, this should take the form of text that could be dropped into CLtL or some new specification document. If necessary, propose a set of labelled alternatives here, rather than a single proposal. Each proposal must be a complete design; do not leave out details. Avoid arguing for the proposal here, just describe it.<<
Test Case:
>>When possible, give a sample of Common Lisp code that illustrates the issue. The code should stand alone, and preferably be suitable for incorporation in a diagnostic suite. <<
Rationale:
>> A brief argument for the proposal. (If more than one proposal is listed, discuss each issue separately here and in subsequent sections.)<<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way? Survey independent Common Lisp implementations - preferably three or more.<<
Adoption Cost:
>>What is the cost to implementors of adopting the proposal? How much implementation effort is required? Is public-domain code available? For pervasive changes, can the conversion be automated?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem if just left as it is? <<
Conversion Cost:
>>For incompatible changes, what is the cost to users of converting existing user code? To what extent can the process be automated? How?<<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of learning, etc.<<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc. should go here. A blow-by-blow account of debates is not necessary. <<
∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:15:10 PDT
Date: 11 Jun 87 13:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
To: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-cleanup@sail.stanford.edu
Message-ID: <870611-131510-1611@Xerox>
!
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 at committee meeting 15-Mar-87
Version 3 Masinter 15-Mar-87
Version 4 by Fahlman, incorporate Dribble
Version 5 by Masinter, 29-May-87, revert to Version 3
Version 6 by Masinter, 5-Jun-87, minor formatting
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.
The cleanup committee supports this change as stated.
∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue FORMAT-OP-C (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:07:51 PDT
Date: 11 Jun 87 14:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-OP-C (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <870611-140751-1716@Xerox>
!
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Versions 2,3 by Pitman
5-Jun-87, Version 4 by Masinter (copy-editing)
11-Jun-87, Version 5 release to X3J13
(remove confusing paragraph)
Problem Description:
CLtL is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should be
culturally compatible with the host environment." This description is
not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose:
some implementations have (FORMAT NIL "~C" #\Space) => "Space" rather
than " ".
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; currently, FORMAT does not suffice.
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. (This proposal
leaves the behavior of ~C with non-zero bits incompletely specified.)
For example, the description of the ~C format directive on p389 of CLTL
might read:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Test Case:
(EQUAL (FORMAT NIL "~C" #\Space) " ")
Rationale:
This was probably the intent of the Common Lisp designers.
It makes things clear enough that programmers can know what to expect in
the normal case (standard characters with zero bits).
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and ~:C
equivalently or very similarly.
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would require an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable. As things
stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of "~C"
and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as a
simplification.
Discussion:
The cleanup committee generally supports this clarification.
The original version of this proposal (which tried to make WRITE-CHAR
and ~C identical in all cases) prompted the following comment:
"I believe the error in CLtL is that it was not stated explicitly that
the `implementation-dependent abbreviated format' applies only to
characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as WRITE-CHAR for characters with
zero char-bits. I don't think we want to require ~C and write-char to
do the same thing for characters with bits."
∂11-Jun-87 1620 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:20:37 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 JUN 87 13:27:34 PDT
Date: 11 Jun 87 13:27 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-132734-1630@Xerox>
!
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/26/87
Version 2 by cleanup committee 15-Mar-87 14:45:18
Version 3 by Masinter (format) 15-Mar-87 18:34:28
Version 4 by Masinter 5-Jun-87
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to declare a variable without
initializing it. More importantly, though, DEFVAR is used by lots of
users in every implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious.
Discussion:
The cleanup committee generally supports this clarification.
[Version 3 was distributed at the last X3J13 meeting. This version has
changed only to bring it in line with the current proposal format.]
∂11-Jun-87 1619 Masinter.pa@Xerox.COM AREF-1D (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:07:01 PDT
Date: 11 Jun 87 13:06 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-130701-1603@Xerox>
In most of these proposals, some earlier version was circulated to the
committee and explicitly voted on. In cases where there have been
editorial changes after the ballot, the edited version has been
circulated, but not necessarily endorsed.
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.
ROW-MAJOR-AREF is valid for use with SETF.
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.
Benefits:
This gives users efficient access to something to which they already
have inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
The cleanup committee generally supports this enhancement. Version 2 was
endorsed (assuming change to function name ROW-MAJOR-AREF.)
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:43:40 PDT
Date: 11 Jun 87 13:40 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-ATSIGN-COLON (Version 3)
To: x3j13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <870611-134340-1658@Xerox>
This was distributed at the last X3J13 meeting. The only changes have
been to bring it into the current proposal format.
!
Issue: FORMAT-ATSIGN-COLON
References: FORMAT description (p386)
Category: CLARIFICATION
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Masinter 15-Mar-87
Version 4 by Masinter 5-Jun-87
Problem Description:
CLtL describes the format op syntax as:
"a format directive consists of a tilde (~), optional prefix parameters
separated by commas, optional colon (:) and atsign (@) modifiers, and a
single character indicating what kind of directive this is."
CLtL uses :@ fairly consistently throughout without saying whether @: is
legal. Is @: allowed?
Proposal (FORMAT-ATSIGN-COLON:OK):
There is no required ordering between the @ and : modifier.
Rationale:
This is currently underspecified, and this way of specifying it will
cause the least disruption to user code.
Current practice:
Most implementations accept these in either order. Some implementations
have been known to expect only :@.
Adoption Cost:
The change to accept either syntax is probably quite trivial.
Benefits:
Having @: and :@ mean different things would be awkward.
Conversion Cost:
Existing user code would be unaffected.
Aesthetics:
Leaving these unordered is slightly simpler conceptually.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1619 Masinter.pa@Xerox.COM Format for proposals to the cleanup committee (Version 11)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:19:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:04:43 PDT
Date: 11 Jun 87 13:04 PDT
From: Masinter.pa@Xerox.COM
Subject: Format for proposals to the cleanup committee (Version 11)
To: X3J13@Sail.stanford.edu
Message-ID: <870611-130443-1598@Xerox>
The previous version went out without line breaks.
!
Format for proposals to the cleanup committee (Version 11)
June 11, 1987
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable symbol in the
Common Lisp style, e.g., CDR-TERMINATION.<<
References: >>The pages of CLtL which describe the feature being
discussed, or other references.<<
Category: >>One or more of: CLARIFICATION -- proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE -- proposal for an
incompatible change to the language. ADDITION -- proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details. Avoid arguing for the proposal here, just describe it.<<
Test Case:
>>When possible, give a sample of Common Lisp code that illustrates the
issue. The code should stand alone, and preferably be suitable for
incorporation in a diagnostic suite. <<
Rationale:
>> A brief argument for the proposal. (If more than one proposal is
listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more.<<
Adoption Cost:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Conversion Cost:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc.<<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. A blow-by-blow account of debates is not necessary. <<
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:20:43 PDT
Date: 11 Jun 87 15:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: IMPORT-SETF-SYMBOL-PACKAGE (Version 5)
To: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
Message-ID: <870611-152043-1809@Xerox>
This issue was distributed at the last X3J13 meeting. The only changes
were to remove a sentence about INTERN (which didn't belong in this
proposal) and to put it in the current proposal format.
!
Issue: IMPORT-SETF-SYMBOL-PACKAGE
References: IMPORT (CLtL p. 186)
Category: CLARIFICATION.
Edit History: Version 2 at committee meeting 15-Mar-87 15:19:23
Version 3 by Masinter 15-Mar-87 18:42:13
Version 4 29-May-87 by Masinter, remove confusing
"to further clarify".
Version 5 to X3J13
Problem Description:
The action of IMPORT on the home package of a symbol is not described
well; does it affects the "home package" of a symbol.
Proposal (IMPORT-SETF-SYMBOL-PACKAGE:YES):
IMPORT behaves as follows: if any symbol to be imported has no home
package (SYMBOL-PACKAGE returns NIL), then IMPORT sets the home package
of the symbol to the specified package being imported to.
Rationale:
Current practice:
Most Common Lisp implementations work this way.
Adoption Cost:
small -- it requires a simple rewrite if not done this way.
Benefits:
Without this proposal, there is confusion about how Common Lisp works,
and the risks that some new implementations will not work this way.
Conversion Cost:
None, as this describes current practice.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1625 Masinter.pa@Xerox.COM (REVISION) Issue: PATHNAME-STREAM (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:27:51 PDT
Date: 11 Jun 87 15:27 PDT
From: Masinter.pa@Xerox.COM
Subject: (REVISION) Issue: PATHNAME-STREAM (Version 3)
TO: X3j13@sail.stanford.edu
Line-fold: NO
CC: Masinter.pa@Xerox.COM
REPLY-To: CL-Cleanup@sail.stanford.edu
Message-ID: <870611-152751-1817@Xerox>
Version 2 of this proposal accidentally contained an odd sentence fragment under Conversion cost. Sorry.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (remove odd
odd sentence fragment)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement. CLtL says that a stream can be used as an argument and converted to a pathname, but pathnames only name files, not other sources or sinks of data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that is or was open to a file. For example, it is an error to attempt to obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the only thing that can be implemented without large changes to the language such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname. Others may do something else, but since the proposal is to define this to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an error", no implementations need change.
Benefits:
Description of pathname functions will make more sense.
Conversion Cost:
None.
Aesthetics:
Makes language a little cleaner.
Discussion:
The cleanup committee supports this clarification.
∂11-Jun-87 1623 Masinter.pa@Xerox.COM Issue: PATHNAME-STREAM (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:23:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:06:30 PDT
Date: 11 Jun 87 15:06 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 2)
TO: X3j13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
REPLY-To: CL-Cleanup@sail.stanford.edu
Message-ID: <870611-150630-1795@Xerox>
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
CLtL says that a stream can be used as an argument and converted to a
pathname, but pathnames only name files, not other sources or sinks of
data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream that
is or was open to a file. For example, it is an error to attempt to
obtain a pathname from a two-way-stream or a string-stream.
Rationale:
This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: We believe no existing user code relies on any values.
Aesthetics: Makes language a little cleaner.
Discussion: The cleanup committee supports this clarification.
∂11-Jun-87 1622 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:22:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:18:53 PDT
Date: 11 Jun 87 14:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 4)
To: X3J13@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <870611-141853-1738@Xerox>
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 3 11-Jun-87, for release
Problem Description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Clarify that MACROLET, FLET and LABELS can shadow a SETF method; i.e., a
SETF method applies only when the global function binding of the name is
lexically visible.
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.
Adoption Cost:
Some implementations will have to add this feature, although it is not a
major change.
Benefits:
This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.
Conversion Cost:
This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.
Aesthetics:
SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.
∂11-Jun-87 1621 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 16:21:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:43:23 PDT
Date: 11 Jun 87 13:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
TO: X3J13@sail.stanford.edu
reply-To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-134323-1657@Xerox>
!
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Category: OMISSION
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Versions 4,5 by Fahlman 11-Apr-87
Version 6 by Masinter 5-Jun-87
Problem Description:
Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
FLET.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
Two alternatives to the proposal were considered and rejected:
The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks. This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.
The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms. There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
However, eliminating the implicit block in DEFUN would be a significant
incompatible change. Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature. While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations. The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.
∂11-Jun-87 1842 Masinter.pa@Xerox.COM Issue: PRINC-CHARACTER (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 18:42:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:35:38 PDT
Date: 11 Jun 87 15:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PRINC-CHARACTER (Version 2)
TO: X3J13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Reply-to: CL-cleanup@sail.stanford.edu
Line-fold: NO
Message-ID: <870611-153538-183@Xerox>
!
Issue: PRINC-CHARACTER
References: PRINC (p383)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Problem Description:
CLtL is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* For (FORMAT NIL "Foo~ABar" #\Space)
Pretty result: "Foo Bar"
Ugly result: "FooSpaceBar"
In other words, " " looks better here.
* For (FORMAT T "Type ~C to continue" #\Space)
Pretty result: "Type Space to continue"
Ugly result: "Type to continue"
In other words, "Space" looks better here.
Proposal (PRINC-CHARACTER:WRITE-CHAR):
(PRINC char stream) should be defined to be equivalent to
(WRITE-CHAR char stream).
Rationale:
The behavior of (PRINC char) should be well-defined even if a
completely arbitrary decision had to be made.
In fact, though, we can get some advice by appealing to history.
The only data type which corresponds to characters in most old
lisps was symbols. For example, in Maclisp,
(PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))
In Common Lisp, it would make sense in the absence of arguments
to the contrary to preserve an analagous relation, namely:
(PRINC char) == (WRITE-CHAR char)
Current Practice:
Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
"Space" for (PRINC #\Space).
Symbolics and Spice are known to use the WRITE-CHAR strategy.
Vaxlisp and Lucid might be using it, too, or they might be
using ~C in FORMAT; no one familiar with their internals has
commented.
In any case, some other implementations are believed to differ
(ie, to output "Space" when you PRINC a #\Space), but a specific
reference is not currently available. In any case, the wording
in CLtL is not clear enough to preclude such a differing
implementation from `legitimately' emerging.
Adoption Cost:
Any implementations which did not already implement this proposal
decided upon would suffer an incompatible change.
Benefits:
User code that uses PRINC (and presumably ~A) on characters would
have a chance of being portable.
Conversion Cost:
It's easy to search for occurrences of PRINC and ~A in code, but
it may not always be apparent when the argument is a character.
Automatic conversion is unlikely to succeed.
Aesthetics:
Making PRINC do something well-defined for as many primitive data
types as possible will probably be perceived as a simplification.
Discussion:
The cleanup committee generally supports this proposal.
Pitman thinks this is moderately important because it is embarrassing
to have commonly used functions like this vary so widely in behavior
between implementations. He doesn't think it is critical because
(if nothing else) it is only one of many problems with the vague
contract of PRINC.
There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
suggested making PRINC work like ~C in FORMAT, but no one seemed
to think that was useful and the proposal was removed for Version 2
to keep from muddying what's likely to be a very straightforward
vote in favor of PRINC-CHARACTER:WRITE-CHAR.
∂15-Jun-87 1920 Masinter.pa@Xerox.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87 19:20:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 14:43:28 PDT
Date: 15 Jun 87 14:15 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
cc: Masinter.pa@Xerox.COM
Message-ID: <870615-144328-103@Xerox>
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
Problem Description:
CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.
As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls. The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list. The
keyword-indicator can be any symbol, not just a keyword.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place. In this case, it becomes desirable to use packages to prevent
accidental name clashes among non-positional argument names of different
functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in. If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.
The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Adoption Cost:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Conversion Cost:
None--no existing programs will stop working.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂16-Jun-87 2337 Masinter.pa@Xerox.COM
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 17:17:44 PDT
Date: 16 Jun 87 17:17 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.Edu
Message-ID: <870616-171744-109@Xerox>
This is the cover letter for the various proposals which have been
mailed to you. Hardcopy versions of all proposals will go out in
tomorrow's (U.S.) mail.
!
Dear X3J13 member:
Enclosed are several proposals from the cleanup committee for your
examination. The committee has been working hard via electronic mail.
For each proposal, there has been an average of 10-15 messages.
In most cases, the cleanup committee has explicitly endorsed the
proposal--i.e., we all think it is a good idea. In some cases, while we
generally agreed that the proposal is a good idea, we've wrangled over
the exact wording of the proposal and the discussion; in those cases,
while an earlier version was circulated among the cleanup committee, the
latest version is the sole responsibility of the author. In a few cases
(identified in the proposal) there has been disagreement on the proposal
itself, but we believed we should bring the matter to the attention of
the larger group, for discussion and guidance.
Listed below are all of the issues currently under consideration, with
an extremely brief description of the issue. If you want further
details, or want to join the cleanup committee, please let us know
(CL-CLEANUP@Sail.Stanford.edu). Issues whose writeup is included in
this mailing (and mailed electronically) are marked with a !. Issues
marked with * are nearly ready for release, but a final version is not
available. We hope to have versions of these at the X3J13 meeting.
!
! Proposal format (Version 11)
Format for proposals to the cleanup committee.
Version 11 released 11-Jun-87.
* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
(Standardize interaction of adjust-array and displacement)
Discussion about :displaced-to nil vs. no :displaced-to.
Not ready for release.
ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
(Extend adjust-array so its OK on non-adjustable arrays.)
Several comments which need reply
Not ready for release.
! AREF-1D (Version 5/11 Jun 87)
(Add a new function for accessing arrays with row-major-index)
Version 5 released
ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
(Extend ASSOC-IF, etc. to allow :KEY)
Almost ready for release.
COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
(Does *BREAK-ON-WARNING* affect the compiler?)
Questions on interaction with condition proposal.
Is this an environment issue?
Not released.
! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 3 released.
Version 6 released 11-Jun-87.
! DEFVAR-INITIALIZATION (Version 4)
((DEFVAR var) doesn't initialize)
Version 3 Released
Version 4 released 11-Jun-87.
! DEFVAR-INIT-TIME (Version 2/29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 released 11-Jun-87.
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
(can DO-SYMBOLS see the same symbol twice?)
Debate: extend so that both options are available?
Not ready for release.
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
("selective linking" means GC non-used symbols;
proposal to change #., #, and part of FUNCTION-TYPE)
Not ready for release.
FILE-WRITE-DATE-IF-NOT-EXISTS
(What does FILE-WRITE-DATE do if no such file?)
Defer to condition system?
In discussion, formal proposal not yet submitted.
! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 released 11-Jun-87.
! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
( @: == :@ in format)
Version 3 released.
Version 4 (re-)released 11-Jun-87.
* FORMAT-COMMA-INTERVAL (Version 1/10 June 87)
(Allow another argument to ~D etc to paramerize digits between commas)
Almost ready for release.
FORMAT-NEGATIVE-PARAMETERS
In discussion, formal proposal not yet submitted.
! FORMAT-OP-C (Version 5/ 11-Jun-87)
(What does ~C do?)
Version 5 released 11-Jun-87.
! FUNCTION-TYPE (Version 5/ 16-Jun-87)
(Change definition of FUNCTIONP, function type ...)
Draft released 16-Jun-87.
GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
Not ready for release.
! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 released 11-Jun-87.
! IF-BODY (Version 7, 16-Jun-87)
(extend IF to implicit progn if more than one ELSE form?)
Draft released 16-Jun-87.
IGNORE-ERRORS (Version 4, 29-May-87)
(Introduce error catcher)
Pitman will release as report from cleanup + error committee.
! IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
(Does IMPORT affect home package?)
Version 3 Released
Version 5 released 11-Jun-87.
! KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
( &KEY arguments not in keyword package?)
Version 6 released 15-Jun-87.
LOAD-TIME-EVAL (Version 1, 6 Jun 87)
(New function/macro/special form for evaluation when
compiled file is loaded?)
Not ready for release.
MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
From ENVIRONMENT-ARGUMENTS
Formal proposal not yet submitted.
! PATHNAME-STREAM (Version 2)
(PATHNAME only works on file streams)
Released 11-Jun-87.
PATHNAME-SYMBOL (Version 2)
(Do symbols automaticly coerce to pathnames?)
Not ready for release.
PEEK-CHAR-READ-CHAR-ECHO (Version 1)
(character interaction with echoing on terminal)
Not ready for release.
! PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Released 11-Jun-87.
PROCLAIM-LEXICAL (Version 1)
(add LEXICAL proclaimation, default binding type for
undeclared free variables)
Not ready for release.
PROMPT-FOR (Version 1)
(add new function which prompts)
Not ready for release.
PUSH-EVALUATION-ORDER
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
In discussion, formal proposal not yet submitted.
REQUIRED-KEYWORD-ARGUMENTS
(Syntax for keyword arguments which must be supplied?)
In discussion, formal proposal not yet submitted.
REMF-DESTURCTION-UNSPECIFIED (Version 1)
(How does REMF affect its arguments?)
Not ready for release.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
In discussion, no clear consensus
Not ready for release.
SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Not ready for release.
SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Not ready for release.
SHARPSIGN-PLUS-MINUS-PACKAGE
(What package are *features* in?)
Not ready for release.
SPECIAL-FORM-SHADOW
(Is it OK to shadow a special form with FLET, LABELS?)
In discussion, no formal proposal submitted.
TAILP-NIL
(Operation of TAILP given NIL)
Not ready for release.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
(GO out of UNWIND-PROTECT clauses.)
Not ready for release.
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: IF-BODY (Version 7)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 17:07:38 PDT
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: IF-BODY (Version 7)
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <870616-170738-108@Xerox>
The cleanup committee had a great deal of difficulty attempting to
arrive at a version of this proposal which fairly outlined the issues.
I don't think we succeeded. While the issue itself is straightforward,
the way in which it came about, our procedures for handling
controversial cases, the manner in which summaries of opinions get
generated, etc. have been problematic. Hidden within this simple issue
are some more complex ones, with tradeoffs between compatibility and
extensions, simplicity and ease of use. As it stands, while we have
discussed reviewed numerous versions of this proposal, this version has
not been approved or endorsed by the cleanup committee as a whole.
Larry Masinter
!
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history:27-Feb-87, Version 1 by Pitman (IF-BODY:YES)
3-Mar-87, Version 2 by Fahlman (add IF-BODY:NO)
17-Apr-87, Version 3 by Masinter(merge 1&2)
19-Apr-87, Version 4 by Pitman (misc editing)
27-Apr-87, Version 5 by Pitman (for balance)
13-Jun-87, Version 6 by Pitman (for brevity)
16-Jun-87, Version 7 by Masinter(for brevity)
Problem Description
CLtL defines the special form IF as taking either two or three
arguments. Some implementations extended IF to allow more arguments. In
those implementations, using the extended IF syntax will not generate a
warning. Code using the extended IF is not portable.
Proposal (IF-BODY:LEGAL):
Extend IF, making it expressly legal to supply an implicit-PROGN of
`else' forms using the syntax (IF test then {else}*).
Test Case:
(IF NIL 'THEN 'ELSE 'MORE)
according to CLtL is an error. Under IF-BODY:LEGAL, this would return
MORE.
Rationale:
This extension is convenient to use and is compatible with many current
implementations.
Current Practice:
According to CLtL, the test case, (IF NIL 'THEN 'ELSE 'MORE) "is an
error".
Some implementations already provide the proposed extension.
A few implementations provide alternate keyword-driven extensions that
are incompatible with the proposed extension.
Some implementations signal an error if other than two or three
arguments are passed.
Some implementations quietly ignore additional arguments to IF,
returning only the value of the third argument when the first argument
is false.
Benefits:
As long as some implementations provide this extension while others do
not, the portability goals of Common Lisp will suffer. Code developed
where these features are available is not typically discovered to be in
error until a port to some other implementation is attempted. At that
point, which is typically inconveniently late in the development cycle,
the developer may notice that code either does not compile (generates
syntax errors) or does not compile correctly (the additional forms are
quietly ignored and the code generated is not what the writer intended).
The problem is rightly due to the user, but users typically expect that
they should be warned about such problems. Unfortunately, however, both
the Lisp which allows the extended syntax and that which fails to signal
an error about the invalid syntax are within their rights as currently
stated.
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
Adoption Cost:
In most implementations which don't already have this extension, making
this syntax legal is a matter of a fairly localized change to a finite
number of utilities which reason about programs (compiler, interpreter,
code walkers).
In some implementations which have incompatible extension strategies,
such as keyword-driven facilities, the cost may be slightly higher
because this is an incompatible change.
Aesthetics:
This issue has both pro and con sides. Opinions differ on how important
each of these arguments are. The following arguments have been made:
Pro: When there are multiple else clauses, the alternatives (IF test
then (PROGN else1 else2)) or (COND (test then) (T else1 else2 else3))
are cumbersome. A natural extension of IF provides economy of expression
in some circumstances. Experience in user communities where extended IF
is available show that few users object to its presence; most are happy
about the syntactic flexibility it provides. By allowing the extended
IF, the resolution of this controversial programming style issue is left
to the user rather than being forced by the language designers. Those
who prefer the symmetry of the (IF test then else) syntax are free to
use it as needed or even exclusively without infringing on the desires
of others who may wish to use the extended syntax.
Con: The (IF test then else) syntax is symmetric. The asymmetry of (IF
test then {else}*) syntax can be visually confusing. IF was intended to
be the simplest conditional form, from which all the others are built.
This proposal makes it more complex.
Discussion:
The cleanup committee had a great deal of difficulty with this issue,
primarily because of the many conflicting priorities it seems to
represent. It prompted a great deal of debate.
The committee found it nearly impossible even to arrive at a version of
the problem statement and proposal which could be endorsed as a fair
representation of the issue. In particular, this version has not been
endorsed or agreed upon by all members the committee.
Some members feel very strongly that this proposal should be adopted,
while others object violently, not only to the proposal but to the
manner in which it arose. How can we balance flexibility against
simplicity in the language syntax? How seriously should we consider
compatibility with current extensions to Common Lisp?
The problem with IF-BODY arose as a serious compatibility issue in
porting a major Common Lisp application (MACSYMA).
There was strong sentiment that the allowed variance of IF is a serious
barrier to portability, and wants to see it fixed. Those who support
this proposal believe it is the minimally disruptive way to fix the
problem. If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
There was concern about the potential precedent which could be set by
using compatibility concerns as a lever to introduce all kinds of
unwanted idiosyncratic extensions present in a few implementations.
It was suggested that the mere fact that some people like an extensionis
not sufficient reason to put it into the language, but is sufficient
reason to -discuss- putting it into the language.
It was noted that one of the original reasons for including IF in the
language was to have a simple primitive that can easily be recognized,
by people and by program-walkers alike, as being the simplest
conditional and not having implicit PROGNs as do WHEN, UNLESS, and COND.
The supporters argue that the language is already so cluttered that
worrying about such a tiny change to IF is unwarranted (e.g., consider
the complexity of LAMBDA). If the only concern was primitive simplicity,
we should just redefine the layer at which simplicity is achieved by
letting LISP:IF be a macro that expands into PRIMITIVE:IF which has
simpler semantics but which no one has to be stuck programming with (if
they don't want to). While users could make their own JDOE:IF macro that
has this extension, this is likely to be a such a common extension, it
should be adopted as part of the standard.
∂16-Jun-87 2336 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87 23:36:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 15:51:21 PDT
Date: 16 Jun 87 15:33 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
Reply-to: CL-Cleanup@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870616-155121-101@Xerox>
FUNCTION-TYPE is one of the more difficult issues facing the cleanup
committee. This is a tough but important issue that involves some
fundamental trade-offs, so discussion by the whole X3J13 committee is
called for.
I am distributing version 5, even though the full cleanup committee has
not read or commented on it. Scott Fahlman worked hard to produce
Version 5; I think Scott's summary of the issues and arguments is
excellent. However, to repeat, because of insufficient time, this
proposal does not reflect a consensus of opinion, either on the proposal
or on the form in which it is presented.
This version presents the two options the committee discussed the most
as alternatives. We hope to be able to discuss (and revise) this
proposal before the Boston meeting. The proposal has two parts, one
less controversial than the other. It is possible that the group will
decide to postpone the difficult issues and just vote on the simpler
one.
The writing up of these two options was not meant to preclude others.
One other proposal was discussed, which would require a symbol's
function cell to accept symbols and lambda expressions as well as true
functions and to return unchanged whatever was put there. We do not yet
have an exposition of this point of view.
Since Scott Fahlman won't be at X3J13, he included his own position at
the end.
Sincerely,
Larry Masinter
!
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
SYMBOL-FUNCTION (pg 90), APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by Gabriel 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by Fahlman 10-May-87
Version 4 by Masinter 29-May-87 incorporate comments
Version 5 by Fahlman 15-June-87 include two options
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual. On page 47 it is stated that the FUNCTION type
specifier can only be used for declaration and not for discrimination.
Some of the original Common Lisp designers maintain that this
restriction on the use of the FUNCTION specifier was meant to apply only
to long-form FUNCTION specifiers. In any event, this issue blurs
the status of the FUNCTION data-type.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Two alternative proposals are presented here:
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION and INTERPRETED-FUNCTION. Note that this is a change
from the current Common Lisp definition which explicitly defines a
COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. FUNCALL and APPLY will now accept only a true function as the
functional argument. This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY. It is no longer legal to pass a symbol or lambda
expression as the functional argument to any of these functions; to do
so "is an error".
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".
Proposal FUNCTION-TYPE:COERCING-REDEFINITION
This is identical to FUNCTION-TYPE:STRICT-REDEFINITION except for
section 3:
3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments are modified to state
they will accept (true) functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this is not a change to the current behavior of
Common Lisp; the descriptions must be changed to accommodate the new
definition of the FUNCTION data type.
RATIONALE:
Both proposals provide a clean, useful definition for the FUNCTION
data-type in Common Lisp. Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.
The STRICT-REDEFINITION proposal consistently uses the new, strict
definition of FUNCTION in all of the obvious places.
The COERCING-REDEFINITION proposal cleans up the definition of the
FUNCTION data type, but attempts to minimize the impact on existing code
by providing implicit coercions in FUNCALL and APPLY.
Current Practice:
Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION. They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell. No current Common Lisp
implementation has exactly the semantics described in either of these
proposals, however.
Adoption Cost:
For either proposal, the type predicates would have to be brought into
compliance, but that should require little effort.
Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists. Such lists would have to be changed
to structures or to some special internal data type. The behavior of
COMPILE, STEP, TRACE, and possibly ED would have to be modified
to deal with functions that are not lists (but from which the list form
can be easily reconstructed if necessary).
If STRICT-REDEFINE is adopted, implementations may choose to convert
FUNCALL and APPLY to the new stricter form, but they are not required to
do so. Since the use of a symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension. Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.
BENEFITS:
By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme.
CONVERSION COST:
The COERCING-REDEFINITION proposal attempts to minimize the impact on
user code by allowing APPLY, FUNCALL, and related functions to accept
symbols and lambda lists, as they currently do. One impact on
user-level code would be a change in the operation of certain type
predicates. Such cases should be relatively easy to find and fix.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
Users might also convert their code by running for a time in an
implementation that still does the coercion in FUNCALL and APPLY, but
that issues a warning message whenever the coercion is actually needed.
This will flag all of the non-portable situations in parts of the
program that have actually been executed during the test period.
In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged. If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well. Some
old code (MACSYMA is one example) depends on this behavior and would
have to be modified if either of these proposals is adopted. However,
such code is not currently portable because many existing Common Lisp
implementations already violate these assumptions. CLtL does not
clearly state what values SETF of SYMBOL-FUNCTION will accept and how
that object may be modified.
Under either proposal, user code which uses COMPILED-FUNCTION-P would no
longer be valid or portable.
AESTHETICS:
Making the concept of a function well-defined will probably be perceived
as a simplification.
The STRICT-REDEFINITION proposal is perceived by most members of the
cleanup committee as the simpler and cleaner of the two proposals. The
COERCING-REDEFINITION proposal adds some complexity in the name of
compatibility.
DISCUSSION:
This has been discussed at great length within the cleanup committee.
All of us agree that the definition of the FUNCTION data type must be
revised, but there is no clear consensus on what to do about the
coercions. Since the cleanup of the type hierarchy is important to the
CLOS group, there is some urgency to this part of the proposal, at
least.
Some committee members (Gabriel and Fahlman) have argued that the strict
form of the proposal is preferable because it is simpler: it defines a
FUNCTION data type and then requires every object used as a function to
be a FUNCTION. The strict proposal requires a somewhat greater
conversion effort for user code, but it seems better to make this effort
once than to live forever with runtime coercion of functional arguments
and the resulting complexity.
Members of the Eulisp group have argued strongly for what amounts to the
STRICT-REDEFINITION proposal. They feel that this would remove one
important difference between their view of Lisp (similar to Scheme in
this instance) and ours.
Moon has argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.
Several members of the committee argued in favor of presenting both
proposals to X3J13, since the tradeoff between simplicity and conversion
effort must be discussed by the whole community.
White suggested that if the coercing version of the proposal is
adopted, we might need an APPLICABLE-P predicate that is true of any
object that is legal as a functional argument to APPLY and FUNCALL.
FUNCTIONP will not do this job.
Pitman has argued that items 4 and 5 (either proposal) will break a lot
of code that depends on being able to use lambda expressions and symbols
as function definitions, and that it will be hard to fix such problems.
He may produce a third proposal before the X3J13 meeting that deals with
these problems. He has suggested that we may wish to settle the type
redefinition issues (points 1 and 2 above) now, while deferring a
decision on the more controversial coercion issues.
Fahlman feels that the issues are now clearly drawn and that we should
go ahead and make a decision on the whole package.
Clinger has suggested that the strict form is preferable because it
makes
it possible to reduce the total size of a delivered application program.
Only those Common Lisp functions that are actually called need to be
included, but implicit function coercions tends to create loopholes
through which *every* function might be called.
The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.
Fahlman and Gabriel support FUNCTION-TYPE:STRICT-REDEFINITION.
∂17-Jun-87 0844 barmar@AQUINAS.THINK.COM Issue: FUNCTION-TYPE (Version 5)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 08:44:15 PDT
Received: from POLYCARP.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 32813; Wed 17-Jun-87 11:46:53 EDT
Date: Wed, 17 Jun 87 11:40 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617114008.1.BARMAR@POLYCARP.THINK.COM>
I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
existing code.
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
barmar
∂17-Jun-87 1150 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 11:50:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Jun 87 14:49:41-EDT
Date: Wed, 17 Jun 1987 14:49 EDT
Message-ID: <FAHLMAN.12311274316.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In reply to: Barry Margolin <barmar at AQUINAS.THINK.COM>
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
I see no big hole here.
The coercion is so trivial that I figured anyone writing a package to
convert old code to run under the STRICT-REDEFINITION rules could figure
out how to do it with no problem. And since this is a temporary crutch
for use on onconverted old code, I certainly don't think that we want to
add anything like MAKE-FUNCTION to the language; for all new code, users
will invoke FUNCTION for themselves in the appropriate places.
We do NOT want to add an environment argument to MAKE-FUNCTION. APPLY
and FUNCALL currently interpret symbols and lambda expressions in the
null lexical environment, not the surrounding one. That must be the
case, since the symbol or lambda may have come from some very different
part of the program.
Here's the way I would re-code APPLY, using a macro. FUNCALL, et al,
would be treated in a similar way. The covnersion tool would simply be
a code-walker (or perhaps even an editor macro) that turns every APPLY
into COERCING-APPLY unless the argument being passed in is sitting right
there and its type can be determined at conversion time.
(defmacro coercing-apply (funarg &rest other-args)
`(apply (let ((x ,funarg))
(typecase x
(function x)
(symbol (symbol-function x))
(t (eval (list 'function x)))))
,@other-args))
Assuming that the implementation has a good implementation of TYPECASE
and a quick test for the FUNCTION data type, this should add very little
extra cost to the APPLY call, except in the case where a raw lambda-list
needs to be function-ized. Some smart compilers may optimize away a
TYPECASE statement if the type of the object can be determined by
analysis at compile time.
Note that COERCING-APPLY is almost identical to what APPLY would look
like in the coercing version of the proposal, except that the
type-dispatch and coercion is outside the APPLY rather than inside.
Anyone arguing that the strict form of the proposal is unacceptable
because this fully-mechanized method of conversion introduces
inefficiency should realize that this same inefficiency is currently
built into *every* FUNCALL and APPLY, and would continue to be under the
coercing version of the proposal. Under the strict form, it only
appears in mechanically converted code, and then only in cases where the
type of the functional argument is not easily determined at
conversion/compile time. But I think that the overhead is so small
compared to an APPLY-type function call that efficiency is not a strong
argument for either side.
If code size is a bigger issue than the speed of APPLY, COERCING-APPLY
could be coded as a function rather than as a macro, or it could be done
as an inline function, letting the user control the tradeoff via
declarations. There are very few programs around in which the code size
would grow by more than 1%, even in the macro case.
So, fully mechanized conversion of old code is feasible under the
STRICT-REDEFINITION proposal. The question is whether we are willing to
accept even this small inconvenience in order to get a cleaner language
(if indeed you believe that the strict form is cleaner).
-- Scott
∂17-Jun-87 1247 barmar@Think.COM Issue: FUNCTION-TYPE (Version 5)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Jun 87 12:46:48 PDT
Received: from polycarp by Think.COM via CHAOS; Wed, 17 Jun 87 15:49:07 EDT
Date: Wed, 17 Jun 87 15:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
Cc: X3J13@sail.stanford.edu
In-Reply-To: <FAHLMAN.12311274316.BABYL@C.CS.CMU.EDU>
Message-Id: <870617154704.1.BARMAR@POLYCARP.THINK.COM>
Date: Wed, 17 Jun 1987 14:49 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
In reply to: Barry Margolin <barmar at AQUINAS.THINK.COM>
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.
We do NOT want to add an environment argument to MAKE-FUNCTION. APPLY
and FUNCALL currently interpret symbols and lambda expressions in the
null lexical environment, not the surrounding one. That must be the
case, since the symbol or lambda may have come from some very different
part of the program.
I now agree with this.
As for whether MAKE-FUNCTION should be added, I still think it should
be. If STRICT-REDEFINITION is adopted, then programmers who want to
turn lambda lists into functions will need a reasonable way to do this.
Yes, (EVAL `(FUNCTION ,LAMBDA-LIST)) will do it, but I don't think users
should have to write this. Generally, Lisp programmers are taught that
they should rarely need to invoke EVAL directly, unless they are
implementing an embedded language or something along those lines.
Consider the function:
(defun read-apply-print-loop ()
(loop (print (apply (make-function (read)))))
This isn't an embedded language, and there's no reason it should have to
call EVAL directly.
The coercion is so trivial that I figured anyone writing a package to
convert old code to run under the STRICT-REDEFINITION rules could figure
out how to do it with no problem. And since this is a temporary crutch
for use on onconverted old code, I certainly don't think that we want to
add anything like MAKE-FUNCTION to the language; for all new code, users
will invoke FUNCTION for themselves in the appropriate places.
I don't agree that this is a temporary crutch only for old code. There
is no way to write the above function without manually coercing lambda
lists to functions, because the lambda list that it is trying to apply
did not come from another program, it was generated on the fly (in this
case by the reader). There is no way for read to return a function
object (actually, there is a disgusting way, q.v.), it can only return a
lambda list.
Here's the disgusting way to make READ return a function: the user can
type "#.#'(lambda ...)".
barmar
∂17-Jun-87 1312 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Jun 87 13:12:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175697; Wed 17-Jun-87 16:11:37 EDT
Date: Wed, 17 Jun 87 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: CL-Cleanup@Sail.Stanford.Edu
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617161131.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Since apparently we're going to discuss this proposal at length on the
X3J13 mailing list, I just wanted to point out one minor hole in it.
CONVERSION COST:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
∂17-Jun-87 1535 DLW@ALDERAAN.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Jun 87 15:35:51 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93095; Wed 17-Jun-87 18:15:56 EDT
Date: Wed, 17 Jun 87 18:15 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP@Sail.stanford.edu, X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870617181519.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Jun 87 17:07 PDT
From: Masinter.pa@Xerox.COM
If this proposal is not accepted, it should be mandated that
extensions to IF are explicitly disallowed. The status quo, where there
is a tacit acceptance of extensions which are not portable and difficult
to detect, is unacceptable.
I'd like to state emphatically that I do not agree with this point of
view about extensions. The original point of Common Lisp was to be a
large common subset, designed to allow portable programs without
stifling extensions and experimentation, and without creating massive
compatibility problems. (I say "massive" because that's what would
happen if a policy of such explicit disallowal were applied across the
board.) If this attitude had prevailed at the beginning, there would
have been no Common Lisp.
I take the position that there ought to be tools that specifically help
you make sure that your program can be expected to run portably in other
CL implementations. The extended IF is not particularly "difficult to
detect" for such a tool; in fact, it's very easy. Meanwhile, the
extended implementation need not print out any warnings.
Such a portability tool is needed for other reasons: even if a
particular CL implementation doesn't have any "extensions", nevertheless
it necessarily makes choices about things that the CL manual leave up to
the implementation, and a program could be depending on those choices.
∂17-Jun-87 1740 Mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU updcoming meeting
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 17:40:16 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Jun 87 20:39-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 47846; 17 Jun 87 20:38:56-EDT
Date: Wed, 17 Jun 87 18:32 EDT
From: Mike%acorn@oak.lcs.mit.edu
Subject: updcoming meeting
To: x3j13@sail.stanford.edu
Message-ID: <870617183245.1.MIKE@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Sorry if you received this twice.
To: x3j13 participants
From: Gold Hill Computers
163 Harvard St.
Cambridge, MA 02139
617-492-2071
Gold Hill is handling the arrangements for the meeting
on June 30 and July 1.
The MIT/AI Lab has graciously offered to provide space
for the meetings on the 8th floor at 545 Technology Square,
Cambridge MA. In addition, classroom space for sub-committee
meetings on June 29 is also being provided. Room numbers
are as follows: 512, 516, 204, and 773.
Arrangements with the Cambridge Marriott Hotel for rooms
at a special rate of $115 have been arranged.
Contact Dana at Gold Hill about these rooms.
Arrangements have also been made with Delta Airlines for a
special fare. This will be a 30% discount on "Selling Y"
fares. It can apply to either coach or special coach fares.
Reservations must be made at least seven days in advance.
To use this discount, call Delta at 1-800-641-6760.
The identifying file number is A1680. The identifying
name is X3J13.
There will be a charge of $40 for each participant for
catering services provided for breakfast pastry,
coffee and lunch for both days.
My apologies about the late notifications.
Dana Kawiecki
Coordinator.
P.S., we regret that due to network failures, there is no
reliable way to contact Gold Hill by electronic mail at the
present time.
∂17-Jun-87 2011 FAHLMAN@C.CS.CMU.EDU Issue: IF-BODY (Version 7)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87 20:11:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Jun 87 23:10:30-EDT
Date: Wed, 17 Jun 1987 23:10 EDT
Message-ID: <FAHLMAN.12311365480.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: IF-BODY (Version 7)
In-reply-to: Msg of 16 Jun 1987 20:07-EDT from Masinter.pa at Xerox.COM <CL-CLEANUP at Sail.stanford.edu>
Since I will not be able to atend the X3J13 in Boston, I would like to
state my views on this proposal via mail. This message may also help to
explain what the "disagreements within the cleanup committee" were all
about.
If we look at this proposed extension purely as a matter of language
design, I am opposed to it, but not violently so. I think that it is
confusing to see something like
(IF pred-clause
clause-1
clause-2
clause-3
and-so-on)
in a program. The then-clause gets lost in all the clutter, and it is
harder to understand the program in a quick scan. If there
must be multiple else-clauses, I prefer to see something like
(IF pred-clause
(PROGN then-clause-1
then-clause-2)
(PROGN else-clause-1
else-clause-2
and-so-on))
The two distinct conditional branches jump out at you in this case.
Since this extension would affect my ability to READ Common Lisp code,
it is little consolation that I don't have to use the new construct
myself.
Another problem with the proposed extension: If one is allowed only one
"then" clause but multiple "else" clauses, some users will be tempted to
negate the test in order to get the more complex result into the "else"
position. Again, this makes code harder to read and understand. It is
no big thing, but neither is an occasional PROGN.
Well, so much for my own sense of aesthetics. If the members of X3J13
disagree -- if they really feel that the proposed extension improves
Common Lisp -- then so be it.
The real disagreement concerned the other argument in the proposal. It
goes roughly like this: Some manufacturers have unilaterally adopted
this extension. Their users get screwed when they move their code into
Common Lisp systems without this extension. The extension is compatible
and relatively innocuous. Therefore, we should force every Common Lisp
to adopt this extension so that these poor users won't have to suffer.
Or, if we are unwilling to do that, we must explicitly outlaw this
extension. (Clever straw-man, that.)
I think that it would be a very dangerous precedent if we were to give
this argument any weight whatsoever. This same line of argument could
be used to smuggle all sorts of idiotic extensions into the language.
It has always been an important principle of Common Lisp that
implementation-specific extensions are allowed; we would never have
reached agreement if this were not the case. So it would be wrong to
outlaw the extended form of IF. But code that makes use of non-portable
extensions is not portable, and its users should not expect it to be.
Vendors of extended Common Lisp systems should make life easy for the
developers of portable code by providing a compiler mode that warns
about non-standard usage. In the case of extended IF, this would be
very easy, and the fix is equally easy: just add a PROGN. So if users
really are experiencing the portability problems described in this
proposal, they should ask the manufacturer of the system they are using
to provide such a tool. That is the right way to handle portability
problems caused by non-standard extensions. If the manufacturer doesn't
think the portability problem is serious enough to fix, why should we
change the language to make this system's users more comfortable?
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
That's an amazingly arrogant position. It is quite possible to think
that a non-portable feature is wonderful and still provide your
customers with a "warn about non-portable usage" mode that will save
them from hassles if they ever need to move their code to some less
enlightened system that merely implements the Common Lisp standard.
Anyway, that's what the disagreement was about, along with much
procedural discussion about how much of this debate should appear in the
proposal and about whether the proposal should go out at all.
-- Scott
∂18-Jun-87 0736 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 07:36:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 18 Jun 87 10:35:41-EDT
Date: Thu, 18 Jun 1987 10:35 EDT
Message-ID: <FAHLMAN.12311490219.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: X3J13@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 17 Jun 1987 16:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In response to Moon:
I tried to respond to this yesterday, but it looks like the mail system
ate my message. My apologies if anyone sees this twice.
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc...
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
This is true. However, it still is not particularly hard for a
code-walker or even a smart editor macro to find all of these :test and
:key arguments and to see if they need repair. In the overwhelming
majority of these cases, the functional argument is sitting there
explicitly after the keyword, either quoted or already wrapped in a
FUNCTION. The former can be fixed trivially, and the latter need no
fixing. Very few of these cases will end up requiring a runtime
type-test.
-- Scott
∂18-Jun-87 0821 shebs%orion@cs.utah.edu IF with multiple ELSE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 08:21:26 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA00828; Thu, 18 Jun 87 09:23:09 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA12575; Thu, 18 Jun 87 09:23:06 MDT
Date: Thu, 18 Jun 87 09:23:06 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8706181523.AA12575@orion.utah.edu>
To: x3j13@sail.stanford.edu
Subject: IF with multiple ELSE
Count this as an absentee ballot against multiple ELSEs in IF. This
"feature" is in PSL, and it has been troublesome for maintainers on
several occasions. There doesn't seem to be any significant reasons
besides compatibility. In general, Common Lisp has been contorted by
the desire to retain compatibility - now that CL has proven successful
and the older dialects have faded somewhat, compatibility should take
a back seat to making the language more reasonable.
stan
∂18-Jun-87 0913 barmar@AQUINAS.THINK.COM Issue: IF-BODY (Version 7)
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 18 Jun 87 09:13:25 PDT
Received: from OCCAM.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 33136; Thu 18-Jun-87 12:16:18 EDT
Date: Thu, 18 Jun 87 11:27 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: IF-BODY (Version 7)
To: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
cc: X3J13@sail.stanford.edu
In-Reply-To: <FAHLMAN.12311365480.BABYL@C.CS.CMU.EDU>
Message-ID: <870618112702.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 17 Jun 1987 23:10 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
If we look at this proposed extension purely as a matter of language
design, I am opposed to it, but not violently so.
I'm not going to discuss the esthetics of the change, but I agree with
Scott that we shouldn't change IF (even though I occasionally use
multiple else-clauses in my own programs, but most of them make
extensive use of Symbolics OS features already, so they are not
portable).
It is not adequate to encourage implementors to warn about non-standard
uses since the only implementations which will implement the extension
are ones who think it is a good idea to use the feature, and people are
not inclined to warn about things they think are a good idea to use.
That's an amazingly arrogant position. It is quite possible to think
that a non-portable feature is wonderful and still provide your
customers with a "warn about non-portable usage" mode that will save
them from hassles if they ever need to move their code to some less
enlightened system that merely implements the Common Lisp standard.
There's been quite a bit of discussion about how to deal with extensions
before, and I'm going to restate my opinion.
It seems to me that it should not be that difficult to provide such a
facility, simply by using the package system. The Common Lisp
implementation I'm most familiar with is Symbolics, and they provide
their own package, SYMBOLICS-COMMON-LISP, which imports everything in
LISP and exports them plus all the Symbolics extensions. What they
could do is shadow in SCL any functions/special forms that are extended,
i.e.
(SI:DEFINE-SPECIAL-FORM LISP:IF
IF-EXPANDER (PRED THEN ELSE)
...)
(SI:DEFINE-SPECIAL-FORM SCL:IF
IF-EXPANDER (PRED THEN &REST ELSES)
...)
Portable applications would normally be written in packages that :USE
LISP, while non-portable applications could :USE SCL.
I realize that the package scheme doesn't solve all problems with
extensions, but it can go a long way. It could be used to solve this
problem, as well as LOOP (unless and until the fancy LOOP macro is
adopted).
barmar
∂18-Jun-87 1001 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 10:01:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 176524; Thu 18-Jun-87 12:59:36 EDT
Date: Thu, 18 Jun 87 12:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: X3J13@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12311490219.BABYL@C.CS.CMU.EDU>
Message-ID: <870618125936.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 1987 10:35 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In response to Moon:
One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc...
There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments. There are probably a few other functions that call FUNCALL
or APPLY internally.
This is true. However, it still is not particularly hard for a
code-walker or even a smart editor macro to find all of these :test and
:key arguments and to see if they need repair. In the overwhelming
majority of these cases, the functional argument is sitting there
explicitly after the keyword, either quoted or already wrapped in a
FUNCTION. The former can be fixed trivially, and the latter need no
fixing. Very few of these cases will end up requiring a runtime
type-test.
Scott, the "automatic strategy" sentence that I quoted out of context
was in the context of discussing how to put in run-time type tests.
∂18-Jun-87 1740 RWK@YUKON.SCRC.Symbolics.COM Issue: IF-BODY (Version 7)
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 17:40:51 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 226953; Thu 18-Jun-87 20:24:59 EDT
Date: Thu, 18 Jun 87 20:24 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: Barry Margolin <barmar@AQUINAS.THINK.COM>
cc: Scott E. Fahlman <Fahlman@c.cs.cmu.edu>, X3J13@sail.stanford.edu
In-Reply-To: <870618112702.1.BARMAR@OCCAM.THINK.COM>
Message-ID: <870618202441.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 11:27 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
It seems to me that it should not be that difficult to provide such a
facility, simply by using the package system. The Common Lisp
implementation I'm most familiar with is Symbolics, and they provide
their own package, SYMBOLICS-COMMON-LISP, which imports everything in
LISP and exports them plus all the Symbolics extensions. What they
could do is shadow in SCL any functions/special forms that are extended,
i.e.
This doesn't work so well if there are any applications or any part of
CL that uses that symbol for EQness. For example, if I ran an application
that used 'IF as part of the protocol for interfacing to it, and it was
written in strict CL (and was therefor loaded into our LISP: package)
and I wanted to use it from SCL, things would start getting very confusing.
If you're just dealing with a single application, however, this works so
long as the symbol isn't one of the few symbols that CL uses the EQness
of (such as DOCUMENTATION, VARIABLE, EVAL, COMPILE, LOAD, EQ, EQL, EQUAL,
&ALLOW-OTHER-KEYS, &AUX, &BODY, &ENVIRONMENT, &KEY, &OPTIONAL, &REST, or
&WHOLE.
You also screw up importing any "portable" program-understanding code
that knows anything about that symbol. (Program-understanding code
is not necessarily some big thing that knows the whole language; SETF
is a much smaller example).
In general, shadowing has a lot to disrecommend it as a strategy for
extending Common Lisp.
These comments don't apply, however, to sub-environments intended
directly for developing and testing code intended to be strictly
portable.
∂18-Jun-87 2350 RWK@YUKON.SCRC.Symbolics.COM IF with multiple ELSE
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Jun 87 23:50:14 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 227051; Fri 19-Jun-87 02:49:51 EDT
Date: Fri, 19 Jun 87 02:49 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
To: Stanley T. Shebs <shebs%orion@cs.utah.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706181523.AA12575@orion.utah.edu>
Message-ID: <870619024952.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 18 Jun 87 09:23:06 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Count this as an absentee ballot against multiple ELSEs in IF. This
"feature" is in PSL, and it has been troublesome for maintainers on
several occasions. There doesn't seem to be any significant reasons
besides compatibility. In general, Common Lisp has been contorted by
the desire to retain compatibility - now that CL has proven successful
and the older dialects have faded somewhat, compatibility should take
a back seat to making the language more reasonable.
stan
On the contrary! This is not an issue of compatibility with
older dialects. There are two reasons:
1) Convenience. Several modern dialects have it because we find it
very convenient to use.
1a) Inconvenience of the alternative. PROGN hastens your indentation's
march to the right edge of your screen.
2) Compatibility with those *modern* dialects which choose to extend
IF in this way.
The issue isn't compatibility with older dialects; I agree that can take
a back seat.
While I'm at it, I may as well point out that many of us who use the
extended IF indent it in a way that the THEN and ELSE clauses are
readily distinguished. I find
(IF (CONDITION-FORM)
(THEN-FORM)
(ELSE-FORM))
confusing, even without additional ELSE forms, especially if the
condition form is longer than one line. I prefer
(IF (CONDITION-FORM)
(THEN-FORM)
(ELSE-FORM))
I think this would render the "readability" argument irrelevant,
except there are those who dislike this for reasons I've never
fathomed. (But let's not debate what the best indentation is
here, please! I'm just pointing out the alternative).
∂19-Jun-87 2100 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Jun 87 21:00:21 PDT
Received: by navajo.stanford.edu; Fri, 19 Jun 87 20:57:39 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05237; Fri, 19 Jun 87 20:35:00 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA05585; Fri, 19 Jun 87 20:37:23 PDT
Date: Fri, 19 Jun 87 20:37:23 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706200337.AA05585@bhopal.edsel.uucp>
To: navajo!RWK%YUKON.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!shebs%orion%cs.utah.edu@navajo.stanford.edu,
navajo!x3j13%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Robert W. Kerns's message of Fri, 19 Jun 87 02:49 EDT <870619024952.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
This may be a hopeless quest but . . .
Why is there so little interest in having a conditional form for CL that
more closely approximates the standard computer-science language conditionals
(for "standard .. languages", read "Algol-like").
Interlisp has a format that many use and love:
(if <condition1>
then <clause11> <clause12> ... <clause1n1>
elseif <condition2>
then <clause21> <clause22> ... <clause2n2>
. . .
else <clausem1> <clausem2> ... <clausemnm>
)
and I think Franz Lisp added this format in an essentially upward-compatible
way. The only flaw with such an extension is that the word THEN can't be
used as an ordinary then clause by itself [but then again, how many times
does "then" or "else" appear as local variables, in programs like
(if <mumble> then 5)
where the ambiguity is apparent].
Isn't Common Lisp really much less than "modern" by providing only the
crude form (if <form1>
<form2>
<form3>)
as the primary conditional paradigm?
-- JonL --
∂19-Jun-87 2204 Moon@STONY-BROOK.SCRC.Symbolics.COM IF with multiple ELSE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jun 87 22:04:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177997; Sat 20-Jun-87 01:02:55 EDT
Date: Sat, 20 Jun 87 01:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
To: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706200337.AA05585@bhopal.edsel.uucp>
Message-ID: <870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Use COND.
If you don't like the parentheses, use M-expressions.
∂20-Jun-87 0437 edsel!bhopal!jonl@navajo.stanford.edu IF with multiple ELSE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jun 87 04:37:26 PDT
Received: by navajo.stanford.edu; Sat, 20 Jun 87 04:34:48 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05823; Sat, 20 Jun 87 03:24:42 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA05994; Sat, 20 Jun 87 03:27:06 PDT
Date: Sat, 20 Jun 87 03:27:06 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706201027.AA05994@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!x3j13%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 20 Jun 87 01:02 EDT <870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: IF with multiple ELSE
Re: Use COND.
If you don't like the parentheses, use M-expressions.
Is this a reply to the query "Why is Common Lisp aping ALGOL, but
winding up blatantly idiosyncratic, and for no useful reason"? If
so, then it it may well be interpreted as
Use FORTRAN (has 1950's level syntax, just like COND)
If you don't like the 80-column lines, use PascaModulADAlgolC
-- JonL --
∂21-Jun-87 1652 franz!frisky!jkf@ucbarpa.Berkeley.EDU Re: IF with multiple ELSE
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 21 Jun 87 16:51:00 PDT
Received: by ucbarpa.Berkeley.EDU (5.57/1.25)
id AA07095; Fri, 19 Jun 87 23:30:13 PDT
Received: from frisky by franz (5.5/3.14)
id AA29568; Fri, 19 Jun 87 23:20:19 PDT
Received: by frisky (3.2/3.14)
id AA13854; Fri, 19 Jun 87 23:15:50 PDT
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8706200615.AA13854@frisky>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
x3j13@sail.stanford.edu
Subject: Re: IF with multiple ELSE
In-Reply-To: Your message of Sat, 20 Jun 87 01:02:00 EDT.
<870620010248.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 19 Jun 87 23:15:49 PDT
>> Use COND.
Did you forget the little smiley face?
I've got a lot of experience using a if form with 'then', 'elseif' and
'else' clauses and I'd rate it about an order of magnitude more
readable than cond. I'd also rate 'cond' about a half order of
magnitude more readable than the common lisp 'if' (which is downright
unreadable).
∂22-Jun-87 0935 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 09:35:52 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 94385; Mon 22-Jun-87 12:03:15 EDT
Date: Mon, 22 Jun 87 12:02 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: IF with multiple ELSE
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: edsel!bhopal!jonl@navajo.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8706200615.AA13854@frisky>
Message-ID: <870622120219.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
∂22-Jun-87 1013 cperdue@Sun.COM Re: IF with multiple ELSE
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 10:13:04 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA02476; Mon, 22 Jun 87 10:09:34 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA07547; Mon, 22 Jun 87 10:08:51 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
id AA05089; Mon, 22 Jun 87 10:12:52 PDT
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8706221712.AA05089@clam.sun.com>
To: DLW@ALDERAAN.SCRC.Symbolics.COM
Subject: Re: IF with multiple ELSE
Cc: x3j13@sail.stanford.edu
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
This is more than a "matter of taste" issue. It is also a readability,
clarity, and error-proneness issue. My thanks are to JonL for bringing
this up. My personal vote has been for if with "then" and "else"
keywords and multiple "else" clauses ever since I first began to
use Interlisp-10 several years ago.
If-then-else-etc. in fact is a well-established part of my personal Lisp
programming practice. Let's pursue this issue further.
∂22-Jun-87 1112 DLW@ALDERAAN.SCRC.Symbolics.COM Re: IF with multiple ELSE
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 11:12:22 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 94440; Mon 22-Jun-87 14:12:04 EDT
Date: Mon, 22 Jun 87 14:11 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: IF with multiple ELSE
To: cperdue@Sun.COM
cc: x3j13@sail.stanford.edu
In-Reply-To: <8706221712.AA05089@clam.sun.com>
Message-ID: <870622141115.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@Sun.COM (Cris Perdue)
Let's pursue this issue further.
The only point I was trying to make is that I don't think that it will
be valuable to continue to discuss this over the X3J13 mailing list.
∂22-Jun-87 1126 FAHLMAN@C.CS.CMU.EDU IF with multiple ELSE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 11:23:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 22 Jun 87 14:12:18-EDT
Date: Mon, 22 Jun 1987 14:12 EDT
Message-ID: <FAHLMAN.12312578230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SAIL.STANFORD.EDU
Subject: IF with multiple ELSE
In-reply-to: Msg of 22 Jun 1987 13:12-EDT from cperdue at Sun.COM (Cris Perdue)
Regarding the (if ... then ... else ...) proposal:
This is the same rock on which every attempt to come up with a LOOP-like
construct has run aground: some people like the Interlisp/MIT-Loop-macro
style in which you have lengthy flat lists punctuated with reserved
symbols that play a syntactic role; others hate this and prefer a
"Lispy" syntax in which nested list structure is used to organize the
clauses and parts of a clause. I suppose that if we decide to swallow
the "psuedo-English" syntax for LOOP, then (if ... then ... else
...) is a natural thing to add as well. I suppose that one of these
days we will have to come to grips with this whole bag of worms again --
isn't there a committee working on this?
The current form of IF looks just fine to me, but that is probably a
matter of having seen so many of them. I once saw some code by Joe
Ginder (don't know if the idea was original with him or not) that simply
defined THEN and ELSE as macros that expand into PROGN of the same body.
Once can then write
(if <predicate>
(then clause
clause ...)
(else clause
clause ...))
A perverse programmer could really confuse things by switching the THEN
and ELSE symbols, but perverse programmers can write obscure code in any
event.
-- Scott
∂22-Jun-87 1207 barmar@Think.COM Re: IF with multiple ELSE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 12:07:29 PDT
Received: from occam by Think.COM via CHAOS; Mon, 22 Jun 87 15:07:19 EDT
Date: Mon, 22 Jun 87 15:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: IF with multiple ELSE
To: Cris Perdue <cperdue@sun.com>
Cc: DLW@alderaan.scrc.symbolics.com, x3j13@sail.stanford.edu
In-Reply-To: <8706221712.AA05089@clam.sun.com>
Message-Id: <870622150454.2.BARMAR@OCCAM.THINK.COM>
Date: Mon, 22 Jun 87 10:12:52 PDT
From: cperdue@sun.com (Cris Perdue)
It seems clear that this is one of those "matter of taste" issues,
depending a lot on personal preference and what you're accustomed to.
My experience has been that electronic mail discussions are not very
useful for such issues. Perhaps normal X3J13 channels would be more
effective.
This is more than a "matter of taste" issue. It is also a readability,
clarity, and error-proneness issue. My thanks are to JonL for bringing
this up. My personal vote has been for if with "then" and "else"
keywords and multiple "else" clauses ever since I first began to
use Interlisp-10 several years ago.
If-then-else-etc. in fact is a well-established part of my personal Lisp
programming practice. Let's pursue this issue further.
Unless someone plans on doing some human factors experiments, we will
not be able to make any objective decision about the "readability,
clarity, and error-proneness issue". The matter of taste that Dan
referred to was the fact that different people find the different forms
more readable, clear, or error-prone. Without concrete data, taste is
all we can go by. What we've seen so far is lots of people saying,
"well, I've been using FOO-LISP's WHIZ-BANG-IF feature for years, and
it's really great." Lots of people swore by Interlisp's DWIM feature,
but it wasn't put into CL either.
barmar
∂22-Jun-87 1214 shebs@cs.utah.edu Purpose of this Mailing List
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 12:10:43 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA09296; Mon, 22 Jun 87 13:12:32 MDT
Date: Mon, 22 Jun 87 13:12:32 MDT
From: shebs@cs.utah.edu (Stanley Shebs)
Message-Id: <8706221912.AA09296@cs.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Purpose of this Mailing List
What exactly is this mailing list for? It's pretty clear that arguments
will be carried on anywhere that they are not specifically forbidden.
To reduce traffic, this list should be one-way from committees to everybody
else, with all replies going to committees again, or else each individual
is allowed one public response to any single proposal from a committee.
stan
∂23-Jun-87 1104 RPG Meeting Room at MIT
To: x3j13@SAIL.STANFORD.EDU
Several people have pointed out to me that the 8th floor of 545 Tech
Square must be the AI Lab playroom. I had not really thought about where
the meeting might be held, and when I investigated further, I found out it
was indeed the playroom. The playroom, though colorful, is not an appropriate
place to meet because it is surrounded by the open doors of offices.
The person at Gold Hill who made the arrangements is out of town this
week, so I asked Rod Brooks to look into the situation. He found out that
the playroom was booked for Monday and Tuesday of next week. He reserved
6-120 (Building 6, room 120), which seats 175, for Tuesday and Wednesday
of next week for us. This room is in the eastern leg of the large
U-shaped building with the dome at the bottom and whose open end faces the
Charles river.
Since it might be that the current arrangements are for the wrong two days,
the catering plans might need to be altered, but I am unable to do that
until I can reach someone at Gold Hill.
I am leaving for Boston Friday morning, and, unless I can provide more
information before I leave, you ought to visit the playroom on the
8th floor when you arrive to find out where the meeting will really
be held.
-rpg-
∂25-Jun-87 2342 RPG Meeting Room
To: x3j13@SAIL.STANFORD.EDU
As of today it appears that the meeting room will be 6-120 at MIT. There
will be a sign at each room stating which room is the correct one.
-rpg-
∂26-Jun-87 1048 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Meeting Room
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 26 Jun 87 10:48:07 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 26 Jun 87 12:46:34-CDT
Date: Fri, 26 Jun 87 12:46 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Meeting Room
To: x3j13%SAIL.STANFORD.EDU@MCC.COM
cc: Loeffler@MCC.COM
In-Reply-To: <8706260705.AA01887@bell>
Message-ID: <870626124601.5.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
Date: 25 Jun 87 2342 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
As of today it appears that the meeting room will be 6-120 at MIT. There
will be a sign at each room stating which room is the correct one.
-rpg-
Would someone please see that maps are provided at the hotel for those
that do not know how to navigate the MIT campus.
-- David D. Loeffler
∂30-Jun-87 1109 procyon@Cs.Ucl.AC.UK Common Lisp Mailing List
Received: from [14.0.0.9] by SAIL.STANFORD.EDU with TCP; 30 Jun 87 11:08:22 PDT
Date: Tue, 30 Jun 87 18:55:53 BST
From: Richard Barber (ProcyonResearch) <procyon@Cs.Ucl.AC.UK>
To: x3j13@sail.stanford.edu
cc: mathis@c.isi.edu
Subject: Common Lisp Mailing List
We now have an ARPANET address. Please can you add us to the X3J13 mailing
list.
We haven't had any mailings from the committee for quite a while now. Perhaps
you haven't received our subscription?
Richard Barber
Procyon Research Limited
England.
∂02-Jul-87 1648 MATHIS@ADA20.ISI.EDU BALLOT! ISO NWI
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 16:48:48 PDT
Date: 2 Jul 1987 06:14-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: BALLOT! ISO NWI
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 2-Jul-87 06:14:29.MATHIS>
This is to inform/remind all of you that there will be a mail
ballot on the ISO New Work Item on Lisp. This was distributed
and discussed at the recent meeting in Cambridge. There will be
a very short respose time. Expect to see something on the net
this weekend and in your physical mail next week. -- Bob
∂05-Jul-87 1803 MATHIS@ADA20.ISI.EDU DRAFT letter and ballot
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jul 87 18:03:19 PDT
Date: 5 Jul 1987 18:02-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: DRAFT letter and ballot
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jul-87 18:02:46.MATHIS>
What follows is a DRAFT of my letter and the X3J13 ballot
on the ISO New Work Item. This is not! the final version.
It is being sent to you for comment and advance notice.
Please comment within two days. -- Bob
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 1
Doc. No.: X3J13/87-030
Date: 87-07-06
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
(703)425-5923
Mathisda20.isi.edu
X3J13 Members and Mailing List Observers:
ACTION REQUIRED -- This mailing includes a mail ballot which must
______ ________
ACTION REQUIRED
______ ________
be returned by active US members of X3J
DEADLINE: NOON, July 28, 1987
________
DEADLINE
________
Copies of this ballot are being sent to all people on the X3J13
mailing list in a spirit of open communication and cooperation.
You are all welcome to send me comments on this issue, but you
should indicate what you want me to do with them; for example,
forward them to X3, forward them to the rest of X3J13, o
them to myself.
At the recent meeting of X3J13, the ISO "Proposed NWI [New Work
Item] on Programming Language Lisp (TC97 N 19206-092)
(X3J13/87-024) (also included with this mailing) was distributed
and discussed. It was decided that at least parts of this issue
had to have a written ballot and thus the whole issue should be
the subject of a mail ballot of X3J13.
The following are my summaries of the issues involved and the
discussions we had at the recent meeting. In being a summary it
means that some details have to be left out. I have tried to be
objective and put the issues clearly, but there may yet be some
other things that people ant to say. Our electronic mailing list
(X3J13s available for discussion. Anything
you put there which you want included with the record of this
vote should be forwarded to me with appropriate indications of
your wishes. Anyone who has a comment they would like put on the
electronic mailing list, but who does not have access to do it
himself, can send it to me in hard copy form and I will
redistribute it electronically.
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 2
I must have our response to X3 by July 29, 1987. I intend to take
it to them personnally that day. To be able to do that, I need to
have your responses by noon on Tuesday, July 28. If you are
intending to send in comments along with your ballot, I would
like to know that earlier if possible.
When the formation of an X3 technical subcommittee on Common Lisp
was first proposed, the documents also included a new work item
(NWI) proposal for ISO work in this same area. Both were passed
by X3 at that time. That NWI passed through TC97 to an ad hoc
group within SC22 which had been set up to consider NWIs in this
area. This NWI which we are now considering (TC97 N 1929) is a
revised version of that same NWI which was previously approved by
X3.
X3J13 has spent considerable time discussing its own goals, plan
of work and purposes and summarized its position in X3J13/SD-05
(discussed at the first two meetings and formally approved at the
third, March 16, 1987), which included "X3J13 is committed to
work with ISO toward an international Lisp standard."
These actions clearly indicate that X3 and X3J13 are in favor of
ISO work in the Lisp area. There is however another question on
the TC97 ballot which raised some concerns, "Q.1 Do you accept
the proposal in document [ISO/TC97 N 1929] as a sufficient
definition of the new work item?"
As always when there are significant issues raised in discussing
a formal vote, it also has to be decided whether those concerns
are more appropriately conveyed privately to other people
involved with the project, attached to a yes vote, or as the
comments associated with a negative vote. Even though X3J13 is
basically in favor of ISO work in the Lisp area, once it was
decided to have a mail ballot on the other issue, it was also
necessary to include this fundamental question.
In the report of that ad hoc working group within TC97/SC22
(ISO/TC97/SC22 N 266) (the Lisp related portion of which was
redistributed as X3J13/86-017 and is enclosed again with this
letter), a number of issues were discussed. That report provides
the background for this NWI. In particular, the following
paragraph was included:
The name of the working group has also been a discussion
topic. Lisp is a generic name describing a family of
languages. As such it is not an appropriate name for an ISO
standard. The US has suggested Common Lisp since they
believe it will emerge as Level 2 in the ISO work. The
European group has been using the name EuLisp for their
work. In approving a NWI in this area, the resulting working
group should be tasked to resolve this name issue. For
example, if Level 2 does turn out to be Common Lisp, that is
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 3
a well recognized name by which it should be called; on the
other hand, to call it that at the beginning would prejudge
the work in a way which is at the moment unacceptable.
Although the NWI does not say so explicitly, it should be assumed
that a new working group will start its work from the place where
that ad hoc working group left off, so it should not be necessary
to remind them formally of the content of that report.
If comments are to accompany the US response, the following
paragraph is being suggested. It is written so as to go with
either a positive or negative vote on whether the description of
the NWI is sufficient or not. This paragraph was not reviewed at
the meeting, but has been informally reviewed with some of the
members to be sure that it represents the views that were
expressed at the meeting and serves as an appropriate choice in
the context of this ballot.
Proposed Comments
________ ________
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfer with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Some people felt that these concerns and opions were well known
and accepted within the Lisp community; and that it was always
the case that a standards working group had to spend some of its
initial time agreeing on specifics of purposes and objectives; so
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 4
it was not necessary to formally state these issues in the US
reponse to TC97. "If 'it goes without saying,' it goes without
saying." On the other hand there is the view that it is just such
"obvious" things that need to be put down for the record so that
the work can proceed. As the discussion went on, comments
intended to support not making any formal comments were returned
as "exactly the reasons we should comment," and vice versa.
This is the central issue that motivated this mail ballot and is
Question 3 on the enclosed ballot -- should these concerns be
__________
made a formal part of the US response or not. The other questions
are asked because of asking this one. You may of course have
other concerns and comments about this or other issues related to
this NWI, which you should include with your response.
The comments and discussion here (and any you formally send me)
will be seen by X3 members and their vote will determine what and
whether any comments will be forwarded to TC97 as part of the US
ballot. This letter is being sent to everyone on the X3J13
mailing list which includes many people who are likely to be on
the ISO working group; so these comments and concerns are being
made known. The issue is primarily whether or not they will be
made a part of the formal and official US response to ISO/TC97.
Besides summarizing the issues and the discussion, I also want to
give you an indication of the way I think the people at the
meeting felt. The questions were not put to them in exactly the
way they are here, not everyone at the meeting will be able to
vote in this mail ballot, not everyone entitled to vote was at
the meeting, and some people have probably changed their mind
since they last expressed their opinion to me; but I think most
of the people would have voted on the questions here in one of
the following three ways, with the first one listed being the
most popular and the last one the least popular, but with none of
them having a majority.
1. yes 2. yes 3. no
1. yes 2. yes 3. yes
1. yes 2. no 3. yes
(If you notice the Gray code nature of the above, you may also
have some insight into why this was not decideable at the meeting
and is being submitted to a mail ballot.)
Comments are required with "No" votes. Since I have tried to give
the reasons for voting either direction, I assume some of you
will make your decision for basically the reasons described here,
so I have split the "No" choice into two parts for Questions 2
and 3 -- the first being "No" for the reasons given in this
letter and the second being "No" for other/additional reasons (in
which case you must give them).
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 5
As to the other items on the ballot (Q.3 -- Q.7) the answers are
all "YES." [Q.3] The US is prepared to actively participate in
this work. [Q.4] We already have at least six people who are
members of X3J13 who are interested in serving on an ISO working
group. They have the technical background and the resources to
make effective contributions. Their participation in this new
working group would not detract from any existing TC97 related
work. [Q.5] The book Common Lisp: The Language by Guy L. Steele
_________________________
Jr. is already listed as a reference on the NWI proposal. X3J13
has also been working on proposals for an object system, an
errors and conditions system, interfaces with window systems,
iteration mechanisms, conformance and validation, various issues
related to the Steele book, the Lisp1/Lisp2 issue, and many
others. [Q.6] These and other US documents will be made available
to the ISO Working Group as soon as it is formed and continually
in the future. [Q.7] Richard Gabriel and William Clinger have
expressed their willingness and are arranging the support
necessary for them to take on the role of project editor for this
work. They are both well known in the Lisp community and
respected for their insight into Lisp issues and their writing
abilities.
It is the desire and intention of X3J13 to be as open and
communicative as possible with the ISO work. X3J13 will continue
to be very active in working toward a standard that serves the
needs of the US and Common Lisp communities. Relevant documents
(from whatever source) will be circulated to both X3J13 and the
ISO working group.
Remember that this letter, a copy of the ballot, a summary of the
voting, and any comments you submit will be forwarded as a
package to X3 for their consideration (and to the X3J13 mailing
list as well of course). Even though I have tried to be objective
in these summaries, some of you may want to comment on any part
of my letter, the ballot issues, or the position X3 should take.
Such comments are part of the public standards process. I also
want to remind you that you may want to directly contact the X3
member from your company or organization.
If you have any questions about your responsibilities and/or
rights related to this ballot or if any of the issues are still
unclear, please contact me at Mathisda20.isi.edu or (703)425-
5923.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Ballot on ISO NWI July 5, 1987 DRAFT X3J13/87-030 DRAFT
DRAFT DRAFT Page 6
X3J13 Ballot on
Proposed NWI on Programming Language LISP (TC97 N 1929)
Deadline: Noon July 28, 1987 to Bob Mathis
_________
Question 1: X3J13 recommends to X3 a "YES" vote on the "Proposed
__________
NWI on Programming Language LISP (TC97 N 1929)"
YES NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 2: X3J13 recommends to X3 a "YES" vote that the proposal
__________
in TC97 N 1929 is a sufficient definition of the new work item.
YES NO (for the reasons stated in X3J13/87-030's summary
of the issues and discussions)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 3: X3J13 recommends that the "Proposed Comments" on page
__________
3 of X3J13/87-030 be attached as formal comments with the US
response to ISO/TC97 on this Proposed NWI. (An X3 vote of "NO" to
the sufficiency of definition will require that comments be
provided to TC97, but you may suggest ones other than those in
X3J13/87-030.)
YES NO (because YES votes on the previous two questions
will need no comments)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
There are some transmission errors in the above text; but I hope
it shows the main essence of the topic. -- Bob
∂12-Jul-87 2020 MATHIS@ADA20.ISI.EDU x3j13 ballot
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Jul 87 20:19:37 PDT
Date: 12 Jul 1987 20:19-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 ballot
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]12-Jul-87 20:19:06.MATHIS>
Doc. No.: X3J13/87-030
Date: 87-07-12
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
(703)425-5923
Mathis@Ada20.isi.edu
X3J13 Members and Mailing List Observers:
IMMEDIATE ACTION REQUIRED -- This mailing includes a mail ballot
which must be returned by active US members of X3J13.
DEADLINE: NOON, July 28, 1987 ELECTRONIC RESPONSE POSSIBLE (p. 4)
Copies of this ballot are being sent to all people on the X3J13
mailing list in a spirit of open communication and cooperation.
You are all welcome to send me comments on this issue, but you
should indicate what you want me to do with them; for example,
forward them to X3, forward them to the rest of X3J13, or keep
them to myself. Since the issue relates to the US position on an
ISO ballot, the US principal members of X3J13 are the ones who
must vote and who will determine the result.
At the recent meeting of X3J13, the ISO "Proposed NWI [New Work
Item] on Programming Language Lisp (TC97 N 1929)" (X3/87-06-092)
(X3J13/87-024) (also included with this mailing) was distributed
and discussed. It was decided that at least parts of this issue
had to have a written ballot and thus the whole issue should be
the subject of a mail ballot of X3J13. A draft of this letter and
ballot was distributed electronically for preliminary comment on
July 5, 1987.
The following are my summaries of the issues involved and the
discussions we had at the recent meeting. Being a summary it
means that some details have to be left out. I have tried to be
objective and put the issues clearly, but there may yet be some
other things that people want to say. Our electronic mailing list
(X3J13@SAIL. Stanford.edu) is available for discussion. Anything
you put there which you want included with the record of this
vote should be forwarded to me with appropriate indications of
your wishes. Anyone who has a comment they would like put on the
electronic mailing list, but who does not have access to do it
himself, can send it to me in hard copy form and I will
redistribute it electronically.
I must have our response to X3 by July 29, 1987. I intend to take
it to them personally that day. To be able to do that, I need to
have your responses by noon on Tuesday, July 28. If you are
intending to send in comments along with your ballot, I would
like to know that earlier if possible.
When the formation of an X3 technical subcommittee on Common Lisp
was first proposed, the documents also included a new work item
(NWI) proposal for ISO work in this same area. Both were passed
by X3 at that time. That NWI passed through TC97 to an ad hoc
group within SC22 which had been set up to consider NWIs in this
area. This NWI which we are now considering (TC97 N 1929) is a
revised version of that same NWI which X3 previously approved.
X3J13 has spent considerable time discussing its own goals, plan
of work and purposes and summarized its position in X3J13/SD-05
(discussed at the first two meetings and formally approved at the
third, March 16, 1987), which included "X3J13 is committed to
work with ISO toward an international Lisp standard."
These actions clearly indicate that X3 and X3J13 are in favor of
ISO work in the Lisp area. There is however another question on
the TC97 ballot which raised some concerns, "Q.1 Do you accept
the proposal in document [ISO/TC97 N 1929] as a sufficient
definition of the new work item?"
As always when there are significant issues raised in discussing
a formal vote, it also has to be decided whether those concerns
are more appropriately conveyed privately to other people
involved with the project, attached to a yes vote, or as the
comments associated with a negative vote. Even though X3J13 is
basically in favor of ISO work in the Lisp area, once it was
decided to have a mail ballot on the other issue, it was also
necessary to include this fundamental question.
In the report of that ad hoc working group within TC97/SC22
(ISO/TC97/SC22 N 266) (the Lisp related portion of which was
redistributed as X3J13/86-017 and is enclosed again with this
letter), a number of issues were discussed. That report provides
the background for this NWI. In particular, the following
paragraph was included:
The name of the working group has also been a discussion
topic. Lisp is a generic name describing a family of
languages. As such it is not an appropriate name for an ISO
standard. The US has suggested Common Lisp since they
believe it will emerge as Level 2 in the ISO work. The
European group has been using the name EuLisp for their
work. In approving a NWI in this area, the resulting working
group should be tasked to resolve this name issue. For
example, if Level 2 does turn out to be Common Lisp, that is
a well recognized name by which it should be called; on the
other hand, to call it that at the beginning would prejudge
the work in a way which is at the moment unacceptable.
Although the NWI does not say so explicitly, it should be assumed
that a new working group will start its work from the place where
that ad hoc working group left off, so it should not be necessary
to remind them formally of the content of that report.
If comments are to accompany the US response, the following
paragraph is being suggested. It is written to go with either a
positive or negative vote on whether the description of the NWI
is sufficient or not. This paragraph was not reviewed at the
meeting, but has been informally reviewed with some of the
members to be sure that it represents the views that were
expressed at the meeting and serves as an appropriate choice in
the context of this ballot.
Proposed Comments
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfere with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Some people felt that these concerns and opinions were well known
and accepted within the Lisp community; and that it was always
the case that a standards working group had to spend some of its
initial time agreeing on specifics of purposes and objectives; so
it was not necessary to formally state these issues in the US
reponse to TC97. "If 'it goes without saying,' it goes without
saying." On the other hand there is the view that it is just such
"obvious" things that need to be put down for the record so that
the work can proceed. As the discussion went on, comments
intended to support not making any formal comments were returned
as "exactly the reasons we should comment," and vice versa.
This is the central issue that motivated this mail ballot and is
Question 3 on the enclosed ballot -- should these concerns be
made a formal part of the US response or not. The other questions
are asked because of asking this one. You may of course have
other concerns and comments about this or other issues related to
this NWI, which you should include with your response.
The comments and discussion here (and any you formally send me)
will be seen by X3 members and their vote will determine what and
whether any comments will be forwarded to TC97 as part of the US
vote. This letter is being sent to everyone on the X3J13 mailing
list which includes many people who are likely to be on the ISO
working group; so these comments and concerns are being made
known. The issue is primarily whether or not they will be made a
part of the formal and official US response to ISO/TC97.
Besides summarizing the issues and the discussion, I also want to
give you an indication of the way I think the people at the
meeting felt. The questions were not put to them in exactly the
way they are here, not everyone at the meeting will be able to
vote in this mail ballot, not everyone entitled to vote was at
the meeting, and some people have probably changed their mind
since they last expressed their opinion to me; but I think most
of the people would have voted on the questions here in one of
the following three ways, with the first one listed being the
most popular and the last one the least popular, but with none of
them having a majority.
First Option: 1. yes 2. yes 3. no
Second Option: 1. yes 2. yes 3. yes
Third Option: 1. yes 2. no 3. yes
(If you notice the Gray code nature of the above, you may also
have some insight into why this was not decideable at the meeting
and is being submitted to a mail ballot.) If you want to choose
one of these options, you can respond electronically on this
ballot to Mathis@Ada20.isi.edu.
Comments are required with "No" votes. Since I have tried to give
the reasons for voting either direction, I assume some of you
will make your decision for basically the reasons described here,
so I have split the "No" choice into two parts for Questions 2
and 3 -- the first being "No" for the reasons given in this
letter and the second being "No" for other/additional reasons (in
which case you must give them).
As to the other items on the ISO ballot (Q.3 -- Q.7) the answers
are all "YES." [Q.3] The US is prepared to actively participate
in this work. [Q.4] We already have at least six people who are
members of X3J13 who are interested in serving on an ISO working
group. They have the technical background and the resources to
make effective contributions. Their participation in this new
working group would not detract from any existing TC97 related
work. [Q.5] The book Common Lisp: The Language by Guy L. Steele
Jr. is already listed as a reference on the NWI proposal. X3J13
has also been working on proposals for an object system, an
errors and conditions system, interfaces with window systems,
iteration mechanisms, conformance and validation, various issues
related to the Steele book, the Lisp1/Lisp2 issue, and many
others. [Q.6] These and other US documents will be made available
to the ISO Working Group as soon as it is formed and continually
in the future. [Q.7] Richard Gabriel and William Clinger have
expressed their willingness and are arranging the support
necessary for them to take on the role of project editor for this
work. They are both well known in the Lisp community and
respected for their insight into Lisp issues and their writing
abilities.
It is the desire and intention of X3J13 to be as open and
communicative as possible with the ISO work. X3J13 will continue
to be very active in working toward a standard that serves the
needs of the US and Common Lisp communities. Relevant documents
(from whatever source) will be circulated to both X3J13 and the
ISO working group.
Remember that this letter, a copy of the ballot, a summary of the
voting, and any comments you submit will be forwarded as a
package to X3 for their consideration (and to the X3J13 mailing
list as well of course). Even though I have tried to be objective
in these summaries, some of you may want to comment on any part
of my letter, the ballot issues, or the position X3 should take.
Such comments are part of the public standards process. I also
want to remind you that you may want to directly contact the X3
member from your company or organization.
If you have any questions about your responsibilities and/or
rights related to this ballot or if any of the issues are still
unclear, please contact me at Mathis@Ada20.isi.edu or (703)425-
5923.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
X3J13 Ballot on
Proposed NWI on Programming Language LISP (TC97 N 1929)
Deadline: Noon July 28, 1987 to Bob Mathis
(electronic response possible see p. 4)
Question 1: X3J13 recommends to X3 a "YES" vote on the "Proposed
NWI on Programming Language LISP (TC97 N 1929)"
YES NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 2: X3J13 recommends to X3 a "YES" vote that the proposal
in TC97 N 1929 is a sufficient definition of the new work item.
YES NO (for the reasons stated in X3J13/87-030's summary
of the issues and discussions)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
Question 3: X3J13 recommends that the "Proposed Comments" on
page 3 of X3J13/87-030 be attached as formal comments with the
US response to ISO/TC97 on this Proposed NWI. (An X3 vote of "NO"
to the sufficiency of definition will require that comments be
provided to TC97, but you may suggest ones other than those in
X3J13/87-030.)
YES NO (because YES votes on the previous two questions
will need no comments)
NO (comments are required and they will be forwarded
along with the summary of this ballot to X3)
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu "Iteration" activity
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:01 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05324; Fri, 17 Jul 87 12:30:44 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00277; Fri, 17 Jul 87 12:34:45 PDT
Date: Fri, 17 Jul 87 12:34:45 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171934.AA00277@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: "Iteration" activity
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
The large LOOP document I informally passed out at the Boston meeting
is a "reference" manual, and as such was intended for scrutiny by those
who are already are MIT-style LOOP lovers. Unfortunately, it seems to
be too much to digest for the novice, so I've prepared a 1-page "Blurb"
and a 1-page "Crib Sheet" to assist the kind of person who doesn't want
to be a LOOP wizard, but may want to have a working knowledge of it
[e.g., to read other people's code, or just to understand this common
but not universal iteration paradigm].
I would like to put this short document formally before the committee
as a readable report on the syntax and semantics of the MIT-style LOOP.
The next message from me to X3J13 will be three pages which are the text
of a "Blurb" (short, working-knowledge overview), a "Crib Sheet" (BNF
syntax with examples for most usages), and a set of two larger examples.
These three pages would be "hardcopied" by printing the "Blurb" in two
columns, 72 lines per column, landscape orientation, on one side of a
sheet, with the "Crib Sheet" similarly printed on the other side. The
"LOOP Examples" page may be viewed as a pop quiz, to see if you can
actually read production-level LOOP code.
Other iteration committee members have indicated they would submit some
additional material for X3J13 consideration, but time constraints seem to
have postponed them [e.g., Chris Perdue wanted to describe an Alphard-
style system, and Pavel Curtis had some ideas on changing or extending
the "collector" syntax of the MIT-style LOOP]. There is also some
question about whether or not to put the LETS reference manual and
code into the X3J13 arena; its size is comparable to that of LOOP, and
as yet we don't have any serious advocates for it on the committee.
-- JonL --
∂21-Jul-87 1253 edsel!bhopal!jonl@labrea.stanford.edu LOOP "Blurb & Crib Sheet"
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:32:15 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:27:58 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05329; Fri, 17 Jul 87 12:32:41 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00290; Fri, 17 Jul 87 12:36:46 PDT
Date: Fri, 17 Jul 87 12:36:46 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171936.AA00290@bhopal.edsel.uucp>
To: labrea!x3j13%SAIL@labrea.stanford.edu
Subject: LOOP "Blurb & Crib Sheet"
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
LOOP Iteration Macro BLURB
WHAT IT IS:
LOOP syntax is an extension of the Common Lisp LOOP macro (CLtL, p 121), and
is expanded into other simpler Common Lisp primitives; the LOOP facility may
thus be thought of as a parser (or as a compiler) into more primitve lisp.
Parsing is controlled by Loop token words, which are simply symbols like FOR,
UNTIL, MAXIMIZE etc. A list of the more common Loop token words, along with
their syntax of usage, appears in the attached "CRIB SHEET".
HOW TO PARSE (and "READ") LOOP CLAUSES:
Each syntactic part of a LOOP construct is called a "clause," whose scope
is determined by the top-level parsing of the Loop token words. This
example contains a few of the possible clauses, to be explained below:
(LOOP FOR i FROM 1 TO (compute-top-value) ;first clause
WHILE (not (unacceptablep i)) ;second clause
COLLECT (square i) ;third clause
DO (format t "Working on ~D now" i) ;fourth clause
WHEN (evenp i) ;fifth clause
DO (format t "~D is a non-odd number" i)
FINALLY (format t "About to exit!!")) ;sixth clause
FROM and TO are also Loop token words, but they are auxiliaries to the FOR
clause. Just how many forms comprise a clause depends on the Loop token
word that starts the clause and on the auxiliary tokens connected with it.
ORDER OF EXECUTION:
Except as noted below, clauses are executed in the same order as they appear
in source code, just as if they were inside one big PROGN. This is repeated
over and over until some clause causes termination, or until a Lisp RETURN,
GO, or THROW, is executed. The exceptions to "linear order" are:
-- Variable initializations are all done first, regardless of where in
the loop body the clause that established the variable is located.
-- The INITIALLY clause (if any) is executed once, before cycling
through the rest of the code.
-- The FINALLY clause (if any) is executed once, before exiting, except
when the code is exited by a Common Lisp GO, RETURN, or THROW.
(Another exception is THEREIS/ALWAYS/NEVER clauses; see the Loop
reference manual for details).
-- Clauses labeled "Iteration Control" (such as FOR i from 1 to 10 ...)
implicitly cause:
+ a variable initialization to be done "initially";
+ a variable "stepping" to be done, generally, between
each execution of the PROGN-like loop body; and
+ a termination test to be performed, generally, just
before the execution of the loop body.
KINDS OF LOOP CLAUSES:
Clauses turn into Lisp code that falls into one of several categories:
** Variable initializating and possibly incrementing:
-- FOR (and its synonym AS) establish a variable to be initialized.
These are called "Iteration control" clauses, and are further
distinguished by auxiliary tokens such as IN, BY, FROM, etc.
FOR/AS clauses also produce code to re-initialize the variable
each time around the loop. When used with the auxiliary "=",
the same form used for the first initialization code is used for
the re-initialization code. With any auxiliary like FROM, UPTO,
DOWN, etc. the re-initialization is a numerical increment by INCF
(or by DECF) defaulting to 1, but changeable by auxiliary BY.
-- Multiple FOR/AS clauses may be combined either serially or
sequentially with the token AND (This is an advanced topic --
see the Loop reference manual for details.)
-- WITH is basically equivalent to a single LET clause. Multiple
WITH clauses may be combined either serially or sequentially
using the token AND (see the Loop reference manual for details).
** Value accumulation
-- COLLECT takes just one form in its clause, and tacks the value
of that form onto the end of a list of values to be returned
when the loop finishes.
-- APPEND is like collect except the value is considered to be
a list of zero or more individual values to be tacked on.
-- SUM takes just one form in its clause, which must evaluate to a
number; the sum of the numbers is returned when the loop finishes.
-- COUNT takes just one form in its clause, and counts the times it
evaluates to non-nil; the count is returned when the loop finishes.
-- MINIMIZE takes just one form in its clause, and keeps track of the
minimum value attained by evaluating that form; this minimum value
is returned when the loop finishes.
-- MAXIMIZE (similar to MINIMIZE).
-- THEREIS, explained below, will cause the non-null value of its
termination predicate to be returned; **however** termination
may occur due to some other clause, in which case the THEREIS
clause does not affect anything.
-- <...>ING -- most of these token words can also be suffixed with ING
** Termination conditions
-- (LOOP-FINISH) is a macro (rather than a token word or clause)
essentially equivalent to a RETURN out of the loop. However,
an accumulated value (if any) is returned instead of nil, and a
FINALLY clause (if any) is also executed.
-- FOR/AS clauses contribute a termination test determined by
the nature of the "Iteration control"
-- WHILE takes just one form, <condition>, in its clause and is
equivalent to the code: (if (not <condition>) (loop-finish)).
-- UNTIL is an inverse of WHILE: (if <condition> (loop-finish)).
-- THEREIS, like UNTIL, takes just one form in its clause, and causes
termination whenever that form evaluates to non-nil; unlike UNTIL,
it does not call (LOOP-FINISH), but directly returns the non-null
value from its form.
-- ALWAYS is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "false" (i.e., nil).
-- NEVER is like WHILE, but directly returns NIL whenever its
<condition> form evaluates to "true" (i.e., non-nil).
** Unconditional execution
-- DO clauses include all forms up to the next Loop token word;
they are all executed each time around the loop body.
-- DOING is a synonym for DO.
** Conditionals
-- IF clauses take one form as a predicate, and a subsequent value
accumulation clause (or DO or nested conditional clause) that
is executed during the loop body phase if the predicate is true.
-- WHEN is a synonym for IF.
-- UNLESS is like WHEN, but complements the predicate.
-- an ELSE clause is an optional component of an IF, WHEN, or UNLESS
clause, and is executed when the predicate is false.
KINDS OF ITERATION CONTROLS
** Iterating over integers, including or not including the endpoint:
(loop for i from 1 to 10 do ...) ;range includes 1, 2, ... and 10
(loop for i from 1 below 10 do ...) ; includes 1, 2, ... but not 10
(loop for i upto 10 do ...) ; includes 0 (default) ... and 10
(loop for i from 10 above 1 do ...) ; includes 10, 9 , 8 ... but not 1
(loop for i below 10 do ...) ; includes 0 (default) ... not 10
** Iterating over lists
(loop for item in baz-list do ...) ;somewhat like dolist
(loop for tail on baz-list do ...) ;somewhat like maplist
(loop for item in baz-list by #'cddr do ...) ;skips alternate items
** Iterating over Common Lisp sequences (access via ELT):
(loop for a being the elements of <some-sequence> ...)
** Repeated setting of variable to same evaluation:
(loop for x = (read-char) until (funny-char-p x) do (process-char x))
** Value on first time computed differently than on subsequent iterations:
(loop for x = #\( then (read-char) ...)
;; First time, x is set to #\(; subsequent times it calls read-char.
DESTRUCTURING and TYPE DECLARATIONS
A list may be used whereever a variable is called for, and the value for
that "variable" will be "destructured" (see CLtL, p146). Variables may
be followed by optional type specifiers, which are limited to FIXNUM
INTEGER, NUMBER, NOTYPE, T and the floating-point types. These are
considered advanced topics; see the Loop reference manual for details.
!
LOOP Iteration Macro CRIB SHEET
Below is an abbreviated list of the more commonly used LOOP syntax tokens
(sometimes called "Loop Keywords"); a BNF description of the legal format
is given, along with an example for each one.
Iteration Control
------------------------------------------------------------------------------
FOR <var> [{FROM | DOWNFROM | UPFROM} <expr1>]
[{TO | DOWNTO | UPTO | BELOW | ABOVE} <expr2]
[BY <expr3>]
(loop for i integer from 0 to 10 by 2
do (format t "~A" i)) ==> 0 2 4 6 8 10
(loop for i downfrom 6 above 0
do (format t "~A" i)) ==> 6 5 4 3 2 1
FOR <var> IN <expr1> [BY <step-function>]
(loop for i in '(1 2 3) sum i) ==> 6
FOR <var> ON <expr1> [BY <step-function>]
(loop for (i) on '(1 2 3) sum i) ==> 6
FOR <var> FIRST <expr1> THEN <expr2>
FOR <var> = <expr1> [THEN <expr2>]
(loop for i first 2 then (* i i)
until (> i 500)
collect i) ==> (2 4 16 256)
(loop for i = (read-char)
until (eql i #\newline)
collect i) ==> (#\a #\b ...)
FOR <var> BEING EACH ELEMENT OF <sequence>
FOR <var> BEING THE ELEMENTS OF <sequence>
(loop for dollars being each element of #(2 9 4 6)
sum dollars) ==> 21
(loop for char being the elements of (the simple-string "abcd")
collect char) ==> (#\a #\b #\c #\d)
AS is a synonym for FOR
REPEAT
(loop repeat 3 (print "What I say three times it true"))
==> "What I say three times it true"
"What I say three times it true"
"What I say three times it true"
End-Test Control
------------------------------------------------------------------------------
THEREIS <predicate>
(loop for i upfrom 0 thereis (and (> i 10) i)) ==> 11
ALWAYS and NEVER are similar to THEREIS:
(loop for i from 0 to 10 by 3 always (< i 10)) ==> T
(loop for i from 0 to 9 by 3 always (< i 9)) ==> NIL
(loop for i from 0 to 10 never (> i 11)) ==> T
LOOP-FINISH
(loop for i from 1 to 10
do (format t "~A " i)
(loop-finish)) ==> 1
WHILE <predicate>
UNTIL <predicate>
(loop while (hungry-p) do (eat))
(loop until (not (hungry-p)) do (eat))
Value Accumulation
------------------------------------------------------------------------------
COLLECT <item> [INTO <var>]
(loop for i from 1 to 5 collect i) ==> (1 2 3 4 5)
APPEND <list> [INTO <var>]
(loop for i in '((a) (b) ((c) d)) append i) ==> (A B (C) D)
NCONC is similar to append, but uses NCONC function rather than APPEND.
SUM <number> [INTO <var>]
(loop for i in '(1 2 3 4 5)
sum i into lots
finally (return (list lots lots))) ==> (15 15)
COUNT <form> [INTO <var>]
(loop for i in '(a 2 nil c t "x") count i) ==> 5
;; Remember -- nil is not counted
MAXIMIZE <expr> [INTO <var>]
MINIMIZE <expr> [INTO <var>]
(loop for i in '(2 1 5 3 4)
maximize i into moby
finally (cogitate-upon moby)) ==> NIL
;; No automatic return value, bug 'cogitate-upon'
;; is called with value 5 in the finally clause.
Binding Variables
------------------------------------------------------------------------------
WITH <var> [= <initial-value>]
(loop with x = 10
for i from 1 to 3
do (format t "~A " x)) ==> 10 10 10
Conditional Execution
------------------------------------------------------------------------------
<c-clause> ::=
{ DO <form>+ | {COLLECT <item> | APPEND <list> | SUM <number> | etc.} }
IF <predicate> <c-clause> [ELSE <c-clause>]
WHEN <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10
if (< i 5)
do (format t "~A " i)
else
do (format t "*")) ==> 1 2 3 4 *****
UNLESS <predicate> <c-clause> [ELSE <c-clause>]
(loop for i from 1 to 10 unless (< i 5) count i) ==> 6
Unconditional Execution
------------------------------------------------------------------------------
DO <form>+
(loop for i from 16 to 18
do (format t "~D " i)
(format t "~X " i)) ==> 16 10 17 11 18 12
Initial and Final Evaluation
------------------------------------------------------------------------------
INITIALLY <form>
(loop initially (format t "++ ")
for i from 1 to 5
do (format t "~A " i)) ==> ++ 1 2 3 4 5
FINALLY <form>
(loop finally (format t "++")
for i from 1 to 5
do (format t "~A " i)) ==> 1 2 3 4 5 ++
!
LOOP EXAMPLES
Since the LOOP facility is implemented as an ordinary Common Lisp macro,
it is often instructive to call MACROEXPAND-1 on a LOOP expression to
see how it gets translated into "vanilla" code. In the example below,
the goal of the loop is to find the tail of '*temporary-code*' just before
the cell that contains a suitable code-vector; this cell will subsequently
be "spliced" out of the *temporary-code* list.
(macroexpand-1 '(loop initially (setq temp-cell *temporary-code*)
while (not (null (rest temp-cell)))
thereis (<=& len (code-length (second temp-cell)))
do (pop temp-cell)))
==>
(let ((#:it1 nil))
(block nil
(tagbody
(setq temp-cell *temporary-code*)
loop::begin-loop
(unless (not (null (rest temp-cell)))
(loop-finish))
(when (setq #:it1 (<=& len (code-length (second temp-cell))))
(return #:it1))
(pop temp-cell)
(go loop::begin-loop)
loop::end-loop)))
Here is another realistic, complex example taken from one version of the
Lucid debugging module. Notice how the essential control parts of the loop
structure are highlighted by being at "top level":
-- there are few (if any) hidden exits from the loop.
-- Numerical "stepping" is invoked by a very succinct, stylized syntax
reminiscent of mathematical notation, rather than the cumbersome,
and distributed, code parts for Common Lisp DO.
-- "stepping" that doesn't fit into the provided formats can be
modeled by a three-line sequence of WITH/DO/WHILE clauses.
(loop for i upfrom (- frames-to-skip) ;'i' < 0 while skipping; and
below (or limit infinity) ; maybe there's no limit?
with fp = first-fp ;'fp' will chain through
do (setq fp (next-valid-fp ; the sequence of valid
fp ; stack frame pointers.
stack-bottom
report-problems))
while fp ;End of stack? if so, exit now
when (and table-length ;Make sure frame fits
(>= i table-length))
do (format *error-output* ;foo
"Error collecting stack frames")
(loop-finish)
when (and (>= i 0) ;Not skipping
frame-environment) ;Want frame recorded?
do (setf (stack-frame-fp i frame-environment)
fp)
finally (return ;Return # of non-skipped frames
;;I points to the first unused slot in all exit cases,
;;so I is the number of frames stored (or counted)
(max i 0)) ;But never negative
)
∂22-Jul-87 0741 FAHLMAN@C.CS.CMU.EDU Iteration proposals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 07:41:25 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 22 Jul 87 10:36:19-EDT
Date: Wed, 22 Jul 1987 10:36 EDT
Message-ID: <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SAIL.STANFORD.EDU
Subject: Iteration proposals
I have a few comments on Loop and the other iteration proposals, but I
assume that this is not the proper forum for detailed discussions,
especially of a preliminary nature. Is the iteration subcommittee now
active, with an internal communication channel for this stuff?
-- Scott
∂23-Jul-87 0944 edsel!bhopal!jonl@labrea.stanford.edu Iteration proposals
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 09:44:42 PDT
Received: by labrea.stanford.edu; Thu, 23 Jul 87 09:40:32 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA01235; Wed, 22 Jul 87 19:49:39 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03169; Wed, 22 Jul 87 19:49:57 PDT
Date: Wed, 22 Jul 87 19:49:57 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707230249.AA03169@bhopal.edsel.uucp>
To: labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!x3j13%sail@labrea.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 22 Jul 1987 10:36 EDT <FAHLMAN.12320403233.BABYL@C.CS.CMU.EDU>
Subject: Iteration proposals
At the Palo Alto X3J13 meeting in mid-March, Chris Perdue offered to set up a
mail redistribution list for the iteration sub-committee, at Sun. After a
few false starts, I think some mail successfully was forwarded through
"sun!clam!loop-groop"; but about mid-May, several of the committee members
fell into the proverbial black hole of "other committments", and there
haven't been any mailings through that channel since then.
None of the iteration committe members were present at the Boston meeting
except myself (and you weren't there either?); so we didn't even have our
face-to-face meeting, as planned. For the time being, I guess individual
contact is still the only active channel; the addresses, as last I knew
them, were:
edsel!jonl@labrea.stanford.edu (Jon L White)
DLW@SCRC.Symbolics.COM (Dan Weinreb)
cperdue@sun.COM (Chris Perdue)
Pavel.pa@Xerox.COM (Pavel Curtis)
GSB@mc.lcs.mit.edu (Glenn Burke)
-- JonL --
∂14-Aug-87 0803 @HAL.CAD.MCC.COM:Loeffler@MCC.COM Windows Subcommittee
Received: from [128.62.1.126] by SAIL.STANFORD.EDU with TCP; 14 Aug 87 08:00:52 PDT
Date: Fri, 14 Aug 87 09:42 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Windows Subcommittee
To: X3j13@sail.stanford.edu
cc: Loeffler@MCC.COM
Message-ID: <870814094226.6.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
What is the current status of the windows committee? I have two people
here at MCC that would like to participate.
-- David D. Loeffler
∂15-Sep-87 0424 MATHIS@ADA20.ISI.EDU report on ISO NWI and SC22 meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 04:24:36 PDT
Date: 14 Sep 1987 19:53-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: report on ISO NWI and SC22 meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]14-Sep-87 19:53:33.MATHIS>
At our meeting in Boston in July, the proposed New Work Item for an
international standard for Lisp was discussed. After a mail ballot of the
membership, it was decided (and subsequently endorsed by X3, the parent
committee of X3J13 and the organization responsible for the final US vote on
this issue) to forward the following comments with our ballot:
In the US there is a very strong feeling that "Lisp" is the
name of a family of languages and that it is appropriate to
standardize only on a particular dialect and that the name
of this dialect must be part of the name of the standard. A
name like "ISO Lisp 89" would be too broad and would not
answer the concerns expressed here. Within the Lisp family,
there have existed many popular dialects with fundamental
differences in their design, implementation, and use. While
some of these existing differences may be resolved, others
will certainly appear since the Lisp family encourages such
experimentation and development.
The US concern about the name for the resulting ISO standard
and the wording of this proposed new work item is not a
shallow comment about words only, but is an indication of
our deep concern that the goals and objectives of developing
a standard within the Lisp family should not interfere with
continued developments in other parts of the Lisp family of
languages. This is one of the first issues that must be
considered by an ISO working group resulting from the
approval of this new work item. This naming issue was also
raised as part of the report of the SC22 ad hoc working
group (ISO/TC97/SC22 N 266) that lead to this NWI proposal.
The US feels that report should be one of the initial
documents of the working group resulting from this NWI
proposal and that the various issues it raises be addressed.
Other countries have also submitted comments -- France offered a Convenor,
Japan thought there should be more emphasis on Common Lisp, and the United
Kingdom emphasized the need for a single standard.
ISO/IEC JTC1/SC22 (the SubCommittee on Languages of Joint Technical Committee
1 of the International Organization for Standardization and the International
Electrotechnical Commission) decided to form Working Group 16 on Lisp.
Christian Queinnic was named Convenor and Richard Gabriel and William Klinger
were named as project editors.
At that same meeting there was considerable discussion about the handling of
large character sets in programming languages. While this issue is frequently
thought of in terms of handling Japanese and Chinese, it is also important for
European languages other than English and for modern text manipulation
systems.
The first meeting of WG 16 will be held February 24 and 25, 1988, in Paris,
France. There will be an International Workshop on Lisp Evolution and
Standardization on February 22 and 23, also in Paris. Participation in the
Workshop is separate from participation in the ISO/IEC Working Group.
∂15-Sep-87 0929 dcm%hpfclp@hplabs.HP.COM October X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 87 09:28:34 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Tue, 15 Sep 87 10:27:15 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Tue, 15 Sep 87 10:27:41 mdt
Return-Path: <dcm@hpfcdcm>
Message-Id: <8709151627.AA15748@hpfcdcm.HP.COM>
To: x3j13@sail.stanford.edu
Cc: mathix@ada20.isi.edu
Subject: October X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Tue, 15 Sep 87 10:27:37 MST
Sender: dcm%hpfclp@hplabs.HP.COM
X3J13 Meeting
10/20/87 - 10/21/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday,
October 19-21 at the University Park Holiday Inn in Fort Collins,
Colorado. Monday has been set aside for committee meetings, followed
by the main meeting on Tuesday and Wednesday. October is the perfect
time to see fall (and sometimes winter) in Colorado. Rocky Mountain
National Park is approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated
discount airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your
room, rental car, or airport limousine reservations through Lifeco at
the same time. Payment must be made by credit card. Tickets will be
mailed via registered mail. Late reservations can be express mailed
at additional cost.
A block of rooms is available at the University Park Holiday Inn at
$46.50 plus tax per night. If you don't make reservations through
Lifeco Travel, please make your own reservations by calling
(303)482-2626 and asking to reserve a room in the "HP X3J13" block.
Reservations will be held until 6 PM unless guaranteed by a major
credit card. Non-smoking rooms are available. Check-in and check-out
times are 1 PM. The block of rooms will be dropped on 10/2/87, but
you should still be able to obtain the discounted room rate on
available rooms if you specify you are attending the the "HP X3J13"
conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday.
I expect these arrangements will run $50 or less per person which I
will collect at the meeting. I should be able to update this value in
a few weeks. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner
Tuesday evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate
cafe offering some the best and most unusual food in Northern
Colorado. It is a very small cafe which can only accommodate 60 total
patrons, but they are willing to put together a special banquet for
us. To handle a group this large in a short period of time they would
like to limit the menu to 4 items. The list of possible entrees
includes: Cajun roast duckling with spice peach gravy, chicken boursin
(double breast of chicken stuffed with herbed cream cheese dressing
and mushroom voloute' sauce), shrimp diane (sauteed jumbo shrimp in a
garlic cajun sauce), sirloin tips with mushrooms and onions, poached
salmon with a special sauce, or boned leg of lamb stuffed with spinach
and served with a dijon sauce. A vegetarian entree will also be
available. Entrees would be about 15 dollars, including soup or
salad. Appetizers, dessert, and beverage would be ala carte.
Cuisine, Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in
advance so they could make the necessary preparations. Note if you
are interested on the registration form and mark your first and second
choice entrees. Please note any dietary restrictions if this
selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to
I-25 and go north on I-25 towards Cheyenne, Wyoming. Take the first
Fort Collins exit, #265, turn left and drive 5 miles to the College
Avenue intersection. Turn right and drive 3 miles to the Prospect
Road intersection. Turn left and the Holiday Inn is just across the
railroad tracks on the south side of the road. It shouldn't be hard
to see since it is 8 stories tall in an area with very few building
over 2 stories.
Two limousine services provide shuttle service from Stapleton directly
to the Holiday Inn. Fort Collins Express (303-482-0505) leaves
Stapleton on the hour while the Front Range Airporter (303-221-5466)
leaves Stapleton on the half hour. Both are located in the baggage
claim area. The charge is $12 each way on the Express and $13 on the
Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by October 5 via
electronic mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions
__________________________________________________________________________
X3J13 OCTOBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 10/20 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂16-Sep-87 1145 dcm%hpfclp@hplabs.HP.COM November X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 87 11:45:10 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 16 Sep 87 12:43:25 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 16 Sep 87 12:43:23 mdt
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 16 Sep 87 12:43:19 MST
Message-Id: <1297.558816199@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Bob Mathis requested that I delay the meeting a month so the subcommittees
will have more time to prepare their reports. I have rescheduled the
meeting a month later, November 16-18, which seemed to be the most
desirable dates in November. Other than the date changes there are no
other changes in the arrangements.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 or less per person which I will
collect at the meeting. I should be able to update this value in a few
weeks. Please note any dietary restrictions so I can make the necessary
arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)339-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Sep 87 03:12:38 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa25268; 24 Sep 87 6:13 EDT
Received: from utokyo-relay by RELAY.CS.NET id ay09298; 24 Sep 87 6:00 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA23717; Thu, 24 Sep 87 17:39:32 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA00464; Thu, 24 Sep 87 17:14:20 jst
Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Thu, 24 Sep 87 15:58:47 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA16011; Thu, 24 Sep 87 14:50:53 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
id AA01964; Thu, 24 Sep 87 14:37:43 JST
Date: Thu, 24 Sep 87 14:37:43 JST
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8709240537.AA01964@kurims.kurims.kyoto-u.junet>
To: x3j13@SAIL.STANFORD.EDU
Subject: Japanese Activities toward Lisp Standardization
Japanese Activities toward Lisp Standardization
The demand for Lisp standardization has been growing rapidly in Japanese
computer industries and academic organizations. AIST (Agency of Industrial
Science and Technology), which is responsible for Japan Industrial Standards
(JIS in short), has initiated its activity toward JIS Lisp standardization.
In April 1986, in response to the request from AIST, a working group for Lisp
standardization was formed at JEIDA (Japan Electronic Industry Development
Association). After one year's preliminary discussions, the following
committee "JEIDA Committee for Lisp Standardization" was formed and its
active efforts have begun in June 1987. The aim of this committee is to
develop a Lisp language specification suitable for JIS standard in cooperation
with ISO and the organizations for Lisp standardization in other countries.
JEIDA Committee for Lisp Standardization
----------------------------------------
Chairman:
Takayasu Ito (Tohoku University)
Secretaries:
Tsuneo Furuyama (NTT: Nippon Telegraph and Telephone Corp.)
Fumio Motoyoshi (ETL: Electrotechnical Laboratory)
Taiichi Yuasa (Kyoto University)
Members from Major Computer Companies:
Fujitsu Ltd.
Hitachi Ltd.
IBM Japan Ltd.
Mitsubishi Electric Corp.
NEC Corp.
Oki Electric Industry Co. Ltd.
Toshiba Corp.
Observers:
Masayuki Ida (Aoyama Gakuin University)
Tetsuo Ida (The Institute of Physical and Chemical Research)
Ryo Kamito (AIST)
Masakazu Nakanishi (Keio University)
Takehisa Nireki (JEIDA)
Kentaro Shimizu (University of Tokyo)
Technical issues for Lisp standardization will be discussed by the subsidiary
working group "JEIDA Technical Working Group for Lisp Standardization", or
TG/A in short. This group started technical discussions soon after it was
formed in August 1987. It has been agreed that Common Lisp is a good starting
point for technical discussions. But various technical deficiencies of Common
Lisp have been already pointed out at TG/A. The role of TG/A is to clear up
major technical issues for Lisp standardization, continuing detailed technical
examinations on Common Lisp and other Lisp dialects.
JEIDA Technical Working Group for Lisp Standardization
------------------------------------------------------
Chairman:
Taiichi Yuasa (Research Institute for Mathematical Sciences,
Kyoto University)
Members:
Takashi Chikayama (ICOT)
Etsuya Shibayama (Dept. of Information Science,
Tokyo Institute of Technology)
Kentaro Shimizu (Dept. of Information Science, University of Tokyo)
Akikazu Takeuchi (Central Research Lab., Mitsubishi Electric Corp.)
Kyoji Umemura (NTT Software Lab., NTT)
Advisors:
Toshiaki Kurokawa (Tokyo Research Lab., IBM Japan Ltd.)
Michiaki Yasumura (Central Research Lab., Hitachi Ltd.)
Anyone interested in Japanese activities for Lisp standardization should
contact:
Professor Takayasu Ito
Department of Information Engineering
School of Engineering
Tohoku University
Sendai 980, Japan
Junet: chairlsp@nttlab.ntt.junet
or
Dr. Taiichi Yuasa
Research Institute for Mathematical Sciences
Kyoto University
Kyoto 606, Japan
Junet: yuasa@kurims.kurims.kyoto-u.junet
∂20-Oct-87 1636 @RELAY.CS.NET:DUSSUD@jenner.csc.ti.com Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Oct 87 16:36:09 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae00813; 20 Oct 87 18:19 EDT
Received: from csl.ti.com by RELAY.CS.NET id ah15609; 20 Oct 87 18:17 EDT
Received: from Jenner by tilde id AA13643; Tue, 20 Oct 87 16:18:06 CDT
Message-Id: <2770752076-11152612@Jenner>
Date: Tue, 20 Oct 87 16:21:16 CDT
From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
To: dcm%hpfclp@hplabs.hp.com
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: November X3J13 meeting
In-Reply-To: Msg of Wed, 16 Sep 87 15:39:35 cdt from tilde::@relay.cs.net, @sail.stanford.edu:dcm%hpfclp@hplabs.hp.com
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: Patrick Dussud
Institution: Texas Instruments Austin.
Street Address: 12501 research Blvd
City, State, Zip: Austin TX 78759
Phone: (512) 250-7483
Network Address: Dussud%jenner%ti-csl.csnet
Dinner 11/17 (y/n): N__________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂22-Oct-87 0839 ROSENKING@A.ISI.EDU Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 08:39:11 PDT
Date: 22 Oct 1987 11:36-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: November Meeting
From: ROSENKING@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]22-Oct-87 11:36:22.ROSENKING>
To all those planning to attend the November meeting:
If anyone is interested in indulging in some pre-meeting skiing, on
Saturday and Sunday (Nov. 14-15) at Breckenridge or Keystone mountains
in Colorado, drop me some mail. I am gathering accomodation and prime
ski condtion information at this time and I plan on making reservations
shortly.
All are welcome ! Lisp experience is a plus, though not for skiing ?!
- Jeff Rosenking
∂26-Oct-87 0522 MATHIS@C.ISI.EDU next meeting
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 05:21:58 PST
Date: 26 Oct 1987 05:21-PST
Sender: MATHIS@C.ISI.EDU
Subject: next meeting
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 05:21:15.MATHIS>
I hope you are all making your reservations for the next meeting,
Nov 16-18, in Colorado.
Messages about this were sent out to this list some time ago and
in the mail just recently.
Monday afternoon is for subcommittee meetings -- people who are
planning such should either respond to me directly or announce
them on this list.
Tuesday we will start about 9am.
Wednesday I would like to leave Denver about 7pm. That means the
meeting can run until 5pm. I expect that people will be staying
for the full afternoon. If a four o'clock ending time would
help, let me know so others can plan on it too.
As to the agenda -- I expect some discussion about windows on
Tuesday; some discussion about the Lisp1/Lisp2 issue; some
discussion about planning for the international work; more on
CLOS; and an extensive report from the clean-up committee (they
have been busy, but won't have their report mailed around in
advance). There are also other committees that will be
reporting.
If you have any suggestions for agenda organization, please let
me know. I will try to put out a more complete version by the
end of the week (if you get back to me).
Thanks, Bob
∂26-Oct-87 1233 MATHIS@C.ISI.EDU Wednesday afternoon agenda
Received: from C.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 12:33:31 PST
Date: 26 Oct 1987 12:32-PST
Sender: MATHIS@C.ISI.EDU
Subject: Wednesday afternoon agenda
From: MATHIS@C.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[C.ISI.EDU]26-Oct-87 12:32:47.MATHIS>
I have already gotten an indication from a few people that they
have to leave around 2pm or 3pm Wednesday afternoon. That's
fine. However, it might make sense to have the last item on the
Wednesday agenda be something that might be considered less
central to the overall work. Any suggestions?
Thanks, Bob
∂29-Oct-87 1212 X3J13-mailer November X3J13 meeting
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 12:12:47 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 29 Oct 87 12:08:43-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Thu, 29 Oct 87 12:10:07 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Thu, 29 Oct 87 12:58:33 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Thu, 29 Oct 87 12:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Thu, 29 Oct 87 12:57:30 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ada20.isi.edu, dcm%hpfcdcm@hplabs.HP.COM
Subject: November X3J13 meeting
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Thu, 29 Oct 87 12:57:27 MST
Message-Id: <5124.562535847@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
Last call for reservations and registrations. Please send me a
registration form in addition to making your reservations. I need to give
a tentative head count to the the hotel and the restaurant next Monday,
November 2, with final counts due the following Monday, November 9. So far
I've heard from the following people:
Kathy Chapman Digital Equipment Corporation
Walter van Roggen Digital Equipment Corporation
Dan Pierson Encore Computer Corporation
Sandra Loosemore Evans & Sutherland Computer Corp.
Steve Haflich Franz Inc.
Kevin Layer Franz Inc.
James Kempf Hewlett Packard Company
Dave Matthews Hewlett Packard Company
George Hadden Honeywell
Aaron Larson Honeywell
Thom Linden IBM
Mary Van Deusen IBM
Dick Gabriel Lucid, Inc.
JonL White Lucid, Inc.
Linda DeMichiel Lucid, Inc.
Christopher Dabrowski National Bureau of Standards
Chris Perdue Sun Microsystems
Sonya Keene Symbolics, Inc.
David Moon Symbolics, Inc.
David Bartley Texas Instruments
Patrick Dussud Texas Instruments
Daniel Bobrow Xerox Corporation
Pavel Curtis Xerox Corporation
Gregor Kiczales Xerox Corporation
Larry Masinter Xerox Corporation
The dinner selections thus far seem to favor duck, shrimp, chicken, and
lamb using a simple first choice heuristic.
First choice Second Choice
Shrimp XXXX XXXX
Lamb XXXX XXXXX
Sirloin XX XXXX
Duck XXXXX XX
Salmon XX XXXXX
Chicken XXX X
Veg. X
A few ski resorts have already opened, Jeff Rosenking is looking for other
skiers to join him on a trip the weekend before the meeting. Your ski
reservations, including lift tickets, can also be made through Lifeco
travel when you make your travel reservations.
There are some small board rooms available at the hotel if you would like
to use them Monday for committee meetings. Please let me know what times
you would like to reserve one so I can have one set aside for you.
By the way, I seem to have typoed my phone number in the last mailing. The
correct phone number is (303)229-2201.
Dave Matthews
--------------------------------------------------------------------------
X3J13 Meeting
11/16/87 - 11/18/87
Fort Collins, Colorado
The fifth meeting of X3J13 will be held Monday through Wednesday, November
16-18 at the University Park Holiday Inn in Fort Collins, Colorado. Monday
has been set aside for committee meetings, followed by the main meeting on
Tuesday and Wednesday. November is the perfect time to see fall (and
sometimes winter) in Colorado. Rocky Mountain National Park is
approximately one hour from Fort Collins.
Hewlett-Packard's travel affiliate, Lifeco Travel, has negotiated discount
airfares that you can obtain by calling:
800-521-8858 (in California)
800-722-8755 (elsewhere)
Ask to make a group reservation for X3J13. You may also make your room,
rental car, or airport limousine reservations through Lifeco at the same
time. Payment must be made by credit card. Tickets will be mailed via
registered mail. Late reservations can be express mailed at additional
cost.
A block of rooms is available at the University Park Holiday Inn at $46.50
plus tax per night. If you don't make reservations through Lifeco Travel,
please make your own reservations by calling (303)482-2626 and asking to
reserve a room in the "HP X3J13" block. Reservations will be held until 6
PM unless guaranteed by a major credit card. Non-smoking rooms are
available. Check-in and check-out times are 1 PM. The block of rooms will
be dropped on 11/2/87, but you should still be able to obtain the
discounted room rate on available rooms if you specify you are attending
the the "HP X3J13" conference.
Refreshments and lunch are being arranged for Tuesday and Wednesday. I
expect these arrangements will run $50 per person which I will collect at
the meeting. Please note any dietary restrictions so I can make the
necessary arrangements with the catering department.
If there is sufficient interest I would like to arrange a dinner Tuesday
evening at Cuisine, Cuisine. Cuisine, Cuisine is an intimate cafe offering
some the best and most unusual food in Northern Colorado. It is a very
small cafe which can only accommodate 60 total patrons, but they are
willing to put together a special banquet for us. To handle a group this
large in a short period of time they would like to limit the menu to 4
items. The list of possible entrees includes: Cajun roast duckling with
spice peach gravy, chicken boursin (double breast of chicken stuffed with
herbed cream cheese dressing and mushroom voloute' sauce), shrimp diane
(sauteed jumbo shrimp in a garlic cajun sauce), sirloin tips with mushrooms
and onions, poached salmon with a special sauce, or boned leg of lamb
stuffed with spinach and served with a dijon sauce. A vegetarian entree
will also be available. Entrees would be about 15 dollars, including soup
or salad. Appetizers, dessert, and beverage would be ala carte. Cuisine,
Cuisine accepts charge cards, but cash would also be welcome.
I would need to narrow this to the four items at least 2 weeks in advance
so they could make the necessary preparations. Note if you are interested
on the registration form and mark your first and second choice entrees.
Please note any dietary restrictions if this selection is not sufficient.
Fort Collins is approximately a one hour drive from Denver's Stapleton
International Airport. From the airport take I-270 or I-70 west to I-25
and go north on I-25 towards Cheyenne, Wyoming. Take the first Fort
Collins exit, #265, turn left and drive 5 miles to the College Avenue
intersection. Turn right and drive 3 miles to the Prospect Road
intersection. Turn left and the Holiday Inn is just across the railroad
tracks on the south side of the road. It shouldn't be hard to see since it
is 8 stories tall in an area with very few building over 2 stories.
Two limousine services provide shuttle service from Stapleton directly to
the Holiday Inn. Fort Collins Express (303-482-0505) leaves Stapleton on
the hour while the Front Range Airporter (303-221-5466) leaves Stapleton on
the half hour. Both are located in the baggage claim area. The charge is
$12 each way on the Express and $13 on the Airporter.
| Prospect Road ||
=========|====================== ||
HI | ||
M | ||
O | ||
U | ||
N | Drake Road North ||
T =========|====================== /\ ||
A | || ||
I |US 287/ College Avenue ||
N | ||I-25
S | ||
| Horsetooth Road ||
=========|====================== ||
| ||
| ||
| ||
| ||
| Harmony Road HP /||\
=========|=============================================||===========
| \||/ Exit 265
| ||
||
\/
Denver
Please return the following registration form by November 2 via electronic
mail to dcm%hpfclp@hplabs.hp.com or via US Mail to:
Dave Matthews
Hewlett-Packard Company
3404 E Harmony Road
Fort Collins, Colorado 80525
(303)229-2201
Feel free to contact me if you have any questions.
__________________________________________________________________________
X3J13 NOVEMBER MEETING REGISTRATION FORM
Name: __________________________________________________
Institution: __________________________________________________
Street Address: __________________________________________________
City, State, Zip: __________________________________________________
Phone: __________________________________________________
Network Address: __________________________________________________
Dinner 11/17 (y/n): __________________________________________________
First choice: __________________________________________________
Second choice: __________________________________________________
(Duck, chicken, shrimp, sirloin, salmon, lamb, vegetarian)
Dietary Restrictions: __________________________________________________
__________________________________________________
__________________________________________________
∂11-Nov-87 1800 X3J13-mailer Final reservations
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 17:13:02 PST
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 11 Nov 87 17:08:57-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 11 Nov 87 17:12:18 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 11 Nov 87 17:58:16 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 11 Nov 87 17:57:42 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 11 Nov 87 17:57:43 mst
Return-Path: <dcm@hpfcdcm>
To: x3j13@sail.stanford.edu
Cc: mathis@ADA20.ISI.EDU
Subject: Final reservations
From: Dave_Matthews%hpfclp@hplabs.HP.COM
X-Mailer: mh6.5
Date: Wed, 11 Nov 87 17:57:40 MST
Message-Id: <1830.563677060@hpfcdcm>
Sender: dcm%hpfclp@hplabs.HP.COM
I've scheduled two conference rooms for Monday afternoon for
subcommittee meetings - one for the cleanup committee and one for
the character committee. They will be available all afternoon.
This is the latest list of registrants and dinner guests that I
have. If you aren't listed, such as Bob Mathis, and plan to
attend, please give me a call.
I've eliminated the chicken and salmon as a result of low demand
and added a new dinner choice column to the list of registrants.
Please call me if you have ????? for your dinner selection as you
will need to choose something else.
If you have any questions or need additional help call me and
leave a detailed message if I'm not available. I'll try to get
back to you ASAP.
Dave Matthews
303-229-2201
Peter Coffee Aerospace Corporation -
Jim O'Dell Alliant Computer sirloin
Kathy Chapman Digital Equipment Corporation veg
Walter van Roggen Digital Equipment Corporation duck
Dan Pierson Encore Computer Corporation duck
Sandra Loosemore Evans & Sutherland Computer Corp. shrimp
Steve Haflich Franz Inc. ??????
Kevin Layer Franz Inc. sirloin
Richard Greenblat GigaMOS Systems, Inc. sirloin
Jeff Rosenking Grumman Corporation shrimp
Paul Beiser Hewlett Packard Company shrimp
James Kempf Hewlett Packard Company duck
Dave Matthews Hewlett Packard Company lamb
George Hadden Honeywell shrimp
Aaron Larson Honeywell shrimp
Thom Linden IBM shrimp
Mary Van Deusen IBM duck
Greg Nuyens ILOG S.A. duck
Jerome Chailloux INRIA/ILOG duck
Mary Boelk Johnson Controls, Inc. shrimp
Dick Gabriel Lucid, Inc. sirloin
JonL White Lucid, Inc. lamb
Jan Zubkoff Lucid, Inc. duck
Linda DeMichiel Lucid, Inc. lamb
David Loeffler MCC sirloin
Christopher Dabrowski National Bureau of Standards -
Eric Schoen Schlumberger Palo Alto Research -
Chris Perdue Sun Microsystems duck
Sonya Keene Symbolics, Inc. sirloin
Bob Kerns Symbolics, Inc. ??????
David Moon Symbolics, Inc. -
Kent Pitman Symbolics, Inc. duck
Will Clinger Tektronix Laboratories -
David Bartley Texas Instruments lamb
Patrick Dussud Texas Instruments -
Ellen Waldrum Texas Instruments shrimp
Guy Steele Thinking Machines Corporation shrimp
Thomas Turba Unisys Corp. shrimp
Julian Padget University of Bath duck
Jeff Dalton University of Edinburgh sirloin
Daniel Bobrow Xerox Corporation lamb
Pavel Curtis Xerox Corporation lamb
Andy Daniels Xerox Corporation lamb
Gregor Kiczales Xerox Corporation duck
Larry Masinter Xerox Corporation shrimp
∂12-Nov-87 1335 X3J13-mailer next meeting
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 13:34:57 PST
Date: 12 Nov 1987 16:18-EST
Sender: MATHIS@A.ISI.EDU
Subject: next meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]12-Nov-87 16:18:49.MATHIS>
I've talked to Dave Matthews. If there are any other remaining
reservations, please let him know.
The agenda will be committee reports and regular business on
Tuesday morning. Tuesday afternoon I think will be best spent on
more informal, but more in depth, discussions of the work of the
CLOS and clean-up committees. Wednesday will contain a
continuation of these discussions and also the formulation of a
ballot on clean-up issues (since they haven't been distributed in
advance we can't finalize the vote at the meeting, on the other
hand we may not be to the stage of having a formal mail ballot
either).
We also have to discuss our plans for a standard for Common Lisp
and our plans for the ISO work. There will also be reports from
the editorial, windows, characters, and other subcommittees.
The agenda is not full of a lot of little topics, but is oriented
toward reaching some general understanding of the issues
involved.
-- Bob
∂29-Nov-87 1424 X3J13-mailer subcommittees
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 29 Nov 87 14:24:00 PST
Date: 29 Nov 1987 17:22-EST
Sender: MATHIS@A.ISI.EDU
Subject: subcommittees
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]29-Nov-87 17:22:16.MATHIS>
here is my version of how the subcommittee evolved at the Ft. Collins
meeting. PLEASE send me any additions or other corrections.
If you have an electronic mailing list, please let me know and tell
me how people outside the subcommittee should be involved with that
list (if at all)
X3J13 Subcommittees (as of November 29, 1987
(Mathis, Steele, and Gabriel try to follow all)
Editorial:
Kathy Chapman, chair
Ron Ohlander
Mary Boelk
Dick Gabriel
Kent Pitman
Walter van Roggen
Skona Brittain
Character Subcommittee <cl-natural-languages
Thom Linden, chair (IBM Research)
Larry Masinter (XEROX Research)
Carl Hoffman (International Lisp Associates)
Bob Kerns (Symbolics)
Duncan Missimer (Hewlett-Packard)
Dave Matthews (Hewlett-Packard)
Mike Beckerle (Gold Hill)
Kevin Layer (Franz)
ISO/IEC JTC1/SC22/WG 16 Delegation:
Dick Gabriel, chair
Guy Steele
Bob Mathis
Patrick Dussud
Thom Linden
Larry Masinter
Will Clinger
Bill Scherlis
Kent Pitman
John McCarthy
Iteration
Jon L. White, chair
Pavel Curtis
Chris Purdue
Dan Weinreb
Errors and Conditions
Kent Pitman, chair
Andy Daniels
Validation and Conformance
--, chair
David Slater
Mike Beckerle
Chris Dambroski
Compiler Specification
Steve Haflich, chair
David Bartley
Mike Beckerle
Rob McLaughlin
Walter van Roggen
CLOS
Danny Bobrow, chair
David Moon
Dick Gabriel
Gregor Kiczales
Linda DeMichiel
Sonya Keene
Patrick Dussud
Jim Kempf
Lisp1/Lisp2
Dick Gabriel
Will Clinger
Kent Pitman
Mark Wegman
Richard Greenblat
Dan Weinreb
Macros
Mark Wegman
Julian Padget
Steve Haflich
Kent Pitman
Graphics and Windows
Erik Schoen, chair
George Haden
Ellen Waldrum
Types & Declarations
Bill Scherlis
Clean-up
Larry Masinter
Guy Steele
Kent Pitman
JonL White
Scott Fahlman
David Moon
Ellen Waldrum
Meeting Planning
Jan Zubkoff
∂02-Dec-87 1545 X3J13-mailer 11-87 minutes
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 15:44:53 PST
Received: by labrea.stanford.edu; Wed, 2 Dec 87 15:41:10 PST
Received: from sunvalleymall.lucid.com by edsel id AA11888g; Wed, 2 Dec 87 15:35:55 PST
Received: by sunvalleymall id AA08895g; Wed, 2 Dec 87 15:35:59 PST
Date: Wed, 2 Dec 87 15:35:59 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712022335.AA08895@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Subject: 11-87 minutes
Plans for March meeting to follow.
X3J13/87-038
Minutes
Ft. Collins, CO
11/17/87 - 11/18/87
Item 1: Call to Order, Bob Mathis
9:00 am - Tuesday, November 17, 1987. Ft. Collins meeting called to order.
Introductory remarks. Attendance list send around. Introduction of
attendees.
Item 4: Report on ISO Ballot (Doc: 87-031), Bob Mathis
Letter from Bob Mathis to Catherine Kachurick. Letter from Thomas Turba to
Bob Mathis. Letter from Catherine Kachurick to X3. Preliminary Draft of
ISO/IEC JTC 1 Information Technology Secretariat: USA (ANSI). Summary of
Voting Document. Proposed comments from US on the name for the resulting
ISO standard on LISP. Draft UK Position on LISP.
Item 2: Approval of Agenda, Bob Mathis
Proposed agenda (X3J13/87-037) approved with minor changes. No windows and
a shorter CLOS discussion.
Item 5: Other administrative matters, Bob Mathis
New document register is available. List of subcommittees (please send
Mathis changes of members and send electronic mailing address). X3 bills
have been sent out. Make checks for this meeting payable to Hewlett Packard
and give to Dave Matthews during break. Dinner will be at 6:30pm.
Item 8: Characters, Thom Linden Committee name and scope. Name change
Natural Language Committee to Character Committee. JEIDA acknowledgement
and interaction network. IBM proposal. Thom will have a detailed proposal
at the March meeting. Committee will discuss one topic at a time. Bob
Mathis will forward ISO character notes to Thom Linden.
Item 9: Iteration, JonL White
Work promised on MIT LOOP at Cambridge meeting has just begun. Discussion
on whether standard is needed for portable loops. Discussion on why loop
and do standards may be necessary for new programmers.
Item 10: Lisp1/Lisp2, Common Lisp and Scheme, Will Clinger
Discussion on denotational semantics. Should we dissolve the Lisp1/Lisp2
committee? Should we broaden the committee to look at semantics of the
entire language? We need to take a vote.
11:30am - Morning Break
Item 12: Reports from other subcommittees
Errors, Kent Pitman
No new revisions. Will send mail with questions posed since last meeting.
Will have proposal for approval at next meeting.
12:00 - Lunch
Item 11: Editorial, Kathy Chapman
Discussed whether spec should be CLtL with changes or start from scratch.
Presented idea of 2 manuals, one a formal spec and one a rationale manual.
We need to decide what the deadline for the manual is.
2:30 pm - Break
Item 12: Reports from other subcommittees
Macros, Julian Padget
Brief overview. Please send examples of hairy macros to Julian Padget. A
brief summary will be available at next meeting.
Item 12: Reports from other subcommittees
CLOS, Gregor Kiczales
Committee has filled in chapters 1 and 2. Chapter 3 will be decided in
December at a Meta Objects meeting in Boston. Changes include: loosened
lambda-list congruence rules, instance creation and initialization,
simplified with-slots, handling some exception conditions, and lexical
generic functions. Next revision will be available in February 1988.
Please send comments via net-mail by end of February so changes can be made
by the March meeting.
Item 12: Reports from other subcommittees
Validation, Bob Mathis
Rich Berman has left ISI. This leaves the validation committee unmanned.
Item 12: Reports from other subcommittees
Type and Declaration, Bob Mathis
Bill Scherlis was to report. Nothing has been reported.
4:15pm - Break
4:25pm - Bob Mathis proposed the agenda for Wednesday's meeting be 9:00 -
10:30 Cleanup Committee, wrapping up by lunch and have committee meetings
after lunch.
Item 14: Extended Discussion on CLOS and Clean-up, Larry Mascinter
General remarks and review issue status. Intent is writing for editor the
go-ahead on issues. Ran quickly through issues.
Item 15: Recess, 4:55pm
Item 16: Call to Order, November 18, 8:59am, Bob Mathis
Item 17: Further discussions on cleanup and drafting, Larry Mascinter
The following people contributed issues and discussions but are not on the
clean-up committee. We thank them for their participation.
Dan Carnese Schlumberger
Will Clinger Tektronics
Pavel Curtis Xerox
Steve Haflich Franz
Dieter Kolb Siemans
Sandra Loosemore E&S/Utah
Rob McLaughlin CMU
Jeff Peck SUN
Jonathan Rees MIT
Dave Touretzky CMU
Discussed "need volunteer" issues. Bob Mathis will mail a ballot on closed
topics from clean-up committee. JonL White proposed we bring forward old
issues and reject or adopt them. Larry Mascinter will provide a list.
AREF-1D no comments or objections
GET-SETF-METHOD-ENVIRONMENT no comments or objections
KEYWORD-ARGUMENT-NAME-PACKAGE no comments or objections
PATHNAME-STREAM some comments no objections
DO-SYMBOLS Jonl White suggested DO-PRESENT-SYMBOLS
and will send mail to Larry Masinter.
DECLARE-MACROS Goldhill objected on grounds of incompatible
changes. A long discussion ensued.
10:38am - Break
Item 17: Further discussions on cleanup and drafting, continued.
PATHNAME-SUBDIRECTORY-LIST
Item 22, 24: Planning Relative to Other Technical Issues,
Review Action Item Assignments, Bob Mathis
ISO letter. Committee chairman, people on committees, net names. A motion
was made to thank Lucid, Goldhill and Hewlet Packard. The motion was
approved and Bob Mathis will send thank you letters.
Item 23: Future Meetings, Bob Mathis
Discussion of length and format of future meetings. It was voted that we
would have a 5 day meeting in March 1988 and a tentative date was set for
March 21 through March 25. The first 2 days will be set aside for
subcommittee meetings, the next 2 days will be used for the meeting, and the
last day will be set aside for subcommittee meetings. A reminder that all
proposals should be in the hands of the committee 2 weeks prior to the
meeting. That means mailing 4 - 5 weeks before the actual meeting.
The following meetings are tentatively scheduled June 13 - 17 on the east
coast, September 26 - 30 central or west coast and January 9 - 13 1989 in
Hawaii.
(NOTE: Although March 21 - 25 was discussed as a possible meeting date,
March 14 - 18 has really been set. )
Item 20: Planning for ISO participation, Bob Mathis
Discussion on who should/could go to ISO in February.
Item 25: Adjournment 12:00, Bob Mathis
Jan Zubkoff
Acting Sectretary
∂14-Dec-87 1055 X3J13-mailer March meeting
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 10:55:42 PST
Received: by labrea.stanford.edu; Mon, 14 Dec 87 10:44:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06718g; Mon, 14 Dec 87 10:19:51 PST
Received: by sunvalleymall id AA10259g; Mon, 14 Dec 87 10:20:42 PST
Date: Mon, 14 Dec 87 10:20:42 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8712141820.AA10259@sunvalleymall.lucid.com>
To: labrea!x3j13%sail.stanford.edu@labrea.stanford.edu
Subject: March meeting
X3J13
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Thank you Dave Matthew for letting us use the HP discount!
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-0800.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂11-Jan-88 1056 X3J13-mailer mailings
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 88 10:55:54 PST
Received: by labrea.stanford.edu; Mon, 11 Jan 88 10:56:00 PST
Received: from sunvalleymall.lucid.com by edsel id AA19685g; Mon, 11 Jan 88 10:49:25 PST
Received: by sunvalleymall id AA28780g; Mon, 11 Jan 88 10:52:13 PST
Date: Mon, 11 Jan 88 10:52:13 PST
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8801111852.AA28780@sunvalleymall.lucid.com>
To: x3J13@sail.stanford.edu
Cc: edsel!jlz@labrea.stanford.edu
Subject: mailings
This is a reminder that any subcommittee papers need to be mailed
by Friday 2/5 in order to reack committee members in time.
That's only 3 weeks from Friday folks...
---jan---
∂11-Jan-88 1249 X3J13-mailer mailings
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 12:49:36 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 11 Jan 88 15:49:30 EST
Received: by kali.think.com; Mon, 11 Jan 88 15:49:26 EST
Date: Mon, 11 Jan 88 15:49:26 EST
From: gls@Think.COM
Message-Id: <8801112049.AA11904@kali.think.com>
To: x3J13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 11 Jan 88 10:52:13 PST <8801111852.AA28780@sunvalleymall.lucid.com>
Subject: mailings
I would like to appeal to all subcommittees to try very hard to submit
material for mailing to X3J13 members as Jan has requested. Failure to
use this mailing-out mechanism slows our progress by a factor of two!
(To see why, consider that a proposal based on feedback from the December
meeting can be voted on in March if mailed out ahead, but cannot be voted
on until June if first presented at the March meeting.)
We stand a very good chance of having a draft ready for public review by
December 1988 or maybe March 1989, *provided* that we make good use of time
by mailing proposals out ahead of meetings. Here is a plausible schedule,
if also an optimistic one:
February: Mail out current CLOS draft.
Mail out current error proposal draft.
Mail out cleanup proposals so far.
Mail out other proposals (character sets? iteration?).
March: Vote on all this stuff. Probably CLOS needs two more
iterations and error proposal needs one more iteration.
Some small fraction of cleanup proposals require iteration.
May: Mail out CLOS draft N-1.
Mail out error proposal draft M.
Mail out more cleanup proposals.
Last chance to mail other proposals without blowing the schedule.
Mail out whatever draft manual the editorial committee has so far.
June: Vote on CLOS draft; probably needs one more round.
Vote on error draft; with any luck this is final or
requires only very minor tweaking.
Vote on more cleanup proposals.
Vote on other proposals. Probably more work needed.
Provide feedback to editorial committee (now and by mail later).
August: Mail out CLOS draft N.
Mail out more cleanup proposals (the last ones???).
Mail out draft standard.
September: Vote on CLOS draft. With any luck this is final. (If we cannot
get a final vote by now, I despair of ever having one.)
Vote on cleanup proposals.
Vote on other proposals.
Provide lots of feedback to editorial committee.
November: Mail out reasonably final draft standard.
December: Vote on draft standard. Either it is ready for public review
or it isn't. (It need not be absolutely perfect, but should
be in good shape.) If it isn't, then another vote in March
is needed.
Such a schedule will demand hard work by the subcommittees, especially the
CLOS, cleanup, and editorial committees. I do know that Larry Masinter has
been working hard on the cleanup proposals, and the CLOS group met in
mid-December. Everyone else should only work so hard. If we do not have
the ambition to try for a schedule like this, then we are looking at a
public review in 1990 or beyond, at our present rate, and a standard
perhaps not until 1992. We need it much sooner than that.
Let's get cracking.
--Guy
∂26-Jan-88 1107 X3J13-mailer voting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 11:07:26 PST
Date: 26 Jan 1988 14:06-EST
Sender: MATHIS@A.ISI.EDU
Subject: voting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
At the upcoming meeting (March 14-18, including subcommittees)
in Palo Alto, I expect that we may be voting on some things.
After reviewing the attendance records of the last two meetings,
the following members representatives will be eligible
to vote (assuming they have also paid their X3 service fee).
If there are any questions or corrections, please contact me
as soon as possible.
-- Bob
Company Name Cambridge
====================================
Ft. Collins
A.I. Architechs X
Aerospace X
Alliant X
Bath, U. X X
CSC X
DEC X X
Edinburgh, U. X X
Encore X
Evans & Southerland X
Franz X X
Gensym X
Gigamos X X
GMD X
Goldhill X X
Gould X
Grumman X X
Hewlett Packard X X
Honeywell X X
IBM X X
ILOG S.A. X
INRIA X
Internat. Lisp Assoc. X
Johnson Controls X X
Lucid X X
Mathis X X
MCC X X
Micro. Sys. Consults. X
MIT X
Mitre X X
NBS X
Prime X
Red Shark Software X
Schlumberger X
Sun X
Symbolics X X
Tectronix X X
Texas Instruments X X
Thinking Machines X X
Unisys X X
USC-ISI X
Wang X
Xerox X X
∂01-Feb-88 1511 X3J13-mailer Don't forget mailings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 15:11:15 PST
Received: by labrea.Stanford.EDU; Mon, 1 Feb 88 15:11:29 PST
Received: from sunvalleymall.lucid.com by edsel id AA13089g; Mon, 1 Feb 88 14:55:21 PST
Received: by sunvalleymall id AA09790g; Mon, 1 Feb 88 14:59:40 PST
Date: Mon, 1 Feb 88 14:59:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802012259.AA09790@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Don't forget mailings
Documents for X3J13 should be mailed this week in order to reach
committee members on time. If you need mailing lables please
contact Bob Mathis.
---jan---
∂13-Feb-88 1728 X3J13-mailer Issues from the cleanup sub-committee
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:28:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:29:36 PST
Date: 13 Feb 88 17:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issues from the cleanup sub-committee
To: X3J13@Sail.stanford.edu
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880213-172936-10523@Xerox>
The cleanup committee has a number of issues for discussion and/or voting at the
next X3J13 meeting. I will be mailing out those issues which are ready for
voting at the next meeting, one at a time.
I am uncertain as to the exact procedure for voting; I imagine that Bob Mathis
will help clarify. My current understanding is that you should be prepared
either to vote for endorsing a proposal or should prepare a written objection.
Please address your replies directly to cl-cleanup@Sail.stanford.edu. We promise
to summarize and redistribute any replies we get. X3J13@Sail.stanford.edu should
*not* be used for technical discussions, however.
The cleanup issues fall into several categories.
Passed X3J13/Jun87:
Mailed to X3J13 prior to the June 1987 meeting of X3J13 and passed (via voice
vote) at that meeting.
As these were distributed before, they will not be mailed again except by
individual request, although the issues will appear on the ballot.
Conditionally passed X3J13/Jun87, new version passed X3J13/Nov87:
While an earlier version was mailed to X3J13 prior to the Jun87 meeting, the
most recent version was distributed only in hardcopy at the November 1987
meeting.
Passed X3J13/Nov87:
Distributed only via hardcopy at the November 1987 meeting.
New ballot items for Mar88:
Not previously distributed to X3J13, but ready for voting.
In discussion:
Some of these issues may be distributed via electronic mail to X3J13 prior to
the March meeting for discussion at the meeting, although they will not appear
on a ballot at that time.
∂14-Feb-88 1045 X3J13-mailer Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:45:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:45:59 PST
Date: 14 Feb 88 10:45 PST
From: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-104559-1224@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: ADJUST-ARRAY (CLtL p.297)
Category: Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
Version 2 by Masinter
Version 3 by Masinter, 5-Jun-87 (respond to comments)
Version 4 by Masinter, 23-Nov-87
Problem Description:
The interaction of ADJUST-ARRAY and displaced arrays is insufficiently specified
in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Interaction of adjusting and displacement:
Suppose we are adjusting array A, which is perhaps displaced to B before the
ADJUST-ARRAY call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered, and the
contents rearranged as appropriate. Additional elements of A are taken from the
:INITIAL-ELEMENT. The use of :INITIAL-CONTENTS causes all old contents to be
discarded.
(2) A is not displaced before, but is displaced to C after. As specified in
CLtL, none of the original contents of A appears in A afterwards; A now contains
the contents of C, without any rearrangement of C.
(3) A is displaced to B before the call, and is displaced to C after the call.
(B and C may be the same.) As in case (2), the contents of B do not appear in A
afterward (unless such contents also happen to be in C). If
:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it defaults
to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A gets a
new "data region", and contents of B are copied into it as appropriate to
maintain the existing old contents; additional elements of A are taken from the
:INITIAL-ELEMENT. However, the use of :INITIAL-CONTENTS causes all old contents
to be discarded.
If array X is displaced to array Y, and array Y is displaced to array Z, and
array Y is altered by ADJUST-ARRAY, array X must now refer to the adjusted
contents of Y. This means that an implementation may not collapse the chain to
make X refer to Z directly and forget that the chain of reference passes through
array Y. (Cacheing techniques are of course permitted, as long as they preserve
the semantics specified here and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it no
longer has enough elements to satisfy X. This error may be signalled at the
time of the adjustment, but this is not required.
Note: Omitting the :DISPLACED-TO argument to ADJUST-ARRAY is equivalent to
specifying :DISPLACED-TO NIL; in either case, the array is not displaced after
the call and case (1) or (4) hold.
Rationale:
This interaction must be clarified. This set of rules was proposed some time
ago, as a result of discussions on the Common Lisp mailing list, and this model
has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here, although they
differ in some detail. For example, Symbolics Common Lisp behaves as indicated
except for case (4); in that case, it never copies the contents of B, and all
elements are taken from the :INITIAL-ELEMENT.
Cost to implementors:
Some existing implementations may have to be changed, but adopting any other
model would be worse. Public-domain code implementing this model is available
from CMU.
Cost to users:
This is a relatively uncommon situation, which is the reason it didn't occur to
the original language designers to specify how it works. Any user code that
cares about this issue probably already follows the proposed model.
Benefits:
Clarification of a situation that is currently not addressed by the standard.
Discussion:
The cleanup committee supports this clarification.
Some consideration was given to adding DISPLACED-ARRAY-P or ARRAY-DISPLACED-TO
and ARRAY-DISPLACED-INDEX-OFFSET which would allow access to information as to
whether an array was or was not displaced. However, these are not part of the
current proposal.
A similar issue arises with ADJUST-ARRAY and fill pointers, and will be the
subject of a separate issue.
∂14-Feb-88 1049 X3J13-mailer Issue: APPEND-DOTTED (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:49:35 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:50:04 PST
Date: 14 Feb 88 10:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: APPEND-DOTTED (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105004-1227@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: APPEND-DOTTED
References: APPEND (p268)
Category: CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
29-Oct-87, Version 2 by Pitman (loose ends)
14-Nov-87, Version 3 by Masinter
23-Nov-87, Version 4 by Masinter
14-Jan-88, Version 5 by Masinter
Problem Description:
The description of APPEND on p268 is not adequately clear on the issue of what
happens if an argument to APPEND is a dotted list. The only case explicitly
mentioned is the last argument, viz:
"The last argument [to APPEND] actually need not be a list but may be any LISP
object, which becomes the tail end of the constructed list. For example, (append
'(a b c) 'd) => (a b c . d)."
While this specifies the behavior of APPEND when the last argument is not a
list, the behavior when any of the other arguments are not lists is not
specified.
Proposal (APPEND-DOTTED:REPLACE):
Define that the cdr of the last cons in any but the last argument given to
APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be
returned.
In the degenerate case where there is no last cons (i.e., the argument is NIL)
in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument is a
non-list, the result of APPEND or NCONC can be a non-list.
Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the
same, since these two might legitimately differ in situations involving dotted
lists. As such, deciding which to use is not just a stylistic issue.
Examples:
(APPEND '(A B C . D) '()) => (A B C) ;Proposed
(NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed
Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).
(APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed
(NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed
(APPEND '() 17) => 17 ;Proposed
(NCONC (LIST) 17) => 17 ;Proposed
Rationale:
This function is used a lot and its behavior should be well-defined across
implementations. This proposal upholds the apparent status quo in a number of
implementations.
Current Practice:
Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed
interpretation (at least in the interpreter). Franz's Allegro Common Lisp
conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17,
where it returns NIL instead of 17.
Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list.
Xerox Common Lisp signals an error on APPEND and implements the proposed
interpretation on NCONC.
Cost to implementors:
Technically, the change should be relatively small for those implementations
which don't already implement it. However, implementations which have microcoded
APPEND or NCONC incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only NIL
when SAFETY is 0. In this case, depending on implementation details, requiring
an ATOM check rather than a NULL check may slow things down.
Cost to users:
This change is upward compatible.
Benefits:
Since non-lists are allowed as a last argument and since APPEND and NCONC can
therefore produce dotted lists, some readers may have (incorrectly) assumed that
APPEND and NCONC can reliably deal in general with dotted lists, something that
doesn't appear to be guaranteed by a strict reading. The proposed extension
would happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
Discussion:
The cleanup committee supports this proposal.
∂14-Feb-88 1057 X3J13-mailer Issue: AREF-1D (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 10:57:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 10:57:51 PST
Date: 14 Feb 88 10:57 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: AREF-1D (Version 7)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-105751-1238@Xerox>
This issue passed conditionally at the June 1987 meeting of X3J13. This version,
distributed in hardcopy at the November 1987 meeting, clarified some of the
details of the proposal.
!
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
6-Jun-87, Versions 3, 4 by Masinter (editorial)
11-Jun-87, Version 5, to X3J13 (no changes)
6-Jul-87, Version 6, by Masinter
14-Nov-87, Version 7, by Masinter (update discussion)
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY efficiently
in Common Lisp because they take arguments of varying rank. Currently, you have
to make a displaced array to work with temporarily and then throw away the
displaced array when you're done. In many cases, this is bothersome because
there is no a priori reason why they should have to cons at all.
Proposal (AREF-1D:ROW-MAJOR-AREF):
Introduce a new function ROW-MAJOR-AREF that allows one-dimensional access to
the storage backing up a given array assuming the normal row-major storage
layout.
ROW-MAJOR-AREF is valid for use with SETF.
row-major-aref array index [Function]
This accesses and returns the element of array specified by index when the
elements of array are considered in row-major order. Array may be an array of
any dimensionality. row-major-aref may be used with setf. For reference, the
following sets of expressions are equivalent:
(row-major-aref array index) ==
(aref (make-array (array-total-size array)
:displaced-to array
:element-type (array-element-type array))
index)
and
(aref array .. subscripts ..) ==
(row-major-aref array (array-row-major-index array .. subscripts ..))
Rationale:
Common Lisp requires row-major storage layout of arrays and has a number of
operators that allow users to exploit that order. ROW-MAJOR-AREF is a useful,
simple addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by loops that
had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (ROW-MAJOR-AREF ARRAY I) ...)
Currently, the only really efficient way to write this would involve something
like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations that already use this
primitive internally, it's little more than a matter of changing the name of or
otherwise releasing the existing primitive. In some implementations, it might
involve writing a small amount of code or compiler work to make ROW-MAJOR-AREF
work efficiently.
Benefits:
This gives users efficient access to something to which they already have
inefficient access.
Conversion Cost:
This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely to be
used by any current program.
Aesthetics:
This allows certain programs to be written in a more aesthetic way.
Discussion:
This issue was conditionally passed at X3J13/June 1987, pending clarification of
some details. Those clarifications have been made in this version.
∂14-Feb-88 1103 X3J13-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:03:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:03:31 PST
Date: 14 Feb 88 11:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110331-1248@Xerox>
This issue is new.
!
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
20-Nov-87, Versions 2,3 by Masinter
23-Nov-87, Version 4 by Masinter
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT do not
mention a :KEY option, although ASSOC and RASSOC have one.
This is often reported as an inconsistency in Common Lisp.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords for
other -IF and -IF-NOT functions. The function, as with the :KEY argument for
ASSOC and RASSOC, is applied to the CAR of the pair in the association list for
ASSOC-IF and ASSOC-IF-NOT and the CDR of the pair for RASSOC-IF and
RASSOC-IF-NOT.
Documentation impact:
A better description of the intent might be to say that the car /contains/ the
key of the association, and by default the car /is/ the key of the association.
Example:
(assoc-if #'zerop pathnames :key #'pathname-version)
could be used to search a list indexed by pathnames finding one with zero
version.
Rationale:
This is an inconsistency in the language that is simple to fix.
Current Practice:
Symbolics implements :KEY for the -IF and -IF-NOT assoc functions. Others follow
the book and allow :KEY only for ASSOC.
Cost to Common Lisp implementors:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Cost to Common Lisp users:
The change is essentially upward compatible with user code.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in their
calling conventions.
Aesthetics:
All the other -IF and -IF-NOT variations of list operations omit the :TEST and
:TEST-NOT keywords, but allow :KEY. For example, consider the family of MEMBER,
MEMBER-IF, and MEMBER-IF-NOT. Although this introduces additional mechanism, it
does so in a way that probably makes it easier to think about which functions do
what, so it would likely be seen as a simplification.
Discussion:
The omission of :KEY in this situation in CLtL was probably an oversight.
The cleanup committee supports this proposal.
∂14-Feb-88 1109 X3J13-mailer Issue: COLON-NUMBER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:08:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:08:44 PST
Date: 14 Feb 88 11:08 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: COLON-NUMBER (Version 1)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-110844-1256@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting of X3J13.
!
Issue: COLON-NUMBER
References: Parsing of Numbers and Symbols (p339-341, 343-344)
Category: CLARIFICATION
Edit history: 22-Oct-87, Version 1 by Pitman
Problem Description:
CLtL is unclear about whether a colon followed by a potential number is a
potential number. There are passages which seem to address this issue
unambiguously but fail.
Proposal (COLON-NUMBER:UNDEFINED):
Clarify that syntax involving a leading colon followed by a potential number is
not well-defined. That is, use of notation such as :1, :1/2, and :2↑3 in a
position where an expression appropriate for READ is expected is an error.
Rationale:
This makes the status quo apparent.
Current Practice:
Some implementations, such as Symbolics Lisp, claim the right to interpret this
as an ``is an error'' situation where their upward-compatible extension is to
parse ``:1'' as the number 1 (incidentally, but uninterestingly, expressed in
the KEYWORD package).
Other implementations tokenize ``:1'' as a single token, identify it as a
symbol, and then parse it as :\1 would be parsed.
Cost to implementors:
None. This clarification forces no implementations to change.
Cost to users:
Slight. Some users may have mistakenly believed that this was an aspect of the
language that was guaranteed and may have written programs that exploited that
belief. Such incidences are probably very rare, however. Also, even in the few
cases where such code fortuitously worked, implementations are likely to
continue to support it so such code will probably continue to fortuitously work
in many of those rare situations.
Benefits:
Programmer expectations that any useful behavior can be portably relied upon in
this pathological case should be soundly trounced.
Aesthetics:
Arguably a slight improvement in visual aesthetics. What was already a pretty
marginal syntax is discouraged.
Discussion:
Pitman supports this clarification. He thinks this issue is not a big deal, but
it does crop up often enough to be a nuisance. It would be nice to have everyone
acknowledge a unified position, even if that only meant agreeing to disagree.
∂14-Feb-88 1112 X3J13-mailer Issue COMPILER-WARNING-BREAK (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:12:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:13:23 PST
Date: 14 Feb 88 11:13 PST
From: Masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK (Version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-111323-1266@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
Version 2 by cleanup committee 15-Mar-87 14:25:03
Version 3 by Masinter 5-Jun-87
Version 4 by Masinter 23-Nov-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say whether
*BREAK-ON-WARNINGS* affects warnings output by the compiler. If this is to be
allowed, it should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these functions
are required to break on warnings if *BREAK-ON-WARNINGS* is true (just as if it
calls WARN).
Note: User interface commands provided by particular vendor implementations
which implicitly call COMPILE or COMPILE-FILE could bind *BREAK-ON-WARNINGS*
back to NIL if they felt it important to not break for some reason relating to
cultural compatibility. This would not interfere with the proposed new semantics
for the functions COMPILE and COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when warnings
occur. If the compiler is permitted to warn (separate ballot item), the effect
of this variable on compiler warnings should be nailed down.
Current Practice:
Some compilers respect *BREAK-ON-WARNINGS* and others probably do not.
Adoption Cost:
Those compilers which do not use WARN directly but some other mechanism might
have to be edited, but it would not be a major change.
Conversion Cost:
Probably little or no user code would be affected by this change.
Benefits:
This would make the language definition more consistent by making it less
subject to special cases. Portable programs can be assured of consistent
behavior when dealing with the compiler.
Aesthetics:
Most users will probably perceive this change as a simplification because it
will allow the kind of warning that comes from WARN and the kind of warning that
comes from compilation to be conceptually grouped.
Discussion:
*BREAK-ON-WARNINGS* and the compiler are part of the environment rather than the
language.
We considered but rejected the notion of a separate
*COMPILER-BREAK-ON-WARNINGS*. It is possible that with the adoption of a
signal/error system that the *BREAK-ON-WARNINGS* mechanism could be replaced in
its entirity by a more structured signal/handler structure, making this proposal
moot.
∂14-Feb-88 1125 X3J13-mailer Issue: DEFVAR-DOCUMENTATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:25:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:25:36 PST
Date: 14 Feb 88 11:25 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-DOCUMENTATION (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <880214-112536-1283@Xerox>
An earlier version of this issue was distributed at the November 1987 meeting.
!
Issue: DEFVAR-DOCUMENTATION
References: DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category: CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
23-Nov-87, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether the documentation part of DEFVAR,
DEFPARAMETER, and DEFCONSTANT special forms is evaluated.
Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):
Clarify that the documentation part of DEFVAR, DEFPARAMETER, and DEFCONSTANT
special forms is not evaluated. That is, it must be a literal string, not a form
which evaluates to a string.
Examples:
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) "A documentation string") ; OK
(DEFVAR *MY-VARIABLE* (CONSTRUCT-INITIAL-VALUE) GENERIC-DOCUMENTATION-STRING) ;
would be an error
Rationale:
To ensure portability, implementations must agree on whether or not this
position is evaluated. Specifying that the position is unevaluated is the
conservative thing to suggest, and consistent with the (unevaluated)
documentation strings in DEFUN, DEFSTRUCT.
Current Practice:
Some implementations evaluate this position. Others do not.
Cost to implementors:
Implementations that did not already check might usefully add a check in the
macro expansion for DEFVAR, DEFPARAMETER and DEFCONSTANT to assert that the
DOCUMENTATION, if supplied, was a string. The change is likely trivial.
Cost to users:
Code which uses other than a literal string is not portable, so no portable
programs will be broken. Some non-portable programs which rely on a particular
vendor's interpretation would have to be rewritten. Automatic tools to detect
most offending cases could trivially be constructed. (We know of no current
uses.)
Benefits:
Code portability would be improved. Some programming environment tools might
assume that documentation strings were determinable without evaluation.
Aesthetics:
Slight improvement; this implies consistent treatment for documentation strings
in all defining forms.
Discussion:
We think this is a good idea.
∂14-Feb-88 1130 X3J13-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:30:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:31:18 PST
Date: 14 Feb 88 11:30 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113118-1288@Xerox>
This issue has not been distributed before. It is originally from Steele's list.
!
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 2 by Pierson 12/30/87
Version 3 by Pierson 1/21/88
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is not a
compiled function, it is first compiled.". The definition of COMPILE says that
"If name is a non-nil symbol, then the compiled-function is installed as the
global function definition of the symbol...". Several implementations have
taken this to mean that if DISASSEMBLE is passed a symbol which has an
uncompiled function definition, then it has the side-effect of (COMPILE
'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never install the
newly compiled function.
Example:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
This code will return T if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side effects,
especially for new users.
Current practice:
Allegro CL and Vax Lisp install the compiled definition. Lucid, Symbolics,
Xerox, and KCL don't install it.
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is probably not
called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was meant to be.
Aesthetics:
Some who worried that DISASSEMBLE was supposed to install the compiled function
may find that the language has become a little cleaner.
Discussion:
DISASSEMBLE is an environment feature; some question has been raised as to the
place and force of environment features in the standard. However, this proposal
stands if DISASSEMBLE is part of the standard language.
∂14-Feb-88 1122 X3J13-mailer Issue: DECLARE-MACROS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:22:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:21:29 PST
Date: 14 Feb 88 11:21 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DECLARE-MACROS (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: no
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <880214-112129-1276@Xerox>
This issue was distributed in hardcopy at the November 1987 meeting.
There was some opposition at that time. This version includes a more
extensive description of possible alternative coding practices.
!
Issue: DECLARE-MACROS
References: Declaration Syntax (p154)
Category: CHANGE
Edit history: 22-Oct-87, Version 1 by Pitman
9-Nov-87, Version 2 by Masinter
5-Feb-88, Version 3 by Pitman
Problem Description:
It is permissible for a macro call to expand into a declaration and be
recognized as such. This linguistic feature provides some useful
flexibility, but has a number of disadvantages:
* Operations on the executable portion of a body of code inside a
binding form (such as inserting an additional form) is a complicated
operation. This is because one or more trial macro expansions must be
done in order to pass over any declarations or documentation string
and find the beginning of the body.
* In order to find the end of the declarations, MACROEXPAND must be
called until a non-macro form is seen or until a macro does not expand
into a macro. In some interpreters which do macro expansion on the fly,
this may cause inefficiency because macro expansion of the first form
in a body must be done twice. In implementations where this is
optimized, the implementor may resent the fact that an optimization is
needed in the first place.
* Various code analysis tools have been shown to have been significantly
slowed down by the need to expand macros in order to determine whether
a binding is SPECIAL when analyzing a variable binding form. This is
particularly serious when macro invocations are deeply nested; the
number of macro expansions can be exponential in the depth of nesting
unless a macro-expansion caching mechanism is added.
* User macros must be very careful about finding declarations in a body
of code by doing proper macro expansion. Often, however, naive users
don't realize this and so unknowingly write buggy code. This problem can
be (and is) defined away as simply a programmer error, but this is a
place where we could fairly straightforwardly redefine the language to
better accommodate what has been shown to be a common expectation of the
naive user.
Proposal (DECLARE-MACROS:FLUSH):
Under this proposal, it would not be "permissible for a macro call to
expand into a declaration and be recognized as such, provided that the
macro call appears where a declaration may legitimately appear." (CLtL
p. 154). Macros could not legitimately expand into declarations; the only
valid declarations would be a list whose CAR is the symbol DECLARE.
It would still be possible for a macro call to expand into a PROCLAIM
form, however.
Rationale:
The ability to have a macro form expand into a declaration has been shown
to be useful in some situations. More often, however, the presence of
this feature has been seen to cause problems elsewhere in the language.
Ultimately, its benefits have not outweighed its costs.
Current Practice:
Most or all implementations support the old behavior even though few
user programs probably need it.
Some user macros are careful about finding declarations in a body of code
by doing proper macro expansion, but some probably cheat and look just
for explicit uses of DECLARE. The cheat probably works most of the time.
Cost to implementors:
The nature of this change is such that implementations which did not
choose to change would simply be supporting an implementation-dependent
extension (except for some `minor' worry about destructive modification
due to macro expanding while *MACROEXPAND-HOOK* is set to something
which implemented displacing macros).
In any case, there might be several places in which the interpreter,
compiler, and system macros had knowledge about doing macro expansion
before declaration processing. The change is not trivial, but most of
its complexity is likely to be in finding the places which need change
and not in making the actual change.
Cost to users:
Most users probably do not write macros which expand into DECLARE forms
so most users are probably not affected.
Users who do exploit this feature probably know that they do. In any
case, compilers could be made to detect cases where this feature is
being exploited and warn about it.
Franz and Gold Hill are notable exceptions to the claim that users may
not want this. Both claim to make a reasonable amount of use of macros
which expand into different SPEED and SAFETY declarations, usually
dependent on a global switch.
Rewrites must be devised on a case-by-case basis. A common sort of
rewrite would take the form:
Old code: (DEFMACRO SPEEDY ()
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0))))
(LET (..bindings..) (SPEEDY) ..body..)
New code: (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
`(LET ,BVL
(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
,@FORMS))
(SPEEDY-LET (..bindings..) ..body..)
Another tactic would be:
Old code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *SPEEDY* NIL))
(DEFMACRO USE-STANDARD-SPEED-AND-SAFETY ()
(IF *SPEEDY*
`(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)))
`(DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3)))))
(DEFUN FOO ()
(USE-STANDARD-SPEED-AND-SAFETY)
...)
New code: (EVAL-WHEN (EVAL COMPILE LOAD)
(DEFVAR *STANDARD-SPEED-AND-SAFETY* '((SPEED 0) (SAFETY 3))))
(DEFUN FOO ()
(DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*))
...)
Still a third tactic would be to actually shadow DEFUN, LET, etc. with
variants that process macro expansions and then to build code in a
package that used the revised DEFUN, LET, etc. eg,
(DEFUN PARSE-BODY (BODY ENV)
(LET ((DECLS '())
(DOC '()))
(DO () ((NULL (CDR BODY)))
(LET ((EXP (MACROEXPAND (POP BODY) ENV)))
(COND ((AND (STRINGP EXP) BODY)
(UNLESS (NULL DOC)
(WARN "More than one documentation string was seen."))
(PUSH EXP DOC))
((AND (NOT (ATOM EXP)) (EQ (CAR EXP) 'DECLARE))
(PUSH EXP DECLS))
(T
(PUSH EXP BODY)
(RETURN NIL)))))
(VALUES BODY (NREVERSE DECLS) (NREVERSE DOC))))
(DEFMACRO MY:DEFUN (NAME LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(DEFUN ,NAME ,BVL ,@DECLS ,@DOC-STRINGS ,@FORMS)))
(DEFMACRO MY:LET (BINDINGS &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`(LET ,BINDINGS ,@FORMS)))
...etc.
LAMBDA cannot be done this way, of course, since it is not a macro (or
even a special form). Support for expanding declarations in a LAMBDA
would have to be provided either by using implementation-specific support
(such as Zetalisp's ``lambda macros'') or by a workaround such as a
macro like:
(DEFMACRO LAMBDA (LAMBDA-LIST &BODY DECLS-DOC-AND-FORMS
&ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (FORMS DECLS DOC-STRINGS)
(PARSE-BODY DECLS-DOC-AND-FORMS ENV)
`#'(LAMBDA ,BINDINGS ,@FORMS)))
Note that unlike the other examples, LAMBDA need not be (and in fact,
may not be) in the "MY" package in order for this to work since the
FUNCTION special form will generally only recognize LISP:LAMBDA.
Benefits:
The efficiency of some tools may be improved.
User macros which must do minor surgery on bodies of code will be
easier to write.
Aesthetics:
This change simplifies the semantics of the language slightly and
probably tends to better support the assumptions of naive programmers
writing macros.
In some cases involving complicated extensions to declarations, it
may be slightly harder to express such extensions in a modular way.
Experience thus far has shown such cases to be rare, however.
Discussion:
Symbolics took an in-house poll of people who take advantage of the
feature and it was generally agreed that in most cases where this
feature is used at all, that it would be just as easy to work around
using the sample rewrite techniques cited above.
Moon `credits' Pitman for (against some opposition) pushing this
`feature' down everyone's throats in the original CL design process.
Pitman admits this was an expensive mistake. Moon and Pitman support
this change as an important simplification to the language.
The cleanup committee unanimously endorsed this proposal.
In discussion at the Nov-87 X3J13 meeting, Franz and Gold Hill
mentioned that they use this feature a lot and were not entirely
happy about its going away.
∂14-Feb-88 1137 X3J13-mailer Issue: DO-SYMBOLS-DUPLICATES (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:37:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:37:58 PST
Date: 14 Feb 88 11:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-113758-1303@Xerox>
This issue has not been distributed to X3J13 before.
!
Issue: DO-SYMBOLS-DUPLICATES
References: DO-SYMBOLS, CLtL p.187
Category: Clarification
Edit history: Version 1 by Fahlman 17-Apr-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Nov-87
Problem Description:
CLtL specifies that DO-SYMBOLS executes the body once for each symbol accessible
in the package. It does not say whether it is permissible for the body to be
executed more than once for some accessible symbols. The term "accessible" is
defined on page 172 to include symbols inherited from other packages (not
including any symbols that may be shadowed). It is very expensive in some
implementations to eliminate duplications that occur because the same symbol is
inherited from multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the body more
than once for some symbols.
Example:
(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B::ASYM B)
(USE-PACKAGE B A)
(DO-SYMBOLS (X B) (PRINT X))
;; this may print ASYM once or twice.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of duplicates. For
these applications it is unreasonable to force users to pay the high cost of
filtering out the duplications. Users who really want the duplicates to be
removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Cost to implementors:
None. Implemenations would still be free to eliminate the duplications, though
code will not be assuming that this has been done.
Cost to users:
Code written assuming that DO-SYMBOLS eliminates duplications will have to be
modified. (Such code was not truly portable.)
Benefits:
Clarification of a situation that is currently ambiguous.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a clear case
of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and the
solution proposed here seems to have been informally agreed to at the time --
there was no formal decision-making process in place then.
The need for DO-SYMBOLS to be efficient is questionable, however; for many
applications (e.g., global package manipulation), duplicate values would create
havoc.
For some implementations, the performance penalty would be well over a factor of
two.
Several proposals were considered for adding keyword arguments to DO-SYMBOLS
which might specify :ALLOW-DUPLICATES, adding keywords and eliminating
DO-EXTERNAL-SYMBOLS, etc., but no clear consensus was reached for making
additions.
This version is the closest to the status quo.
∂14-Feb-88 1155 X3J13-mailer Issue: DRIBBLE-TECHNIQUE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 11:55:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 11:55:39 PST
Date: 14 Feb 88 11:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: DRIBBLE-TECHNIQUE (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-115539-1321@Xerox>
This issue has not been distributed before. (In fact, this version had not been
distributed to the cleanup committee.) There was no discussion on the issue,
however.
!
Issue: DRIBBLE-TECHNIQUE
References: DRIBBLE (p443)
Category: CLARIFICATION
Edit history: 06-Dec-87, Version 1 by Pitman
14-Feb-88, Version 2 by Masinter
Problem Description:
The intent and effect of DRIBBLE is not very clearly specified. Users have
complained that DRIBBLE behaves quite differently in different implementations.
Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):
Clarify that DRIBBLE is intended primarily for interactive debugging and that
its effect cannot be relied upon from programs.
Test Case:
#1: (PROGN (DRIBBLE "temp")
(PRINT 'FOO)
(DRIBBLE))
#2: (DRIBBLE "temp")
(PROGN (PRINT 'FOO)
(DRIBBLE)
(PRINC 'BAR))
Rationale:
Users of DRIBBLE have been surprised about how differently DRIBBLE behaves in
different implementations. This makes the status quo much more explicit and will
lead to less surprise.
Current Practice:
Some implementations implement DRIBBLE as a function which simply assigns
streams such as *STANDARD-OUTPUT* to broadcast streams (or the approximate
equivalent thereof). Even within this camp, there is not widespread agreement
about which streams are affected. However, typically test case #1 will capture
the output of (PRINT 'FOO) in the file "temp" and will execute (PRINT 'BAR) but
not capture its output.
Some implementations (eg, Symbolics) push to a recursive command loop when
DRIBBLE is called with an argument, and return from that command loop when
DRIBBLE is called with no argument. In these implementations, test case #1 will
enter a recursive command loop upon the first call to DRIBBLE and will not
execute the (PRINT 'FOO) until (DRIBBLE) is done interactively. When the second
(DRIBBLE) in test case #1 is executed, DRIBBLE will complain that output is not
currently being recorded. In test case #2, the output of (PRINT 'FOO) will be
captured, but the form (PRINT 'BAR) will never be executed because (DRIBBLE)
does not return normally (it throws).
Cost to implementors:
None. This is just a clarification.
Cost to users:
Anyone who currently uses DRIBBLE in code that is believed to be portable is
kidding himself. If such code works in some implementations, it can continue to
work.
Benefits:
Users will be aware that they cannot rely on DRIBBLE in portable code.
Aesthetics:
No apparent effect.
Discussion:
DRIBBLE, like other environment features, is a standard interface to a
non-standard feature. As such, there is some question as to its place in the
ANSI standard. However, if DRIBBLE remains in the standard, its behavior is made
explicitly vague by this proposal.
∂14-Feb-88 1201 X3J13-mailer Issue: FLET-DECLARATIONS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:01:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:00:15 PST
Date: 14 Feb 88 11:59 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-DECLARATIONS (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120015-1323@Xerox>
!
Issue: FLET-DECLARATIONS
References: FLET, LABELS, MACROLET (CLtL p.113)
X3J13 document 86-003 item 113
Cleanup issue DECLARATION-SCOPE.
Cleanup issue DECLARE-MACROS.
Category: ADDITION
Edit history: Version 1, Moon, 1 Jan 1988
Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter)
Problem description:
Declarations are not allowed before the body of FLET, LABELS, and MACROLET, even
though Common Lisp allows declarations in other seemingly analogous places, such
as LET.
Proposal (FLET-DECLARATIONS:ALLOW):
Change the syntax of FLET, LABELS, and MACROLET to allow declarations between
the list of local function/macro definitions and the body forms.
The scope of such declarations in FLET and LABELS includes the bodies of the
locally defined functions, when the declarations are pervasive. Non-pervasive
declarations have no effect on those bodies, except when LABELS includes the
body in the scope of a function non-pervasively declared. This paragraph
follows directly from CLtL p.155 if the locally defined function bodies are
treated like initialization forms. (This paragraph will be superseded by cleanup
issue DECLARATION-SCOPE if it passes.)
The scope of such declarations does not include the bodies of the macro expander
functions defined by MACROLET. This is consistent with the existing rule that
the bodies of those functions are in the global environment, not the local
lexical environment.
If cleanup issue DECLARE-MACROS is not passed, in MACROLET an invocation of one
of the macros locally defined by that MACROLET is permitted to expand into a
DECLARE.
Example:
(defun example (y l)
(flet ((attach (x)
(setq l (append l (list x)))))
(declare (inline attach))
(dolist (x y)
(unless (null (cdr x))
(attach x)))
l))
(example '((a apple apricot) (b banana) (c cherry) (d) (e))
'((1) (2) (3) (4 2) (5) (6 3 2)))
=> ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry))
The above function is erroneous in current Common Lisp. With this proposal, it
would have an intuitively obvious meaning.
Rationale:
This will make the syntax of FLET and LET consistent. This will make it
possible to attach declarations to function bindings; currently only variable
bindings can have attached declarations.
Current practice:
Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW. Symbolics Common Lisp does
not allow declarations in this position.
Cost to Implementors:
The compilation and interpretation of three special forms will have to be
changed, however the same techniques already developed for declarations in LET
should be applicable.
Cost to Users:
No cost since this is an upward-compatible addition.
Cost of non-adoption:
Unnecessary inconsistency in the syntax of Common Lisp.
Benefits:
There is no major benefit but the language will be more consistent.
Esthetics:
Makes the language more consistent.
Discussion:
We need to resolve this for CLOS, because CLOS introduces two new special forms
similar to FLET and LABELS and we need to make their syntax consistent with FLET
and LABELS.
∂14-Feb-88 1204 X3J13-mailer Issue: FORMAT-COMMA-INTERVAL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:03:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:04:24 PST
Date: 14 Feb 88 12:04 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COMMA-INTERVAL (Version 2)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-120424-1324@Xerox>
This issue is new.
!
Issue: FORMAT-COMMA-INTERVAL
References: FORMAT integer printing (p. 388-9)
Category: ADDITION
Edit history: Version 1, Pavel, 10-Jun-87
Version 2, Masinter, 15-Jun-87
Problem description:
There are times when users would like to print out numbers with some punctuation
between groups of digits. The "commachar" argument to the ~D, ~B, ~O, ~X, and
~R FORMAT directives was introduced to fill that need. Unfortunately, the
interval at which the commachar should be printed is always every three digits.
This constraint is annoying when a different interval would be more appropriate.
Proposal (FORMAT-COMMA-INTERVAL:YES):
Add a fourth argument to the ~D, ~B, ~X, and ~O FORMAT directives, and a fifth
argument to the ~R directive, to be called the "comma-interval". This value
must be an integer and defaults to 3. When the : modifier is given to any of
these directives, the "commachar" is printed between groups of "comma-interval"
digits.
Test Cases:
Under the proposal, the following forms return the indicated values:
(format nil "~,,' ,4:B" 13) => "1101"
(format nil "~,,' ,4:B" 17) => "1 0001"
(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
(format nil "~3,,,' ,2:R" 17) => "1 22"
(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"
Rationale:
The current specification of FORMAT gives the user control over almost all of
the facets of printing integers. Only the wired-in constant for the
comma-interval remains, even though there are uses for varying that number. For
example, in many contexts, it would be convenient to be able to print out
numbers in binary with a space between each group of four bits. FORMAT does not
currently allow specification of the commachar printing interval so users
needing this functionality must write it themselves, duplicating much of the
logic in every implementation's integer printing code. Other uses, requiring
other intervals, can be imagined. For example, using a "commachar" of #\Newline
and a "comma-interval" of, say, 72, very large bignums could be printed in such
a way as to ensure line-breaks at appropriate places.
Current practice:
No released implementations currently support this feature.
Cost to implementors:
The change in the implementation of FORMAT is reasonably minor and, in most
cases, highly localized. Usually, the change is as simple as taking an extra
parameter and using it instead of a wired-in value of 3.
Cost to users:
Since the proposal involves the addition of an argument to certain directives,
the change would be entirely upward-compatible. No user code would need to be
converted.
Cost of non-adoption:
Users desiring this functionality will have to write it themselves, duplicating
much of the logic involved in printing integers at all.
Benefits:
One of the few remaining inflexibilities in integer printing is eliminated with
a net increase in user-visible functionality.
Esthetics:
By parameterizing one of the final pieces of wired-in behavior from integer
printing, this small part of the workings of FORMAT would be perceived as having
been cleaned up.
Discussion:
Several members of the cleanup committee endorsed this proposal. No objections
were raised.
∂14-Feb-88 1214 X3J13-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:14:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:14:54 PST
Date: 14 Feb 88 12:14 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-121454-1351@Xerox>
This issue is new.
!
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
version 2: Guy Steele, 18 January 1988
version 3: Masinter, 5 February 1988
Problem description:
Implementations currently differ on the question of what is tested by the FORMAT
command "~:↑". Some implementations test to see whether any arguments remain in
the sublist for the current iteration step; others test to see whether any
sublists remain. The text on page 406 is not clear on this point.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The
entire iteration process is terminated if and only if the sublist that is
supplying the arguments for the current iteration step is the last sublist (in
the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:↑ is *not*
equivalent to ~:#↑; the latter terminates the entire iteration if and only if no
arguments remain for the current iteration step.
Example:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under this proposal, this yields "a...b", rather than "a".
Rationale:
This proposal is desirable because otherwise there is no way to test whether any
sublists remain. The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
"If one thinks about the intent of the parenthetical `(because in the standard
case it tests for remaining arguments of the current step only)', one should
agree that "a...b" will be returned. In referring to ~↑ as the `standard case',
which tests the arguments remaining in the current argument sublist, this
parenthetical implies that there is an `other case', which tests `something
else.' The only `other case' discussed is ~:↑, which therefore must test
`something else.' I claim that the parentheical makes no sense if we interpret
~:↑ as testing the same condition as ~↑. If they both test the same condition,
why have the parenthetical explanation?
"If ~:↑ doesn't test the same condition as ~↑, then what does it test? I claim
that the only test that makes sense is for ~:↑ to test the only thing that
affects the `entire iteration process:' the number of sublists. When there are
no more sublists, `the entire iteration process' is terminated."
Current practice:
Some implementations already have the proposed behavior, including Symbolics
Common Lisp and TI Lisp.
Many other implementations currently have a different interpretation: the test
case returns "a", since ~:↑ in those implementations test for the remaining
arguments rather than remaining sublists. These currently include Kyoto Common
Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP.
Cost to Implementors:
Many implementations will have to make a small change, probably a one-liner.
Cost to Users:
It is unlikely that much user code depends on the behavior of testing for
remaining arguments, but it is possible. The author of this writeup (Steele)
judges it somewhat more likely that user code might depend on the behavior of
testing for remaining sublists.
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity. The proposed semantics allows greater
semantic power (there are more things one can test).
Esthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr.
Discussion:
Guy Steele very strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and
Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer and Rich Robbins have spoken in favor of an alternative proposal, to
test for the remaining arguments.
Historical note: Steele first implemented this "feature", in Zetalisp, and so
the code in Symbolics Common Lisp is likely a direct descendant of the original
code. This might cause some to give weight to Steele's opinion. There are two
arguments against such credence. First, there is no reason why the original
code should be regarded as part of the specification of Common Lisp any more
than any other implementation; plainly, Steele botched the specification when he
wrote the book. Second, a professor of literature (I believe) once told Isaac
Asimov concerning a short story of his (I quote from memory): "Tell me, Dr.
Asimov, just because you wrote the story, what makes you think you know what it
means?"
∂14-Feb-88 1223 X3J13-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:23:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:23:55 PST
Date: 14 Feb 88 12:23 PST
From: Masinter.pa@Xerox.COM
Subject: Issue FUNCTION-TYPE-KEY-NAME, Version 3
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122355-1354@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(from comments by Kent Pitman)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT,
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, there is a problem with &KEY lambda variables
because CLtL does not specify how the types specified in the FUNCTION
declaration are matched up to either the actual arguments passed to the
function, or the lambda variables in the function definition (since the ordering
of keyword arguments is arbitrary).
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list
should be supplied as lists of the form (<keyword> <type>). The <keyword> must
be a valid keyword-name symbol as must be supplied in the actual arguments of a
call. (This is usually a symbol in the keyword package, but, as per
KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.)
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list.
The interpretation of such declarations is that, when &KEY is given in a
FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given
are exhaustive unless &ALLOW-OTHER-KEYS is present.
&ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be
supplied and, if supplied, may be used.
Example:
The type of the function MAKE-LIST could be declared as:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
Rationale:
(1) This specifies a direct correspondence between the argument type and its
matching keyword. All of the information is in one place, and the user does not
have to remember (or even know) the order in which &KEY arguments appear in the
actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type declarations.
The situation regarding type specifications for keyword arguments is so
ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments in
a FUNCTION type specifier may continue to do so. This proposal should not
involve massive amounts of code to be rewritten.
Cost to users:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
The exact semantics of function declarations and the types of arguments is
still under discussion, as are several other issues dealing with declarations.
However, this issue seemed separable.
∂14-Feb-88 1231 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 12:31:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:29:51 PST
Date: 14 Feb 88 12:29 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-122951-1359@Xerox>
This issue is new.
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-ARGUMENT-TYPE-SEMANTICS
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function
argument types and return value types. This type specifier uses a syntax
similar to the usual lambda list syntax to specify which types go with which
lambda list variables. However, this is actually of limited usefulness in the
context of a declaration, where one normally wants type information about the
actual arguments which can be passed to the function rather than the lambda
variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem that
the corresponding type given in the FUNCTION declaration must also be LIST, but
since this provides no information about the actual arguments, some
users/implementors have instead adopted the convention of supplying the type of
the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the type
specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with
&REST is the type of each actual argument, not the type of the corresponding
lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be
LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only examples
found so far are in a text book on Common Lisp, which follows the proposed
syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so.
Probably only a small amount of code would have to be written/changed in
implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be
LIST will have to change their code. However, because this issue is so unclear,
the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited
use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide the
type of the lambda variable rather than the type of the actual arguments.
However, considering the types specified in the FUNCTION specifier to be the
types of the actual arguments rather than the types of the parameters as seen on
the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee. There was some
support for an alternative proposal to require that the &REST argument
declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST
type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE (including David Moon and Larry
Masinter) argue that the simplicity of the declarations and the ugliness of the
alternative, as well as the weight of current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used
internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a
sequence type when in fact there are numerous other places in the language where
it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if
it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an obscure
case (that doesn't even work in some implementations), it's the sort of thing
that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂14-Feb-88 1301 X3J13-mailer Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:58:56 PST
Date: 14 Feb 88 12:58 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-125856-1384@Xerox>
This issue passed conditionally at the June 1987 meeting; this revision was
distributed at the November 1987 meeting.
!
Issue: GET-SETF-METHOD-ENVIRONMENT
References: GET-SETF-METHOD (CLtL p 187)
Category: Change
Edit History: Version 1 9-Jan-87, Version 1 by Masinter
(no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
Version 2 29-May-87, extracted again
Version 3 5-Jun-87, by Masinter
Version 4 11-Jun-87, for release
Version 5 13-Jul-87, by Masinter
Problem Description:
If a macro that performs similar processing to SETF uses GET-SETF-METHOD, and
that macro occurs within a MACROLET, the expansion will not see the MACROLET
definition, e.g.,
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it defaults to
the null lexical environment. NIL can also be passed explicitly to denote the
null lexical environment.
Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the environment
to GET-SETF-METHOD.
Clarify that, within the scope of a MACROLET, FLET and LABELS, global SETF
definitions of the name defined by the MACROLET, FLET or LABELS do not apply. A
SETF method applies only when the global function binding of the name is
lexically visible. All of the built in macros of Common Lisp (SETF, INCF, DECF,
POP, ROTATEF, etc.) which modify location specifications obey this convention.
Test Case:
;;; This macro is like POP
(defmacro xpop (place &environment env)
(multiple-value-bind (dummies vals new setter getter)
(get-setf-method place env)
`(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
(prog1 (car ,(car new))
(setq ,(car new) (cdr ,(car new)))
,setter)))))
(defsetf frob (x) (value)
`(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro expansion time
(flet ((frob (x) (cdr x))
(xpop (frob z)))
Rationale:
This was an omission in the original definition of CLtL.
Current Practice:
Many Common Lisp implementations already have this extension, although some do
not. One implementation has extended GET-SETF-METHOD to take an optional
argument which is incompatible with this use.
Cost to implementors:
Some implementations will have to add this feature, although it is not a major
change.
Cost to users:
This is generally an upward compatible change. In implementations which did not
already take into account the lexical environment for SETF'd forms might start
working differently if the internal implementation of SETF is changed. The
likelihood of this affecting a user's program is very small.
Benefits:
This change improves portability and the ability to use MACROLET, FLET and
LABELS in portable code which might also have SETF forms.
Aesthetics:
SETF methods cannot work correctly within lexically defined function symbols
without this change. This change makes the language more consistent and correct.
Discussion:
The cleanup committee generally supports this change.
A number of additional changes for rationally dealing with lexical environments
as first class objects, including a more general set of accessors and
constructors for lexical environments is required for many language extensions
(e.g., a portable version of the proposed Common Lisp Object System) and should
be addressed by a future proposal. For a while, the cleanup committee attempted
to deal with these issues together, but decided to separate them out into their
component parts. This issue is the simplest.
∂14-Feb-88 1310 X3J13-mailer Issue: PATHNAME-STREAM (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:10:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:10:49 PST
Date: 14 Feb 88 13:10 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 6)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-131049-1395@Xerox>
Version 2 conditionally passed X3J13/Jun87. Version 6 was distributed in
hardcopy form X3J13/Nov87.
!
Issue: PATHNAME-STREAM
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: TRUENAME (p.413), PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87 (minor editing)
Version 3 by Masinter 11-Jun-87 (minor editing)
Version 4 by Masinter 8-Oct-87 (rewording)
Version 5 by Masinter 8-Oct-87 (explicitly only open)
Version 6 by Masinter 14-Nov-87
Category: CHANGE/CLARIFICATION
Problem Description:
CLtL says that a stream can be used as an argument and converted to a pathname,
but many sources or sinks of data that streams might be connected to have no
pathnames associated with them; for example, streams created with
MAKE-TWO-WAY-STREAM or OPEN-STRING-STREAM. For many such streams, there is no
simple way to coerce such a stream to a pathname.
Proposal PATHNAME-STREAM:FILES-OR-SYNONYM:
Clarify that the use of a stream as an argument that expects a pathname (as
described on p413 of CLtL) only applies to streams that are originally opened by
use of the OPEN or WITH-OPEN-FILE, or to synonym streams whose symbol is bound
to such a stream. It is an error to attempt to obtain a pathname from a stream
created with MAKE-TWO-WAY-STREAM, OPEN-STRING-STREAM, MAKE-ECHO-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM.
The pathname used represents the name used to open the file. This may be, but is
not required to be, the actual name of the file. The pathname used is the same
as would be returned by the PATHNAME function.
Rationale:
This is probably what the designers of Common Lisp intended. This is the only
thing that can be implemented without large changes to the language such as
extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname. Others
return an empty pathname.
Some implementations do not return a meaningful value for PATHNAME of a synonym
stream.
Adoption Cost:
Implementations that do not currently handle PATHNAME of a synonym stream will
have to change to allow it. Otherwise, since the proposal says only "is an
error" rather than "signals an error", no implementations other changes are
necessary.
Benefits:
The description of pathname functions will make more sense.
Conversion Cost:
Small: Users with code which accesses pathname components of streams in
implementations which allow it might need to change their programs to make them
portable.
Aesthetics:
Makes language a little cleaner.
Discussion:
The only point of disagreement on this proposal has been on the issue of whether
PATHNAME applies to synonym streams and returns the pathname of the stream
designated.
This version of the proposal says yes, because CLtL p 329 says about synonym
streams that "Any operations on the new stream ..." and does not say anything
about exceptions; earlier on the page the phrase "synonym streams that pass all
operations on" is used. This seems fairly unambiguous, although the word
"operations" is not defined. There was a similar controversy about what CLOSE of
a synonym stream means.
Note that there is currently no way portable to determine whether a stream has a
pathname available.
The entire PATHNAME section needs work to clarify the intent and enable portable
code. This is just a minor issue among the major ones.
∂14-Feb-88 1306 X3J13-mailer Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:06:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:07:20 PST
Date: 14 Feb 88 13:06 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-130720-1391@Xerox>
Version 6 conditionally passed X3J13/Jun87. Version 8 distributed in hardcopy
form X3J13/Nov87.
!
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (CLtL pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
29-May-87, Version 4 by Masinter
5-Jun-87, Version 5 by Masinter
11-Jun-87, Version 6 by Masinter
23-Oct-87, Version 7 by Masinter
8-Nov-87, Version 8 by Moon
Problem Description:
CLtL says that only keyword symbols can be used as keyword-names in
&key parameter specifiers (page 60, "each -keyword- must be a
keyword symbol, such as :start.")
As Common Lisp is currently defined, if someone wants to define a
function that accepts keyword (rather than positional) arguments whose
keyword-names are symbols in packages other than the KEYWORD package,
they cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.
Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of the keyword-names of keyword
parameters; allow any symbol. That is:
If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword symbol with the same print name as the variable is created and
is used as the keyword-name when matching arguments to parameter
specifiers. A keyword-name that is not a keyword symbol can be
specified with the ((-keyword- -var-) ...) syntax of parameter
specifier. The -keyword- can be any symbol, not just a keyword.
A future specification of Common Lisp could be written with revised
terminology that did not use the term "keyword" to refer to three
different things: symbols in the KEYWORD package, symbols beginning
with & that have special meaning in lambda-lists, and keyword-names
used to match function arguments to keyword parameter specifiers.
However, this proposal does not propose to change any terminology.
Test case:
(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
(FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))
(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"
Rationale:
The "rationale" box on p.62 of CLtL is an argument in favor of requiring
keyword-names to be symbols, and disallowing numbers, but does not
speak to the issue of whether or not those symbols should be further
restricted to be in the KEYWORD package.
The desire for keyword parameters whose keyword-names are not in the
KEYWORD package arises when the set of keyword-names accepted by a
function is the union of the sets of keyword-names accepted by several
other functions, rather than being enumerated in a single place. In
this case, it becomes desirable to use packages to prevent accidental
name clashes among keyword-names of different functions.
One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS). It will have generic functions that accept arguments and pass
them on to one or more applicable methods, with each method defining its
own set of keyword-names that it is interested in. If this proposal is
not adopted, either the keyword-names will be required to be keywords,
which will require the methods to have non-modular knowledge of each
other in order to avoid name clashes, or the methods will have to be
defined with an ad hoc mechanism that duplicates the essential
functionality of &key but removes the restriction.
A second example of a Common Lisp application that requires this
capability is private communication channels between functions. Suppose
a public routine MAKE-FOO needs to accept arbitrary arguments from the
caller and passes those arguments along to an internal routine with
additional arguments of its own, and suppose that keyword parameters
are used to receive these arguments.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST NAME-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T NAME-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override some argument in NAME-VALUE-PAIRS, since the only way
that could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT
NIL), or if the user was programming explicitly in the FOOLAND package,
either of which is an implicit admission of willingness to violate
FOOLAND's modularity.
Documentation Impact:
Some careful rewording of the existing language in CLtL is necessary in
the standard to avoid confusion between "keyword", indicating a symbol
in the KEYWORD package, and "keyword name", indicating a syntactic part
of a keyword parameter specifier. It is likely that this is best served
by changing those instances of "keyword" to "named argument" when the
specification is discussing the indicator which introduces an actual
parameter in a call to a function defined with &KEY.
The wording which refers to named arguments as being introduced by
keyword symbols would change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each named argument name must be a symbol.
The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.
Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as the names for named
arguments, and that all functions built into the Common Lisp language
follow that convention.
Examples would be useful. On p.64 the following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)
Cost to implementors:
Some implementors might have to rearrange their error checking slightly,
but it should be very easy.
Cost to users:
None--no existing programs will stop working.
Benefits:
This will help with the object-oriented programming standard, among
other things.
Aesthetics:
The restriction of &key to only keyword symbols is arbitrary and
unnecessary.
There will probably be an argument about whether the restriction is more
aesthetic or less aesthetic than the freedom, but in either case the
aesthetic effect is slight.
In any case, users who do not want to use the extended functionality can
generally avoid it.
Discussion:
The cleanup committee generally supports this extension.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but may be mistaken.
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.
∂14-Feb-88 1300 X3J13-mailer Issue: FUNCTION-TYPE (version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:00:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 12:55:41 PST
Date: 14 Feb 88 12:55 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 9)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
LINE-FOLD: NO
Message-ID: <880214-125541-1381@Xerox>
This is a difficult issue. The issue was discussed both at the June and November 1987 meetings. There seem to be strong opinions along several different dimensions.
This version of the issue writeup contains two different proposals.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
There are two proposals for dealing with this issue.
!
Proposal FUNCTION-TYPE:CONSERVATIVE
1. Introduce a new type PROCEDURE that can be used both for declaration
and discrimination.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE.
Implementations are free to define other subtypes of PROCEDURE.
1c. Introduce a new function, PROCEDUREP, such that
(PROCEDUREP x) == (TYPEP x 'PROCEDURE).
2. Define that a ``function'' may be a procedure, a list whose car is
the symbol LAMBDA, or any symbol (whether fbound or not).
2a. Clarify that the FUNCTION type behaves as if it had been
defined by:
(DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA)))
(DEFTYPE FUNCTION ()
`(OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE))
2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION).
This change is compatible.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify that FUNCALL and APPLY continue to accept functions
as arguments. However, some implementations may produce better
code for expressions such as (FUNCALL (THE PROCEDURE ...) ...)
or (APPLY (THE PROCEDURE ...) ...).
3. Clarify that the result of a FUNCTION special form must be a procedure.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE PROCEDURE (FUNCTION name)). As such, the potential
optimizations mentioned in 2e are also possible for
(FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(PROCEDUREP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error,
but they are also permitted to define useful (non-portable)
interpretations.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Implementations are permitted, but not required, to store
information about a global macro-function or special form
in the function cell. This definition of SYMBOL-FUNCTION
is intended to leave enough freedom for such implementations
to conveniently implement FUNCTION, SPECIAL-FORM-P, and
MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying
subprimitive.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function.
The function is coerced to a procedure before being called as the
expansion interface hook by MACROEXPAND-1.
!
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
STRICT-REDEFINITION is similar to CONSERVATIVE, except that it redefines
the type FUNCTION instead of adding a new type PROCEDURE, and it restricts
coercion by functions that take functions as arguments. The numbering of
CONSERVATIVE is preserved for comparison.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any PROCEDURE subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
with CAR = LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Change FUNCALL and APPLY such that they accept only a function
as the functional argument. This restriction is inherited by
all functions in Common Lispthat take a functional argument.
It is no longer legal to pass a symbol or lambda expression as
the functional argument to any of these functions; to do so
"is an error".
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound,
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).
5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.
5d. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type procedure.
6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
6b. (COERCE lambda-expression 'FUNCTION) is equivalent to
(EVAL `(FUNCTION ,lambda-expression)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the
expansion interface hook by MACROEXPAND-1.
!
Rationale:
Since the two proposals are similar, they are discussed together. Where
motiviation and justification differ, the proposals are referred to by
name (STRICT-REDEFINITION, CONSERVATIVE.)
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
CONSERVATIVE manages a compatible definition with most existing uses of
the term ``function'' while providing a graceful upgrade path to the term
``procedure'' for use in situations that call for a higher degree of clarity.
STRICT-REDEFINITION avoids introducing a new term at the cost of
incompatible change.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x).
In some implementations, (TYPEP x 'FUNCTION) is the same as what
CONSERVATIVE calls (TYPEP x 'PROCEDURE).
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations are likely to have exactly the
semantics described in either. CONSERVATIVE is more compatible with
current practice than STRICT-REDEFINITION, however.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations. While STRICT-REDEFINITION makes it an error to pass
non-function arguments to APPLY, FUNCALL etc, there is no requirement
to check for that error.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The conversion cost associated with CONSERVATIVE is very low because the
model of FUNCTIONP which it takes is largely consistent with existing
practice.
The new features introduced by CONSERVATIVE, particularly the PROCEDURE
data type, can be converted to fairly lazily.
The conversion cost for the STRICT-REDEFINITION proposal is higher. The
changes to FUNCTIONP and the FUNCTION type declaration is relatively easy
to deal with. However, the strict redefinition of FUNCALL, APPLY and
functional arguments will require the addition of an explicit coercion
would have to be added whenever a symbol or lambda expression is used as
a functional argument. Many such cases can be identified at compile time,
but not all.
Some implementations might provide tools to assist in detecting implicit
coercion of symbols to functions. For example, an implementation might add
run-time test in which the implementation still does the coercion but that
issues a warning message whenever the coercion is actually needed.
Alternatively, a "smart" code-walker or editor macro might find all of the
calls to FUNCALL, APPLY, and the 61 Common Lisp functions that take :TEST
or :KEY arguments and, if the argument is not already an explicitly quoted
FUNCTION form, wrap a COERCE around the body.
For either proposal:
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell might have to change. Such code was
already not portable, however, since some implementations signal an error
when this is done.
Benefits:
For CONSERVATIVE:
The term ``function'' would be given a useful meaning that was relatively
compatible with existing usage.
A new term ``procedure'' would be available for descriptional clarity.
The new PROCEDURE datatype would be useful for type discrimination in CLOS.
For STRICT-REDEFINITION:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
STRICT-REDEFINITION provides useful constraints which will be of aid
to systems doing automatic program analysis for the purpose of
``selective linking.'' Such tools may in turn make it possible to
reduce the total size of a delivered application program because
only those Common Lisp functions that are actually called need to be
included.
For either proposal:
The type hierarchy would be simplified.
Either proposal brings Common Lisp into closer alignment with Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with this proposal.
Aesthetics:
Both proposals improve the aesthetics of the language.
Discussion:
These proposals have been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. These two proposals are the distillation of the alternatives.
The CONSERVATIVE proposal offers the advantage of backward compatibility,
and considerably more flexibility in the language.
The STRICT-REDEFINITION proposal offers the advantage of a slightly cleaner
resulting language.
Some concerns were raised about STRICT-REDEFINITION in a previous discussion
about "late binding" of function definitions. Neither proposal disallows
late binding of symbols to functions. For example, in the call
(MAPCAR #'FROB my-list)
the effect of the FUNCTION special form (as generated by the #' read macro)
is to obtain the function definition of FROB at the time the #'FROB is
evaluated. Neither proposal changes this.
Currently, it is allowed to write
(MAPCAR 'FROB my-list)
while this form would no longer be allowed under the STRICT-REDEFINITION
clause. Currently, neither CLtL nor the CONSERVATIVE proposal addresses
the question of the time at which FROB's function definition is obtained;
if, during the processing of my-list, FROB is redefined, it is not clear
whether the processing of subsequent elements would be changed.
∂14-Feb-88 1328 X3J13-mailer Issue: PATHNAME-SYMBOL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:28:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:26:37 PST
Date: 14 Feb 88 13:26 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-132637-1426@Xerox>
My notes are unclear. This issue may have been distributed before.
!
Issue: PATHNAME-SYMBOL
References: PATHNAME (p.413),
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417), LOAD (p. 426), REQUIRE
Cleanup issue PATHNAME-STREAM
Common LispCraft, Wilensky 1986, p 51
Edit History: Version 1 by Moon 11-May-87
Version 2 by Masinter 29-May-87
Version 3 by Masinter 23-Oct-87
Version 4 by Masinter 23-Nov-87
Version 5 by Masinter 5-Feb-88, fix minor typo
Category: CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a pathname is
expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE, and RENAME-FILE) are
not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected. More specifically, PATHNAME,
TRUENAME, PARSE-NAMESTRING, MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE,
PATHNAME-DIRECTORY, PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING,
REQUIRE are changed by this proposal to not allow symbols for their pathname
argument.
Reiterate that OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, RENAME-FILE,
DELETE-FILE, FILE-WRITE-DATE, FILE-AUTHOR do not allow symbols for their file or
filename argument, and that DIRECTORY does not allow a symbol for its pathname
argument. This is implied by the respective descriptions of those functions in
CLtL, but not explicitly stated.
Rationale:
Allowing symbols for pathnames was based on an obsolete practice in MacLisp
(which did not have strings) and causes much error-prone behavior.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics doesn't
allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES, and allowing them
there is probably a bug in the implementation.
Cost to implementors:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation, no
implementation change is actually necessary.
Cost to users:
Some users might be using symbols as pathnames, in implementations where that
works, and they would have to switch to using strings. For example, some users
are used to typing interactively (LOAD 'FOO) to mean (LOAD "FOO"). This is not
explicitly allowed in CLtL, so such behavior has not been portable. However,
such use is probably widespread among users of implementations that allow it
(e.g., Common LISPCraft gives this form in an example.)
Benefits:
Pathname functions will be more consistent. In implementations that check the
type of this argument, program error checking will be improved. In dealing with
case-sensitive file systems, users won't do (load 'foo) and wonder why file
"FOO" (rather than "foo") is not found.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a table
entry that was expected to exist and returned -false-. In systems that accept
symbols as pathnames, this causes a reference to a file named "NIL" on some
perhaps unexpected directory.
Aesthetics:
Improved by the change.
Discussion:
Some users have reported that they thought MERGE-PATHNAMES was in error because
it accepted symbols.
We believe that this feature was accidentally introduced as a historical
artifact and that it has limited utility. It is likely that the feature of
accepting a symbol was copied by Common Lisp from Zetalisp, which in turn copied
it from Maclisp. The reason Maclisp allowed a symbol here was that it did not
have strings at all. While the feature was removed from Zetalisp before Common
Lisp was defined due to the poor state of Zetalisp documentation at the time the
change was overlooked by the designers of Common Lisp.
If a symbol can be coerced into a string, and a string can be coerced into a
pathname, why can't a symbol be coerced into a pathname? An explicit decision
was made early in the design of CL not to make all coercions transitive. For
example, symbols coerce to strings (for string functions), and strings are
sequences (and so can be mixed with other sequence types), but symbols are not
sequences.
There is some sentiment for extending COERCE to allow explicit coersion of
STRINGs to PATHNAMEs, as a separate cleanup item.
A careful reading of CLtL indicates that it is possible for an implementation to
allow a symbol to be a STREAM (there is no requirement that STREAM and SYMBOL be
disjoint.) While there is some sentiment for making this requirement in a
separate cleanup issue, it would otherwise prevent both symbol->pathname and
stream->pathname to have consistent meaning.
∂14-Feb-88 1338 X3J13-mailer Issue: PUSH-EVALUATION-ORDER (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:38:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:37:53 PST
Date: 14 Feb 88 13:37 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: PUSH-EVALUATION-ORDER (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-133753-1430@Xerox>
I believe this issue was not distributed before.
!
Issue: PUSH-EVALUATION-ORDER
References: CLtL p. 99 (generalized variables)
p. 270 (PUSH)
All macros that manipulate generalized variables
(SETF, PSETF, GETF, REMF, INCF, DECF, PUSH, PUSHNEW,
POP, CHECK-TYPE, ASSERT, CTYPECASE, CCASE, SHIFTF,
ROTATEF, and all macros defined by DEFINE-MODIFY-MACRO).
Issue SETF-FUNCTION-VS-MACRO.
Category: CLARIFICATION
Edit History: Version 1, 15-Oct-87, Jeff Peck
Version 2, 23-Oct-87, Larry Masinter
Version 3, 8-Nov-87, David Moon
Version 4, 14-Nov-87, Larry Masinter
Version 5, 25-Nov-87, Larry Masinter
Problem Description:
In the form (PUSH (ref1) (CAR (ref2))) It is unclear whether (ref1) should be
evaluated before (ref2).
CLtL, page 99, in a discussion of generalized variable macros, states:
"Macros that manipulate generalized variables must guarantee the `obvious'
semantics: subforms of generalized-variable references are evaluated ... in
exactly the same order as they appear in the *source* program. The expansion of
these macros must consist of code that follows these rules or has the same
effect as such code. This is accomplished by introducing temporary variables
bound to the subforms of the reference."
This paragraph and a discussion of SETF on the previous pages may also be
interpreted as requiring that *all* subforms of such macro calls should be
evaluated once, in source order, left to right.
However, CLtL, page 270 states:
"The effect of (PUSH Item Place) is roughly equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice while PUSH
takes care to evaluate them only once."
Place and Item appear in different order in the PUSH form and the indicated
equivalent SETF form. Should the PUSH form have primacy over the obvious SETF
form with respect to the left-to-right evaluation?
Are all subforms in a macro call guaranteed to be evaluated in order, or only
those subforms representing generalized variable references?
The same question arises for other forms which manipulate generalized variables,
e.g., PUSHNEW, INCF, DECF, and those defined with DEFINE-MODIFY-MACRO.
Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
This proposal is hard to state, although the intent is fairly clear: evalution
proceeds from left to right whenever possible. The left-to-right rule does not
remove the obligation on writers of macros and define-setf-method to ensure
left-to-right order, however.
In this proposal, a form is something whose syntactic use is such that it will
be evaluated. A "subform" means a form that is nested inside another form -- not
any object nested inside a form regardless of syntactic context.
(1) The evaluation ordering of subforms within a generalized variable reference
is determined by the order specified by the second value returned by
GET-SETF-METHOD. For all predefined generalized variable references (GETF, LDB),
this order of evaluation is exactly left-to-right. When a generalized variable
reference is derived from a macro expansion, this rule is applied *after* the
macro is expanded to find the appropriate generalized variable reference.
This is intended to make it clear that if the user writes a DEFMACRO or
DEFINE-SETF-METHOD that doesn't preserve order, the the order specified in the
user's code holds; e.g., given
(DEFMACRO WRONG-ORDER (X Y) `(GETF ,Y ,X))
that (PUSH <value> (WRONG-ORDER <place1> <place2>)).
will evaluate <place2> first and then <place1> because that is the order they
are evaluated in the macro expansion.
(2) For the macros that manipulate generalized variables (PUSH, PUSHNEW, GETF,
REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, SETF, POP, and those defined with
DEFINE-MODIFY-MACRO) the subforms of the macro call are evaluated exactly once
in left to right order, with the subforms of the generalized variable references
evaluted in the order specified in (1).
PUSH, PUSHNEW, GETF, REMF, INCF, DECF, SHIFTF, ROTATEF, PSETF, POP evaluate all
subforms before modifying any of the generalized variable locations. SETF (in
the case when the SETF macro has more than two arguments) performs its operation
on each pair in sequence, i.e., in (SETF <place1> <value1> <place2> <value2>
...), the subforms of <place1> and <value1> are evaluated, the location
specified by <place1> is modified to contain the value returned by <value1>, and
then the rest of the SETF form is processed in a like manner.
(3) For the macros CHECK-TYPE, CTYPECASE, and CCASE, subforms of the generalized
variable reference are evaluted once as in (1), but may be evaluted again if the
type check files in the case of CHECK-TYPE or none of the cases hold in
CTYPECASE and CCASE.
(4) For the macro ASSERT, the order of evaluation of the generalized variable
references is not specified.
(Rules 2, 3 and 4 cover all macros defined in Common Lisp that manupulate
generalized variable references.)
Examples:
(LET ((REF2 (LIST '())))
(PUSH (PROGN (PRINC "1") 'REF-1)
(CAR (PROGN (PRINC "2") REF2))))
Under this proposal, this would be required to print 12 and not 21.
(LET (X)
(PUSH (SETQ X (LIST 'A))
(CAR (SETQ X (LIST 'B))))
X)
; the PUSH first evalutes (SETQ X (LIST 'A)) => (A)
; then evaluates (SETQ X (LIST 'B)) => (B)
; then modifies the CAR of (this latest value) to be ((A) . B).
; The result is (((A) . B)).
Documentation impact:
PUSH should more appropriately be described as:
"(PUSH Item Place) is roughly equivalent to (SETF Place (CONS Item Place))
except that the subforms of Place are evaluated only once, and Item is evaluated
before Place."
The phase "subforms of the reference" which appears several times in CLtL should
be made more specific to be "subforms of the macro call," referring to the
entire form that calls the generalized-variable manipulating macro.
Rationale:
This is the unstated intention of the page 97-100 discussion of
generalized-variable referencing macros, and indeed the intended definition of
"obvious semantics" for all macros.
Current practice:
Many implementations do not currently follow this evaluation order. In the form
(PUSH Item Place), Lucid, Franz, Kyoto and Xerox evaluate Place then Item.
Symbolics evaluates Item then Place.
For example, in Franz:
(macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
In Symbolics Common Lisp, it returns:
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
Cost to implementors:
Minimal, PUSH etc. could simply be defined by the appropriate macros.
Cost to users:
No currently portable program should be affected. However, this is a minor
incompatible change for some implementations. No serious performance impact is
expected; while some macro expansions may appear to be more verbose, most
compilers deal reasonably with the required order of evaluation.
Benefits:
The implementation and semantics of PUSH become more well specified. This
removes a source of non-portability, abeit likely rare.
Esthetics:
Common Lisp defines order of evaluation as left-to-right; this clarification
ensures consistency across the language.
Discussion:
This seems to be the intent of most of the relevant language in CLtL.
For example, the second to last paragraph on page 99
"As an example of these semantic rules, in the generalized-variable reference
(setf reference value), the value form must be evaluated after all the subforms
of the reference because the value form appears to the right of them."
makes it clear that in this context the phrase "generalized-variable reference"
was meant to refer to the entire macro call, not just the Place, and that order
of evaluation rules are not limited to subforms of Places. We hope the
specification should adopt more consistent terminology.
Note that DEFINE-SETF-METHOD is immune to the exception specified about DEFMACRO
and DEFINE-SETF-METHOD, because since CLtL p.103 says about DEFINE-SETF-METHOD:
"This binding permits the body forms to be written without regard for
order-of-evaluation issues."
∂14-Feb-88 1352 X3J13-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:51:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:49:20 PST
Date: 14 Feb 88 13:49 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134920-1443@Xerox>
This issue is new.
!
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313)
Category: ADDITION
Edit history: Version 1 by Pierson 5-Dec-87
Version 2 by Pierson 30-Dec-87
Version 3 by Masinter 13-Feb-88
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword described as
follows:
If a :KEY argument is supplied, its value must be a function of one
argument which will be used to extract the values to reduce. The :KEY
function will be applied exactly once to each element of the sequence
in the order implied by the reduction order but not to the value of
the :INITIAL-VALUE argument, if any.
Example:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS))
If this proposal is adopted, the same result could be obtained without
creating a new list by:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
We know of no implementation which currently supports this feature.
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged in one way. All :KEY arguments are currently defined
to be used for predicates, this proposal will implicitly broaden :KEY
to support general extraction for any purpose.
Slightly improved in another way. Many common situations where REDUCE
could be used would be easier to write and easier to later read.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is some controversy over whether the "definition" of :KEY
arguments on page 246 of CLtL really constitutes a definition or just
an "unwritten rule".
∂14-Feb-88 1341 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:40:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:41:10 PST
Date: 14 Feb 88 13:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-134110-1441@Xerox>
This issue was distributed at the November 1987 meeting.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂14-Feb-88 1354 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 13:54:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 13:54:43 PST
Date: 14 Feb 88 13:54 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-135443-1454@Xerox>
This issue is new.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261)
Issue REMF-DESTRUCTURING-UNSPECIFIED
(discussion of NREVERSE, NSUBSTITUTE)
Issue AREF-1D
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
26-Oct-87, Version 3 by Masinter (clean up for release)
11-Nov-87, Version 4 by Masinter (respond to comments)
5-Feb-88, Version 5 by Masinter
Description:
Common Lisp provides many useful operations on lists and vectors which don't
apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can REPLACE
the contents of one vector with another, but one can't do this for arrays. One
can verify that EVERY element of a vector has some property, but one can't do
this for arrays, and so on.
The programmer who wishes to use arrays instead of vectors must give up most of
the useful tools CLtL provides for manipulating sequences, even though there is
no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work
on arrays.
Common Lisp already provides a facility called "displaced arrays" which can be
used to overlay one array on top of a portion of another, even if the two are of
different ranks, so that the two share storage or use the awkward convention of
creating a displaced array to the operand. However, creating a displaced array
merely to perform FILL, REPLACE or EVERY is awkward.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
1) Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays of
rank other than 1. These functions should treat array arguments as vectors
displaced to the array storage (in row-major format). The affected functions are
LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A
7) should return the same element as (AREF A 0 1 0). :START and :END keywords
would be interpreted relative to the vector, as would the results returned by
POSITION and SEARCH.
2) Extend the definitions of sequence functions whose result should be the same
shape as but not necessarily EQ to some argument. These functions should deal
with array arguments by returning an array of the same shape as the argument,
and operate on their argument in row-major order. The affected functions are
SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF,
SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP.
3) Sequence functions that modify the number of elements in the array remain
unchanged: it is an error to pass arrays of rank other than 1. (The functions
are not extended because the shape would be undefined.) The unaffected functions
are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE,
DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a sequence
function, and it already has a well-defined behavior for arrays. To test whether
the arrays A and B, of different shapes, have the same elements, one might
write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This is a useful upward compatible extension with relatively low adoption cost.
Cost to Implementors:
This would involve a lot of changes to functions, but all of the changes are
likely to be minor. The presence of displaced arrays in the language already
guarantees that the internal storage format needed to back up these proposed
changes is already in place.
Cost to Users:
This change is upward compatible; current user code should run unmodified.
Benefits:
This proposal adds natural support for multi-dimensional arrays. Currently,
users must write nested DO loops every time they want to perform an array
operation equivalent to FILL, REPLACE, REDUCE, etc., or else they build
displaced vectors by hand and pass them to the sequence functions when
necessary. With this proposal, users of arrays do not have to use home-grown
utilities to duplicate functionality already primitively provided to users of
arrays. The sequence functions become useful in a variety of new situations.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly avoiding
the temptation to turn Common Lisp into a half-baked APL. Instead of trying to
provide a full set of array handling primitives (which would be needed to take
arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an
operator across a specific dimension of a multidimensional array), it requires
just one rule:
treat arrays as displaced vectors where it is well-defined.
Current Practice:
We know of no current implementation of this proposal.
Discussion:
This issue was discussed by the cleanup committee at length; what follows is
only a brief summary of the discussion.
An alternative considered was to only affect those functions which didn't
explicitly depend on the shape of the array; that is, to modify COUNT, SOME,
EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and
expressly forbid arrays as arguments to other sequence functions, including
LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT,
MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES,
DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes
only those functions which do not deal with positional information. Some hedging
over REDUCE and FIND, which often have non-positional uses, were considered.
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been
building displaced vectors to pass to sequence functions when necessary and
really dislikes it.
We considered but discarded as unworkable an alternative where POSITION and FIND
might deal with "positions" as lists of array subscripts.
At one point, this proposal included an extension to COERCE to allow COERCE to
translate from array types to sequences, but it was thought better to separate
out COERCE. We considered a proposal to only introduce a change to COERCE, and
require users who want to operate on arrays explictly perform, e.g., (COUNT
item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost
but was deemed awkward.
Sequence functions like FILL and COUNT are already generalized to arrays in
non-Lisp contexts; in English we use the generalized forms all the time, e.g.,
"count the number of 1's in this matrix."
There is some concern that this proposal makes the requirement for row-major
ordering of internal storage for arrays even more evident. While such an
internal ordering is implied by the ability to create displaced arrays and the
AREF-1D proposal, this proposal adds yet another constraint.
The general reason for opposing this change is that it adds more mechanism than
it is worth. The general reason for liking it is that it adds generality at
little cost.
∂14-Feb-88 1408 X3J13-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:08:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:08:41 PST
Date: 14 Feb 88 14:08 PST
From: Masinter.pa@Xerox.COM
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140841-1482@Xerox>
This issue had not been distributed before.
!
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
References: #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
Category: CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 01-Mar-87
Version 2 by Masinter 10-Nov-87
Version 3 by Masinter 14-Nov-87
Problem Description:
No information is provided in the description of #+ and #- (pp. 358-359) about
what package the features are read on.
In some systems, the current package is used. Since there is no wording in CLtL
to the contrary, it's reasonable to assume that this would be done, but a
consequence of this is that you must be much more sensitive to the package
you're in at any given time when using #+ or #- even for system-provided
features. (This is a problem if the LISP package can contain only the symbols in
CLtL because system-provided features will likely not have the names of symbols
on LISP and hence will require package prefixes. Having a symbol named
LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like
#+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
some such, which might get a read error in a non-Symbolics implementation that
didn't export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is used. This means that
package prefixes are rarely necessary in sharpsign conditionals for
system-provided features regardless of the current package or restrictions about
what may be in LISP. (For example, the KEYWORD package can have any symbol so
it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*).
This has implications about what goes on the *FEATURES* list (p. 448).
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
Specify that the default package while reading feature specs is the keyword
package. Other packages may be designated by use of explicit package prefixes.
Symbols on *FEATURES* may be in any package but that in practice they will
mostly be on the keyword package because that's the package #+/#- uses by
default. If symbols in a package other than keyword appear on *FEATURES*, they
will be seen by #+/#- only if marked by explicit package prefixes in the
written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448
is KEYWORD.
Rationale:
Making the behavior of #+ and #- well defined is important for people writing
portable code that manipulate *FEATURES* directly.
Current Practice:
Some implementations bind *PACKAGE* while reading feature specs and others do
not.
Adoption Cost:
Changes to implementations to make them conform should be fairly minor if not
trivial.
Benefits:
As currently specified, using #+ and #- in truly portable code can have
bootstrapping problems, since it is sometimes required to conditionally set up
*FEATURES* in different ways for different systems.
Conversion Cost:
Few changes to user code will be required; code that uses #+ and #- will
continue to work, although code that manipulates *FEATURES* directly may require
editing.
Aesthetics:
Most users would perceive this as a bug fix either to CLtL or to certain
implementations.
Discussion:
The cleanup committee supports this proposal.
It might be reasonable to suggest that only vendors should add keyword symbols
to the *FEATURES* list, and that users should add features on their personal
packages so that collisions due to user applications were less likely. This idea
might be a subject of controversy though, so is not part of this proposal.
It would be useful to create a non-binding registry of feature names (and
package names) already in use, so that Lisp implementors could pick otherwise
unused feature names, and users who wanted to write portable code could know
what feature names were preferred.
∂14-Feb-88 1406 X3J13-mailer Issue: SHADOW-ALREADY-PRESENT (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:05:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:04:22 PST
Date: 14 Feb 88 14:03 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: SHADOW-ALREADY-PRESENT (version 4)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-140422-1472@Xerox>
This issue is new.
!
Issue: SHADOW-ALREADY-PRESENT
References: CLtL p.186
Category: CLARIFICATION/CHANGE
Edit history: Version 1 Moon 24 Aug 87
Version 2 Moon 27 Aug 87 incorporate JonL's suggestions
Version 3 Masinter 26-Oct-87
Version 4 Masinter 10-Nov-87
Problem description:
The description of the SHADOW function can be interpreted as saying that the
function has no effect, if the symbol is already present in the package. This
happens if the third sentence in the description ("then nothing is done") is
interpreted as applying to the entire description rather than just to the fourth
sentence.
SHADOW is said to take symbols as arguments, however only the print-name is
meaningful for this operation (that fact is already documented).
Proposal SHADOW-ALREADY-PRESENT:WORKS:
1) The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package.
2) The first argument to SHADOW is allowed to be or contain strings as well as
symbols. The specification "the print name of each symbol is extracted" is to be
modified accordingly.
Test Case:
;;; SHADOW always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
;;; list of a package
(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
(find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(export 'test-2::test (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1)) ;should not error
;;; To test the use of strings in place of symbols
;;; change the third line of the test case to
;;; (shadow "TEST" (find-package 'test-1))
;;; Note the use of capital letters in the string.
Rationale:
CLtL p. 180 describes a name conflict problem that can occur when calling the
function USE-PACKAGE. The name conflict is between a symbol directly present in
the using package and an external symbol of the used package. This name conflict
may be resolved in favor of the symbol directly present in the using package by
making it a shadowing symbol. For this to work, SHADOW must add the symbol to
the PACKAGE-SHADOWING-SYMBOLS list even when it is already present in the
package.
Since only the print name of a symbol argument is meaningful, a string should
also be accepted. This is particularly useful to avoid problems when compiling
code in one package environment and loading it into a slightly different package
environment, where the symbol that was referred to at compile time may not be
present at load time. This is particularly important because the symbol
referred to by the print name may be changed by evaluation of the SHADOW form.
A close reading of CLtL shows that one can already use (shadow '#:bar) in place
of (shadow 'bar), to achieve much the same effect as (shadow "BAR"). But the
user should not have to play such games, strings should be accepted.
Current practice:
Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS list,
even when the symbol is already present in the package. Kyoto Common Lisp,
Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the symbol is
already present in the package. It seems likely that we will find several
implementations in each camp.
SHADOW accepts strings in Symbolics Common Lisp.
Cost to implementors:
This should be a minor change to implementations that do not currently work this
way.
Cost to users:
Technically this would be an incompatible change to implementations that do not
already behave as proposed, however it is difficult to conceive of a user
program that would require any conversion to cope with the change. Some users
might want to remove kludges that were only necessary to get around the former
misbehavior of SHADOW.
Cost of non-adoption:
Inconsistency among implementations and lack of a clear way to resolve the name
conflict mentioned in Rationale.
Benefits:
Consistency among implementations and fewer mysterious package problems.
Esthetics:
The proposal would remove an unnecessary special case, thus simplifying the
language slightly.
Discussion:
The issue was raised by Dieter Kolb on the Common-Lisp mailing list.
It would be useless for SHADOW to fail to put a symbol that is already present
in the package onto the PACKAGE-SHADOWING-SYMBOLS list. Moon believes CLtL
intended to describe what is being proposed, but unfortunately used ambiguous
language.
The cleanup committee endorses this proposal.
∂14-Feb-88 1455 X3J13-mailer Common Lisp cleanup issue status to X3J13
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Feb 88 14:54:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 14:55:15 PST
Date: 14 Feb 88 14:54 PST
From: Masinter.pa@Xerox.COM
Subject: Common Lisp cleanup issue status to X3J13
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <880214-145515-1510@Xerox>
!
This is the list of issues distributed for the March 1988 X3J13 meeting:
- ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87)
(Interaction of ADJUST-ARRAY and displaced arrays)
- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)
- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87
- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc. to allow :KEY)
- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87
- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)
- DECLARE-MACROS (Version 3, 5-FEB-88)
(Disallow macros expanding into declarations.)
- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)
- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)
- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
- DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88)
(dribble can't be used programmatically)
- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)
- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)
- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
- FUNCTION-TYPE (Version 9, 13-Feb-88)
(Change definition of FUNCTIONP, function type ...)
- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.
- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87
- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87
- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)
- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)
(Add :KEY to REDUCE)
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
(Allow (DEFUN (SETF FOO) ..))
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)
- SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
(What does SHADOW do if symbol is already there?)
- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(*FEATURES* are in the keyword package)
!
The following issues were mailed prior to the June 1987 meeting and passed at
that meeting; they will not be distributed again except by request.
- COMPILER-WARNING-STREAM (Version 6, 5-Jun-87)
(Compiler warnings are printed on *ERROR-OUTPUT*)
Version 6 passed X3J13/Jun87
- DEFVAR-INIT-TIME (Version 2, 29-May-87)
(DEFVAR initializes when evaluated, not later.)
Version 2 passed X3J13/Jun87.
- DEFVAR-INITIALIZATION (Version 4, Jun-87)
((DEFVAR var) doesn't initialize)
Version 4 passed X3J13, Jun87.
- FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87)
(do FLETs have implicit named blocks around them?)
Version 6 passed X3J13/Jun87.
- FORMAT-ATSIGN-COLON (Version 4, 5-jun-87)
(@: == :@ in format)
Version 4 passed X3J13/Jun87.
- FORMAT-OP-C (Version 5, 11-Jun-87)
(What does ~C do?)
Version 5 passed X3J13/Jun87.
- IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87)
(Does IMPORT affect home package?)
Version 5 passed X3J13/Jun87.
- PRINC-CHARACTER (Version 3)
(PRINC behavior on character objections)
Version 3 passed X3J13/Jun87.
!
For your information only, the following issues are still under consideration by
the cleanup committee. Volunteers to help out with the preparation of issue
writeups are welcome. If you would like to review the mail discussion on a given
topic, please let me know and I will forward it to you.
- ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
Need volunteer to write up.
- CONSTANT-SIDE-EFFECTS (not yet submitted)
(It is an error to do destructive operations on constants in code,
defconstant.)
Discussed 12/86 - 1/87
Will take on if no compiler proposal
- DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted)
(Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be
required to be disjoint from other types?)
From CLOS committee, not yet submitted
- DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
- DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS)
(Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e.,
not a subclass.)
Useful after CLOS
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Mail 11-12 Oct 87 on common-lisp
Interacts with compiler proposal?
- DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file)
(p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to
have the same name. If structure A includes structure B, then no
additional slot of A may have the same name as any slot of B."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file)
(p 305) "The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Need volunteer to sort out DEFSTRUCT issues post-CLOS.
- EQUAL-STRUCTURE (not yet submitted)
(Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.)
What do EQUAL EQUALP and friends do
on structures?
(Need volunteer.
ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu,
Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU?)
- FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT)
(P 425) "Generalize FILE-LENGTH to accept any filename, not just
an open file-stream. Let it take a keyword argument :ELEMENT-TYPE,
defaulting to STRING-CHAR for non-stream arguments and to the
element-type of the stream for a stream argument."
Need volunteer to write up.
- FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal)
(What does FILE-WRITE-DATE do if no such file?)
"there should not be a formal proposal for fixing the file-write-date
ambiguity until we are at the point where we can make proposals
that discuss signalling named conditions. "
Need volunteer.
- FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal)
"format parameters are assumed to be non-negative integers except
as specifically stated"
Need volunteer.
- FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted)
(Change semantics of argument types in function declarations.)
- FUNCTION-SPECS (not yet submitted)
(add "function specs" for defun, trace etc)
beyond SETF-FUNCTION-VS-MACRO.
(SMH!franz@ucbarpa.berkeley.edu, JonL, RWK)
- GC-MESSAGES (version 1)
(Control over unsolicited GC messages in typescript)
merge with other controls for unsolicited messages?
- LAST-N (version 1, 4-DEC-87)
(Extend LAST to take an optional N)
Needs rewrite as per Moon
- LISP-SYMBOL-REDEFINITION (no formal proposal yet)
Is it legal to redefine symbols in the LISP package?
Mail 14-Aug-87
Merge with SPECIAL-FORM-SHADOW
Needs volunteer
- LOAD-TIME-EVAL (Versin 4, 2 Feb 88)
(evaluation when compiled file is loaded)
- MACRO-FUNCTION-ENVIRONMENT
(Add environment argument to MACRO-FUNCTION?)
re-extracted from ENVIRONMENT-ARGUMENTS
CLOS committee to submit?
- PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87)
How to deal with subdirectory structures in pathname functions?
make :DIRECTORY a list?
Need volunteer to rewrite.
- PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
Mail Aug 87 discussion
How to deal with logical devices, :unspecific components, etc
in pathname functions
RWK@YUKON.SCRC.Symbolics.COM may submit proposal.
- PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87)
(interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM)
"Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal
interaction must or even ought to work."
- PROCLAIM-LEXICAL (Version 5, 14-Nov-87)
(add LEXICAL, GLOBAL, CONSTANT proclaimation)
some serious problems
- PROMPT-FOR (Version 1)
(add new function which prompts)
Tabled until re-submitted.
- REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 )
(Specification of side-effect behavior in CL)
DEFINED, VAGUE and IN-BETWEEN
- REMF-MULTIPLE (Version 1, 26 Jan 88)
(What does REMF do if it sees more than one INDICATOR?)
- REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87)
(where does REQUIRE look for files?)
- REST-LIST-ALLOCATION (not yet submitted)
(APPLY #'LIST X) == (COPY-LIST X)?
need volunteer
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
- SETF-SUB-METHODS (version 1, 12-Feb-88)
(more careful definition of order of evaluation
inside (SETF (GETF ...) ...) )
- SHARPSIGN-PLUS-MINUS-NUMBER
(Is #+68000, #-3600 allowed?)
Mild disagreement: it is an error?
- SPECIAL-FORM-SHADOW (no formal proposal)
(Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
In discussion, no formal proposal submitted.
- SHARPSIGN-BACKSLASH-BITS
(What does C-META-H-X mean?)
Forwarded to character committee.
- STANDARD-INPUT-INITIAL-BINDING (Version 1, 19 Jan 88)
Move text of Test case/Example to Problem description.
Somewhere between completely undefining and current situation is
wanted.
- STREAM-CLASS-ACCESS (No formal proposal)
(Originally FOLLOW-SYNONYM-STREAM 19-DEC-86)
Define stream accessors as if synonym-stream two-way-stream etc
were CLOS classes?
Need volunteer
- STRUCTURE-DEFINITION-ACCESS (No formal proposal)
(access to slot accessors for DEFSTRUCT etc.)
Need volunteer to write up
- SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal)
(p 246) "Specify that it is an error for the SUBSEQ indices or any
:START or :END argument have a negative index or point past the end
of the sequence in question. (With respect to whether signalling is
required, this error will be treated the same as array
out-of-bounds.)"
Need volunteer to write up
- TAILP-NIL (no formal proposal yet)
(Operation of TAILP given NIL)
Needs writeup in current format.
- TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87)
(Allow trace for SETF functions, macros, etc.)
Environment extension?
- UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87)
(What happens with non-local exits out of UNWIND-PROTECT
cleanup clauses?)
- VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet)
CLtL says that vectors are extended by a "reasonable" amount. What's that?
∂16-Feb-88 1045 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 10:45:00 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 10:45:09 PST
Received: from sunvalleymall.lucid.com by edsel id AA03090g; Tue, 16 Feb 88 10:16:15 PST
Received: by sunvalleymall id AA28197g; Tue, 16 Feb 88 10:21:23 PST
Date: Tue, 16 Feb 88 10:21:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802161821.AA28197@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: March 1988 agenda questions
I would like to prepare the agenda next week.
If you have something that should be discussed or voted on at the
March meeting please let me know what it is, the Document number
(if any) and approximate time needed.
Thanks!
---jan---
∂16-Feb-88 2122 X3J13-mailer March 1988 agenda questions
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 21:22:35 PST
Received: by labrea.Stanford.EDU; Tue, 16 Feb 88 21:21:45 PST
Received: from bhopal.lucid.com by edsel id AA05999g; Tue, 16 Feb 88 21:07:02 PST
Received: by bhopal id AA02339g; Tue, 16 Feb 88 21:12:15 PST
Date: Tue, 16 Feb 88 21:12:15 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8802170512.AA02339@bhopal.lucid.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3J13@sail.Stanford.EDU
In-Reply-To: Jan Zubkoff's message of Tue, 16 Feb 88 10:21:23 PST <8802161821.AA28197@sunvalleymall.lucid.com>
Subject: March 1988 agenda questions
The four of us -- smh, rwk, jonl, and rg -- have an issue that needs more
time than a few minutes of cleanup committee covering: the extension of
names for definitions (sometimes referred to as "function specs"). Steve
(Haflich) has the problem description and issues written down, and Bob
(Kerns) has a proposed implementation. It would probably take 10 minutes
to present the issue, and conceivably would be met by 5-20 minutes of
unmitigated flaming from the floor after it is presented.
-- JonL --
∂23-Feb-88 1308 X3J13-mailer Re: voting
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 23 Feb 88 13:06:28 PST
Full-Name: Jim Antonisse
Message-Id: <8802232059.AA18904@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@A.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU, jima@mitre.arpa
Subject: Re: voting
In-Reply-To: Your message of 26 Jan 88 14:06:00 -0500.
<[A.ISI.EDU]26-Jan-88 14:06:48.MATHIS>
Date: Tue, 23 Feb 88 15:59:23 EST
From: jima@mitre.arpa
Bob,
Where exactly *is* the March X3j13 meeting? Does anyone
have details of location, registration fee, etc., figured
out yet? I'll be travelling for the week before it so I'd
like to make all arrangements soon.
Thanks,
Jim Antonisse
MITRE
∂23-Feb-88 1541 X3J13-mailer voting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 15:37:54 PST
Received: by labrea.Stanford.EDU; Tue, 23 Feb 88 14:57:40 PST
Received: from sunvalleymall.lucid.com by edsel id AA17257g; Tue, 23 Feb 88 14:09:49 PST
Received: by sunvalleymall id AA15130g; Tue, 23 Feb 88 14:15:41 PST
Date: Tue, 23 Feb 88 14:15:41 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802232215.AA15130@sunvalleymall.lucid.com>
To: jima@mitre.arpa
Cc: MATHIS@a.isi.edu, x3j13@sail.stanford.edu, jima@mitre.arpa,
edsel!jlz@labrea.Stanford.EDU
In-Reply-To: jima@mitre.arpa's message of Tue, 23 Feb 88 15:59:23 EST <8802232059.AA18904@mitre.arpa>
Subject: voting
I sent the original message on December 14 but it looks like it's time for
a reminder. Agenda, subcommitte meeting (that I have arranged) and voting
list to follow later this week.
---jan---
X3J13 Meeting and Subcommitte meetings
3/14/88 - 3/18/88
Palo Alto, CA
The next meeting of X3J13 will be held from 9:00am, Wednesday, March 16,
1988 until 5:00pm, Thursday, March 17, 1988, at the Hyatt Rickeys in Palo
Alto, CA. The meeting will be held in the Executive Conference Room.
Subcommittee meetings will be held Monday, March 14, Tuesday, March 15 and
Friday, March 18.
Please let me know if and when your subcommittee will be meeting in Palo
Alto in March. I need to reserve small rooms now if they're necessary. In
the interest of saving money, if you have a subcommittee member who is local
perhaps the meeting could be held at their company.
For example: the CLOS subcommittee will meet at Lucid
Monday, 3/14 and Tuesday 3/15 at 10:00. Friday's time is
yet to be determined.
A block of rooms is available at the Hyatt Rickeys. The rate will be $84 a
night (plus tax). A limited number of rooms are available for non-smokers.
Please call (800) 228-9000 or (415) 493-8000 before February 26 to receive
the discounted rate. Be sure to mention "X3J13 Standards Committee".
Before I call and get special airline fares I'd like to know if anyone has
found this to be useful. If I get no replies I'll assume it's not necessary
to set up special fares.
Refreshments will be available during the morning (8:00am) and afternoon
sessions. Lunch will be available Wednesday, March 16 and Thursday, March
17. If you have dietary restrictions please complete the appropriate
section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
I will be happy to arrange a group dinner for Wednesday, March 16. Someone
has suggested we go to Watercourse Way in Palo Alto for sushi dinner and go
hot tubbing afterwards at (combined fee of around $25) If interested, please
note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
|X Hyatt Rickeys |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
San Jose Airport
!
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rush hour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-8000. Hertz, Avis and National car rentals are
within 1 block.
Directions from San Jose airport: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real, Palo Alto, CA 94306 (415) 493-8000.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@labrea.stanford.edu
(415) 329-8400
!
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
*Feel free to bring check to meeting but please let me know if you will be
attending.
!
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Lunch 3/18: yes _______ no _______
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Sushi Dinner 3/16: yes ______ something else ______
Hot tubbing 3/16: yes ______ something else ______
Set up special airline fares: yes _______ no _______
Subcommittee Name: _________________________________________________
Subcommittee Chair: ________________________________________________
____ We need a meeting room
____ We will be meeting at _________________________________________
∂24-Feb-88 1139 X3J13-mailer X3J13 committee meeting agenda draft
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:49 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:24 PST
Received: from sunvalleymall.lucid.com by edsel id AA21834g; Wed, 24 Feb 88 10:49:37 PST
Received: by sunvalleymall id AA17034g; Wed, 24 Feb 88 10:55:36 PST
Date: Wed, 24 Feb 88 10:55:36 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241855.AA17034@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3J13 committee meeting agenda draft
DRAFT
X3J13 Committee Meeting Agenda
March 16 - 17, 1988
1 Call to Order, March 16, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis
- Introduction of attendees
- Report on ISO meeting, Dick Gabriel
- Future meetings and mailings, Jan Zubkoff
3 Approval of Agenda
4 Approval of Minutes
5 CLOS (Doc: 88-002, 88-003, 88-004), Dick Gabriel, Danny Bobrow, et.al.
6 Lunch, 12:00pm - 1:00pm
7 CLOS continuation
8 Recess, 5:00pm
9 Call to Order, March 17, 9:00am
10 Clean-up, Larry Masinter
11 Lunch
12 Status of Standard, Kathy Chapman; 1 hour
13 Function Specs, JonL White, Steve Haflich, Bob Kearns; 20 minutes
14 Condition System, Kent Pitman; 1 hour
15 Other committee reports
16 Adjournment, 5:00pm
∂24-Feb-88 1139 X3J13-mailer Subcommittee meetings
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:39:37 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:07 PST
Received: from sunvalleymall.lucid.com by edsel id AA21628g; Wed, 24 Feb 88 10:25:19 PST
Received: by sunvalleymall id AA16953g; Wed, 24 Feb 88 10:31:18 PST
Date: Wed, 24 Feb 88 10:31:18 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241831.AA16953@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: Subcommittee meetings
Here are the ones I know about.
---jan---
Monday, 3/14
9:00 -
9:30 -
10:00 - CLOS
10:30 - Gabriel
11:00 - Lucid
11:30 - |
12:00 - |
12:30 - |
1:00 - | Characher
1:30 - | Linden
2:00 - | Hyatt Iteration
2:30 - | Delmonte Room White
3:00 - | | Hyatt
3:30 - | | Regency Room
4:00 - | - |
4:30 - | |
5:00 - - -
5:30 -
6:00 -
Tuesday, 3/15
9:00 - Character Clean-up
9:30 - Linden Masinter
10:00 - Hyatt | CLOS
10:30 - Delmonte Room | Gabriel
11:00 - | | Lucid
11:30 - | | |
12:00 - | - |
12:30 - | |
1:00 - | Editorial |
1:30 - | Chapman |
2:00 - | Lucid |
2:30 - | | |
3:00 - | - |
3:30 - | |
4:00 - - |
4:30 - |
5:00 - -
5:30 -
6:00 -
Friday, 3/18
9:00 -
9:30 -
10:00 -
10:30 -
11:00 -
11:30 -
12:00 -
12:30 -
1:00 -
1:30 -
2:00 -
2:30 -
3:00 -
3:30 -
4:00 -
4:30 -
5:00 -
5:30 -
6:00 -
∂24-Feb-88 1140 X3J13-mailer voting at X3J13
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 11:40:23 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 11:01:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA22000g; Wed, 24 Feb 88 11:07:43 PST
Received: by sunvalleymall id AA17093g; Wed, 24 Feb 88 11:12:40 PST
Date: Wed, 24 Feb 88 11:12:40 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8802241912.AA17093@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: voting at X3J13
X3J13 VOTING LIST for March 1988 meeting
Bob's records indicate these groups were represented at the
indicated meetings. If they have paid their X3 service fees,
they can vote at the meeting in Palo Alto.
Company Name Cambridge Ft. Collins
-----------------------------------------------------------
A.I. Architectures x
Aerospace x
Alliant x
Bath U. x x
CSC x
DEC x x
Edinbrugh U. x x
Encore x
Evans and Sutherland x
Franz x x
Gensym x
Gigamos x x
GMD x
Goldhill x x
Gould x
Grumman x x
Hewlett Packard x x
Honeywell x x
IBM x x
ILOG S.A. x
INRIA x
Internat. Lisp Assoc. x
Johnson Controls x x
Lucid x x
Mathis x x
MCC x x
Micro. Sys. Consultants x
MIT x
Mitre x x
NBS x
Prime x
Red Shark Software x
Schlumberger x
Sun x
Symbolics x x
Tektronics x x
Texas Instruments x x
Thinking Machines x x
Unisys x x
USC-ISI x
Wang x
Xerox x x
∂28-Feb-88 1147 X3J13-mailer ISO meeting news
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 11:47:20 PST
Date: 28 Feb 1988 14:46-EST
Sender: MATHIS@A.ISI.EDU
Subject: ISO meeting news
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]28-Feb-88 14:46:29.MATHIS>
Hot news from the ISO-IEC/JTC 1/SC 22/WG 16 Lisp meeting in Paris
February 24-25, 1988.
The working group decided "The draft standard to be provided by
the Working Group within 18 months will take as starting point
COMMON LISP (with X3J13 cleanups) with treatment of major issues
and default values to be identified (including issues in the
AFNOR list and on the agenda)." They also decided on "ISLISP" as
the working name of the standard language.
There is considerable hope in both X3J13 and this ISO working
group that the results of their work match exactly (this will
require close cooperation).
∂01-Mar-88 1445 X3J13-mailer X3 attendee list to date
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:14 PST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:06:55 PST
Received: from sunvalleymall.lucid.com by edsel id AA06854g; Tue, 1 Mar 88 13:56:26 PST
Received: by sunvalleymall id AA00420g; Tue, 1 Mar 88 14:02:49 PST
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803012202.AA00420@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: X3 attendee list to date
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
---jan---
Registration Fees
03/01/88
Name Company Paid
Masayuki Ida Aoyama Gakuin University -
Gregor Kiczales Xerox PARC -
Bob Mathis -0- -
Daniel Bobrow Xerox PARC y
Kathy Chapman Digital Equipment y
Steve Haflich Franz, Inc. y
Kevin Layer Franz, Inc. y
Thom Linden IBM y
Jeff Rininger SRI International y
Thomas Turba UNISYS Corp y
Walter van Roggen Digital Equipment y
Paul Beiser HP -
Eric Benson Lucid, Inc. -
Jeff Dalton University of Edinburgh -
Linda DeMichiel Lucid, Inc. -
Jerry Duggan HP -
Dick Gabriel Lucid, Inc. -
David Moon Symbolics, Inc. -
Julian Padget University of Bath -
Mary Van Deusen IBM Research -
JonL White Lucid, Inc. -
∂02-Mar-88 1203 Common-Lisp-mailer Request to be added to mailing list...
Received: from potomac.ads.com by SAIL.Stanford.EDU with TCP; 2 Mar 88 12:03:39 PST
Received: by potomac.ads.com (5.58/1.7)
id AA11771; Wed, 2 Mar 88 15:04:38 EST
Date: Wed, 2 Mar 88 15:04:38 EST
From: John T. Nelson <jtn%potomac@potomac.ads.com>
Message-Id: <8803022004.AA11771@potomac.ads.com>
To: ansi-common-request@potomac.ads.com, common-loops-request@potomac.ads.com,
common-windows-request@potomac.ads.com
Subject: Request to be added to mailing list...
We would like to be added to your mailing list. Sorry if I'm repeating
myself but we've had a few problems with ARPAnet. Please send the
common-windows, common-loops and ansi-common lists to their respective
addresses at our machine:
post-common-loops@potomac.ads.com
post-ansi-common@potomac.ads.com
post-common-windows@potomac.ads.com
Thanks.
John T. Nelson UUCP: sun!sundc!potomac!jtn
Advanced Decision Systems Internet: jtn@potomac.ads.com
1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611
Strange... and beautiful music
∂02-Mar-88 1350 X3J13-mailer Re: X3 attendee list to date
Received: from venera.isi.edu by SAIL.Stanford.EDU with TCP; 2 Mar 88 13:50:06 PST
Received: from isd1.isi.edu by venera.isi.edu (5.54/5.51)
id AA07388; Wed, 2 Mar 88 13:50:51 PST
Posted-Date: Wed 2 Mar 88 13:50:45-PST
Received: by isd1.isi.edu (5.54/5.51)
id AA09581; Wed, 2 Mar 88 13:50:49 PST
Date: Wed 2 Mar 88 13:50:45-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 attendee list to date
To: edsel!jlz@labrea.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <573342645.0.OHLANDER@VENERA.ISI.EDU>
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Mail-System-Version: <SUN-MM(216)+TOPSLIB(128)@VENERA.ISI.EDU>
I will be attending the March meeting and will be having lunch on both
days. My registration and fee will follow shortly
Ron Ohlander
USC/ISI
-------
∂04-Mar-88 1440 X3J13-mailer X3J13 attendee list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:40:12 PST
Received: by labrea.Stanford.EDU; Fri, 4 Mar 88 14:01:57 PST
Received: from sunvalleymall.lucid.com by edsel id AA22425g; Fri, 4 Mar 88 14:23:43 PST
Received: by sunvalleymall id AA03806g; Fri, 4 Mar 88 14:30:22 PST
Date: Fri, 4 Mar 88 14:30:22 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803042230.AA03806@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu, paul%hpfclp@hplabs.hp.com
Subject: X3J13 attendee list
Please let me know if you have any additions/changes.
---jan---
X3J13 Attendee Information
03/04/88
Hot
Name Institute Paid L1 L2 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Kathy Chapman Digital Equipment y y y - -
Christopher Dabrowski NBS - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - - - y -
Jerry Duggan HP - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - y -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Ron Ohlander USC/ISI - y y - -
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
Guy Steele Thinking Machines, - y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
-------------------------------
10 25 24 17 6
∂07-Mar-88 1542 X3J13-mailer new and improved list
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 15:42:41 PST
Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 15:43:20 PST
Received: from sunvalleymall.lucid.com by edsel id AA04874g; Mon, 7 Mar 88 14:59:33 PST
Received: by sunvalleymall id AA09200g; Mon, 7 Mar 88 15:06:23 PST
Date: Mon, 7 Mar 88 15:06:23 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8803072306.AA09200@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: new and improved list
X3J13 Attendee Information
03/05/88
Lunches Sushi Hot
Name Institute Paid 3/16 3/17 Dinner Tub
David Bartley TI y y y - -
Paul Beiser HP - y y y -
Eric Benson Lucid, Inc. - - - y -
Daniel Bobrow Xerox PARC y y y y y
Skona Brittian MSC y y y y y
Kathy Chapman Digital Equipment y y y - -
Pavel Curtis Xerox PARC - y y - -
Christopher National Bureau of - y y - -
Jeff Dalton University of - y y y -
Linda DeMichiel Lucid, Inc. - y y y -
Jerry Duggan HP - y y - -
Patrick Dussud TI - y y - -
Dick Gabriel Lucid, Inc. - y y y -
Richard Greenblatt Gigamos - y y - -
Steve Haflich Franz, Inc. y - - - -
Masayuki Ida Aoyama Gakuin - y y y -
Sonya Keene Symbolics - y y - -
Gregor Kiczales Xerox PARC - y y y y
Kevin Layer Franz, Inc. y y y - -
Thom Linden IBM y - - - -
Barry Margolin Thinking Machines - y y - -
Larry Masinter Xerox PARC - y y - -
Bob Mathis -0- - y y y -
David Moon Symbolics, Inc. - y y - -
Jim O'Dell Gigamos - y y - -
Ron Ohlander USC/ISI y y y y y
Julian Padget University of Bath - y y - -
Crispin Perdue Sun Microsystems - - - y -
Dan Pierson Encore y y y y y
Kent Pitman Symbolics - y y y -
Jeff Rininger SRI International y y y - y
Eiji Shiota Nihon Symbolics - y y y y
David Slater Computer Sciences - y y - -
Guy Steele Thinking Machines, y y y y y
Thomas Turba UNISYS Corp y y y - m
Mary Van Deusen IBM Research - - - - -
Walter van Roggen Digital Equipment y y - y -
Ellen Waldrum TI - y y - -
JonL White Lucid, Inc. - - - y -
∂08-Mar-88 1121 X3J13-mailer Re: X3J13 attendee list
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Mar 88 11:21:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae25704; 8 Mar 88 13:12 EST
Received: from csc.ti.com by RELAY.CS.NET id ak03153; 8 Mar 88 13:05 EST
Received: from home by tilde id AA09943; Tue, 8 Mar 88 10:43:52 CST
Received: by home id AA08325; Tue, 8 Mar 88 10:43:27 CST
Date: Tue, 8 Mar 88 10:43:27 CST
From: Ellen Waldrum <waldrum@home.csc.ti.com>
Message-Id: <8803081643.AA08325@home>
To: edsel!jlz@LABREA.STANFORD.EDU, paul%hpfclp@hplabs.hp.com,
x3j13@SAIL.STANFORD.EDU
Subject: Re: X3J13 attendee list
Jan,
I forgot. I will be going to dinner as well. BTW, David Bartley from TI
will be attending. I know he tried to send you a message.
-- Ellen
∂08-Mar-88 1339 X3J13-mailer X3 attendee list to date
Received: from HAL.CAD.MCC.COM ([128.62.1.126]) by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:38:22 PST
Date: Tue, 8 Mar 88 15:11 CST
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: X3 attendee list to date
To: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
cc: x3j13@sail.stanford.edu, Loeffler@MCC.COM
In-Reply-To: <8803012202.AA00420@sunvalleymall.lucid.com>
Message-ID: <19880308211108.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
Date: Tue, 1 Mar 88 14:02:49 PST
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Please let me know if your name isn't listed below and you are
attending the March meeting. I also need to know whether you
will be having lunch 3/16 and/or 3/17.
Add:
David D. Loeffler MCC
I have made all my travel arrangements. I will be having lunch on 3/16
and 3/17. I will pay on Wednesday.
-- David D. Loeffler
∂19-Mar-88 1821 X3J13-mailer last meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:21:52 PST
Date: 19 Mar 1988 21:21-EST
Sender: MATHIS@A.ISI.EDU
Subject: last meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:21:18.MATHIS>
Thanks to all of you who participated in last week's meeting. I
think we had a very productive meeting. The results will be in
the minutes and reports from the various committees. The
committees are really working.
I have also noticed that some of you have already begun sending
out comments relative to last weeks discussions. Keep those
cards and letters coming.
Thanks, Bob
∂19-Mar-88 1844 X3J13-mailer minutes 3/88 mtg
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 18:44:21 PST
Date: 19 Mar 1988 21:43-EST
Sender: MATHIS@A.ISI.EDU
Subject: minutes 3/88 mtg
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]19-Mar-88 21:43:46.MATHIS>
Minutes of the X3J13 Meeting, Palo Alto, March 16, 17, 1988.
Wednesday, March 16
09:00 am Item 1, 2a, 2b., 3, 4.
Item 1. 2a. Call to Order. Bob Mathis
Item 2b. Introduction of attendees. Attendees list.
Item 4. Approval of minutes
Item 3. Approval of agenda.
Item 2d. Attendees were reminded to keep discussions short so that
entire agendas could be covered.
The method of distribution for backup will be netmail with
the following exceptions: documents which are too large for
netmail will be mailed, documents will be available in hard
copy at the meeting, and arrangements will attempt to be made
for those people requesting hard cover mailings.
Cambridge, June 13-17. Committee mtg Wed, Thur.
Washington, October, Committee mtg Wed, Thur.
Hawaii, Jan.
09:10 am. Item 2c.
Item 2c. Report on ISO meetings, Paris, Feb 24-25, 1988. Dick Gabriel.
Countries participating were: Canada, Commission of the
European Community, Denmark, France, Germany, Japan,
Netherlands, Switzerland, UK, and US. Position of each
country presented, demonstrating wide diversity of opinion.
US Delegation included Dick Gabriel (project editor), Bob
Mathis, Will Clinger (project editor), Patrick Dussud, Larry
Masinter, Kent Pitman, Thom Linden, and John McCarthy.
Votes were taken which Dick Gabriel stated to the ISO group
had to be tentative on his part since he wished to come back
to this group for advice.
1. Majority vote was to concentrate first on a short-term
standard.
2. Some characteristics of the standard, by preference:
portable, efficient, clear semantics and simple semantics.
3. Most popular departure points were Common Lisp, Scheme,
and Eulisp.
4. The majority vote was for the name ISLISP.
5. Responsibilities were distributed. US volunteered
documents, rather than volunteers, for OOP, Functions,
Macros, Multiprocessing, Character Set, Windows,
Conditions, Iteration. Bob Mathis emphasized to X3J13 that
individuals could volunteer.
10:30 am Break
10:45 am Item 5
Item 5 (Doc: 88-002, 88-003, 88-004), Guy Steele.
Chapter 1 and 2.
The purpose of having an implementation result being undefined
was shown to be that of having the result be undocumented so
that a user could not rely on the result (for example, use of
multiple ELSE in an IF).
JonL White expressed concern that the use of the name "symbol
class" would continue a direction, which he considered
misguided, on nomenclature on symbol-value. A broader
question was raised as one reply that CLOS committee could
not address the entire issue of nomenclature in Common Lisp.
Expressed concerns: voting on chapters 1 and 2 separate from
3; voting on chapters 1 and 2 without knowing how it fits
into CLTL; voting at this meeting rather than waiting until
reply from written comments integrated into chapters 1 and 2;
defining a continuing mechanism (ie. cleanup committee) for
continuing changes to chapters 1 and 2); defining a new
subcommittee to define the layering of Common Lisp.
12:10 pm Item 6 Lunch
1:00 pm Item 7 CLOS Continuation
The following motion was moved and unanimously passed:
X3J13 and the CLOS Subcommittee agree on the following:
1. X#J13 members will read and give comments on Document
88-002 (Chapters 1 and 2 of the CLOS Specification) by April
21, 1988. Comments can be sent via electronic mail to:
common-lisp-object-system@sail.stanford.edu
2. The CLOS Subcommittee will consider all comments, prepare
a revised draft of Chapters 1 and 2, and prepare a written
summary of how they addressed the comments. These documents
will be distributed to X3J13 members in advance of the June
X3J13 meeting.
3. At the June meeting, the X3J13 Committee will vote
whether or not to accept Chapters 1 and 2 out of the CLOS
Subcommittee.
Vote of thanks to the CLOS Subcommittee for their
work was moved and unanimously passed.
Chapter 3.
Gregor Kiczales presented a summary of the status of the
Metaobject Protocol (Chapter 3 of the CLOS Specification
88-003).
Moved by Barry Margolin, seconded by Dan Bobrow.
Approve the general direction of the Metaobject Protocol of
CLOS (as specified in 88-003), and recommend that the Object
Subcommittee continue working on this with an eye toward a
new draft prior to the fall meeting with the expectation that
we would then have a one month written comment period prior
to the winter meeting followed by a vote to move it out of
subcommittee at the winter meeting. Motion passed
unanimously by voice vote.
2:30 pm Afternoon break
2:40 pm Item 10
Item 10 Cleanup, Larry Masinter.
Moved and passed by voice vote 10-7: To postpone the vote on
the bundled cleanup issues until tomorrow morning.
Bundled Issues:
ADJUST_ARRAY_DISPLACEMENT
APPEND_DOTTED
AREF_1D
ASSOC_RASSOC_IF_KEY
COLON_NUMBER
DEFVAR_DOCUMENTATION
DISASSEMBLE_SIDE_EFFECT
DO_SYMBOLS_DUPLICATES
DRIBBLE_TECHNIQUE
FLET_DECLARATION
FORMAT_COMMA_INTERVAL
FORMAT_COLON_UPARROW_SCOPE
FUNCTION_TYPE_KEY_NAME
GET_SETF_METHOD_ENVIRONMENT
KEYWORD_ARGUMENT_NAME_PACKAGE
PATHNAME_STREAM
PATHNAME_SYMBOL
PUSH_EVALUATION_ORDER
REDUCE_ARGUMENT_EXTRACTION
SHADOW_ALREADY_PRESENT
SHARPSIGN_PLUS_MINUS_PACKAGE
Unbundled Issues to be separately considered:
COMPILER_WARNING_BREAK
DECLARE_MACROS
FUNCTION_TYPE_REST_LIST_ELEMENT
FUNCTION_TYPE
SETF_FUNCTION_VS_MACRO
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS
Larry Masinter led a discussion of cleanup issues which were
not sent to members prior to this meeting. For back mail on
a particular issue, send to:
masinter.pa@xerox.com.
Otherwise, see:
cl-cleanup@sail.stanford.edu.
05:05 pm Item 8 Meeting adjourned
Thursday, March 17
09:00 am Item 9
Item 9 Call to Order. Bob Mathis
09:15 am Item 10
Item 10 Cleanup, Larry Masinter
Moved by Dave Slater and seconded by Dan Pierson that the
bundled cleanup issues be accepted in a single vote and
the unbundled cleanup issues be accepted on separate votes.
The motion passed by unanimous voice vote.
COMPILER_WARNING_BREAK - A majority voice vote and a majority
company vote rejected the addition of COMPILER_WARNING_BREAK.
DECLARE_MACROS - Cris Perdue moved and Dick Gabriel seconded
a motion to stop discussion of DECLARE_MACROS. The motion
was passed by majority company vote. A majority company vote
accepted the addition of DECLARE_MACROS.
FUNCTION_TYPE_REST_LIST_ELEMENT - JonL White moved and Barry
Margolin seconded to table the previous motion to accept
FUNCTION_TYPE_REST_LIST_ELEMENT. The motion passed by
company vote 16-7.
FUNCTION_TYPE - Unanimous straw vote showed a belief that
redefinition of some type was necessary (FUNCTION_TYPE).
Unanimous straw vote showed that some change was needed
rather than the status quo. Majority (all but 2) straw vote
showed sentiment was against the conservative proposal.
Majority straw vote passed to not accept 2E as written, but
rather to amend 2E so that FUNCALL and APPLY can accept
anything that can be coerced to a function. A straw vote by
company was called to accept 6B. The straw vote passed
(14-7-4). Barry Margolin moved and Jim Antonisse seconded to
table the previous motion to accept FUNCTION_TYPE and to ask
the subcommittee to resubmit FUNCTION_TYPE with changes in
line with the straw votes. The motion passed (20-1-3). Dick
Gabriel moved and Dan Pierson seconded that the conservative
proposal be immediately accepted. This was unanimously
rejected by company vote (0-25-0).
11:15 pm Break
11:30 pm General comments
SETF_FUNCTION_VS_MACRO - As agreed yesterday, this issue is
tabled until after the function specification report.
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS - The motion to generalize
SEQUENCE_FUNCTIONS_EXCLUDE_ARRAYS passed (15-6-3). Dick
Gabriel moved and Dan Pierson seconded that the discussion be
reopened. The motion passed by majority company vote. David
Moon moved to call the question to a vote to generalize SEQ
... The vote was rejected (3-18-3).
12:15 pm Item 11 Lunch
01:15 pm Item 12
Item 12 Status of Standard, Kathy Chapman
After describing the phases of document preparation, concern
was expressed whether an early version of the document would
be available or whether the cost in time and money would make
an early version impractical. A straw vote unanimously
passed to require members wishing to review the document to
specifically ask for the document and pay for duplication and
mailing. Kathy has been asked for a more detailed plan for
distribution and review at the next meeting.
02:00 pm Status of Scheme Standard, David Bartley
Scheme standardization is under consideration in a
microprocessor group of IEEE. This umbrella is also working
toward the standardization of MODULA/2, SMALLTALK, FORTH,
and PILOT.
02:15 pm Item 15
Item 15 Other committee reports
MACRO SUBCOMMITTEE REPORT, Julian Padget
There has been no subcommittee meeting since the last X3J13
meeting. Two people responded to a request for interesting
macros. Julian reiterated his request and also asked for new
volunteers. Send any information to:
padget@maths.bath.ac.uk
CHARACTER SUBCOMMITTEE REPORT, Thom Linden
A detailed proposal was presented of the work done to date.
Several strawvotes presented moderate support for the
direction of parts of the proposal.
03:20 pm Break
03:30 pm Announcements, Bob Mathis
03:35 pm Item 15 (cont.)
Item 15 ITERATION SUBCOMMITTEE REPORT, Jon L. White
The status of LOOPS and the work being currently done in OSS
was described. Pavel Curtis discussed ITERATE and GATHERING.
Concern was expressed with the concept of the iteration
constructs being "portable, optional".
COMPILER SUBCOMMITTEE REPORT, Steve Haflich
Steve described a model to be used to figure out what a compile
file does.
04:35 pm Item 14
Item 14 Condition System, Andy Daniels
Comments have stopped so version 18 of proposal seems
stabilized. Open issues are still open but can be completed
as cleanup. Straw vote showed that the directions are right
and that the proposal should be presented for acceptance at
the June meeting. Volunteers are requested to flesh out
specification.
05:00 pm Item 13
Item 13 Function Specs, JonL White
JonL described the overview and goals of the specifications. A
proposal is forthcoming. Unanimous straw vote to encourage
the subcommittee to continue its work and to present a
proposal.
05:35 am Item 10 (cont.)
Item 10 Cleanup, Larry Masinter
SETF_FUNCTION_VS_MACRO - Unanimous straw vote showed that
discussion should be closed. Dan Pierson moved and Guy Steele
seconded the motion to table SETF... The motion passed by a
majority voice vote. Committee thanked Larry Masinter for
bringing forward these issues in such good condition and
Larry thanked his subcommittee.
06:00 Item Adjournment
Minutes submitted by Mary S. Van Deusen (March 17, 1988)
∂21-Apr-88 0708 X3J13-mailer X3J13 Meeting 6/13 - 6/17/88
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 07:08:00 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386470; Thu 21-Apr-88 10:07:49 EDT
Received: by scrc-pegasus id AA00636; Thu, 21 Apr 88 09:48:40 est
Date: Thu, 21 Apr 88 09:48:40 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting 6/13 - 6/17/88
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at
The Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston,
∂21-Apr-88 0829 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 08:29:47 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386565; Thu 21-Apr-88 11:29:22 EDT
Received: by scrc-pegasus id AA01353; Thu, 21 Apr 88 11:19:00 est
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting
Cc: bouzane@scrc-pegasus
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
Please let me know if sub committee meetings are necessary so
conference room arrangements can be made. There is a possibility
that sub committees could use three (3) conference rooms at
Symbolics (one holds 15 people, the other two hold 10 people).
However, I would need to know as soon as possible how many sub
committee meetings there will be in a given day, how many people
in each meeting each day and what days. If Symbolics' conference
rooms are used this would reduce the individual cost.
A block of rooms have been put aside for our use at the
Guest Quarters Suite Hotel; the rate will be $140 for single
occupancy and $160 for double occupancy. Please call Reservations
at the Hotel (617) 783-0090 before May 12, 1988 to receive this rate.
Be sure to mention "X3J13 Standards Committee". A one night
deposit is required. All registered guests are offered a
complementary American Breakfast (this is a full breakfast) daily
in the Scullers Grille Restaurant (in the Hotel). In addition, all
registered guests are invited to attend the night manager's discount
cocktail reception at the Mezzanine Bar. Please note, if you choose
not to take advantage of these features, the breakfasts and receptions
are not refundable nor may they be substituted for any other meal or
function.
Refreshments will be available during the morning and afternoon sessions.
A deli lunch will be available on June 15 and 16 (assorted cold cuts,
potato salad, cole slaw, condiments, relishes, bread/rolls, coffee, tea,
soda, juices, fresh fruit) at the Hotel where the 15th and 16th's
meetings are being held. If any has a dietary restriction please
let me know.
The cost per person for food service and conference room rental is
$64.90. However, this will be reduced if the sub committee meetings
can be held at Symbolics. Only after everyone returns the registration
form will I be able to determine if the cost will remain at $64.90 or
if it will be reduced. A subsequent announcement will be sent with
regard to this once all forms are in and at that time a check will
be due.
Please let me know if you would like to schedule a group dinner,
suggestions are welcomed.
Also, if you wish, we are working with a national travel agent who
would be happy to help in acquiring lower faries by trying to
group people together. Please let me know your proposed travel
if you want to try our travel agent.
Directions from Logan Airport, Boston to the Guest Quarters Suite
Hotel:
The Guest Quarters Suite Hotel is located at the Allston/Cambridge
exit of the Massachusetts Turnpike, minutes from downtown Boston and
Cambridge. Since the Hotel does not offer a shuttle service your
best mode of transportation from the airport is by taxi. For your
convenience, some taxi rates are listed below.
From Logan Airport $12.20
From Local Bus Stations 8.00
From Train - South Station 7.00
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambrdige Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPATURE FROM/DATE/TIME:
AIRLINE PREFERENCE
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂21-Apr-88 0908 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 09:08:11 PDT
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 386634; Thu 21-Apr-88 12:07:44 EDT
Received: by scrc-pegasus id AA01584; Thu, 21 Apr 88 11:38:19 est
Date: Thu, 21 Apr 88 11:38:19 est
From: Rosemary Bouzane <bouzane@scrc-pegasus>
To: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu
Subject: X3J13 Meeting
Cc: bouzane@scrc-pegasus
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
Please let me know if sub committee meetings are necessary so
conference room arrangements can be made. There is a possibility
that sub committees could use three (3) conference rooms at
Symbolics (one holds 15 people, the other two hold 10 people).
However, I would need to know as soon as possible how many sub
committee meetings there will be in a given day, how many people
in each meeting each day and what days. If Symbolics' conference
rooms are used this would reduce the individual cost.
A block of rooms have been put aside for our use at the
Guest Quarters Suite Hotel; the rate will be $140 for single
occupancy and $160 for double occupancy. Please call Reservations
at the Hotel (617) 783-0090 before May 12, 1988 to receive this rate.
Be sure to mention "X3J13 Standards Committee". A one night
deposit is required. All registered guests are offered a
complementary American Breakfast (this is a full breakfast) daily
in the Scullers Grille Restaurant (in the Hotel). In addition, all
registered guests are invited to attend the night manager's discount
cocktail reception at the Mezzanine Bar. Please note, if you choose
not to take advantage of these features, the breakfasts and receptions
are not refundable nor may they be substituted for any other meal or
function.
Refreshments will be available during the morning and afternoon sessions.
A deli lunch will be available on June 15 and 16 (assorted cold cuts,
potato salad, cole slaw, condiments, relishes, bread/rolls, coffee, tea,
soda, juices, fresh fruit) at the Hotel where the 15th and 16th's
meetings are being held. If anyone has a dietary restriction please
let me know.
The cost per person for food service and conference room rental is
$64.90. However, this will be reduced if the sub committee meetings
can be held at Symbolics. Only after everyone returns the registration
form will I be able to determine if the cost will remain at $64.90 or
if it will be reduced. A subsequent announcement will be sent with
regard to this once all forms are in and at that time a check will
be due.
Please let me know if you would like to schedule a group dinner,
suggestions are welcomed.
Also, if you wish, we are working with a national travel agent who
would be happy to help in acquiring lower fares by trying to
group people together. Please let me know your proposed travel
if you want to try our travel agent.
Directions from Logan Airport, Boston to the Guest Quarters Suite
Hotel:
The Guest Quarters Suite Hotel is located at the Allston/Cambridge
exit of the Massachusetts Turnpike, minutes from downtown Boston and
Cambridge. Since the Hotel does not offer a shuttle service your
best mode of transportation from the airport is by taxi. For your
convenience, some taxi rates are listed below.
From Logan Airport $12.20
From Local Bus Stations 8.00
From Train - South Station 7.00
Please feel free to contact me if you have any questions:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambridge Center
Cambridge, MA 02142
(617) 621-7611
Bouzane@SCRC.Symbolics.Com
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambrdige Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPARTURE FROM/DATE/TIME:
AIRLINE PREFERENCE:
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂21-Apr-88 1242 X3J13-mailer X3J13 Meeting
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Apr 88 12:42:02 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 21 Apr 88 15:20:11 EDT
Received: by kali.think.com; Thu, 21 Apr 88 15:20:07 EDT
Date: Thu, 21 Apr 88 15:20:07 EDT
From: gls@Think.COM
Message-Id: <8804211920.AA20298@kali.think.com>
To: bouzane@scrc-pegasus.arpa
Cc: Symbolics@scrc-pegasus.arpa, x3j13@sail.stanford.edu,
bouzane@scrc-pegasus.arpa
In-Reply-To: Rosemary Bouzane's message of Thu, 21 Apr 88 11:19:00 est <8804211540.AA01439@Think.COM>
Subject: X3J13 Meeting
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus.arpa>
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
I hope they use Scotch tape--thumbtacks in his chest will make him
scream with pain. :-)
(Actually, I *think* that's a typo, though "marquis" and "marquee"
do happen to be etymologically related.)
--The Pedantic Quux
∂21-Apr-88 1306 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 13:06:26 PDT
Received: from HARPAGORNIS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 387047; 21 Apr 88 16:05:18 EDT
Date: Thu, 21 Apr 88 16:04 EDT
From: Tom Parmenter <parmenter@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 Meeting
To: gls@Think.COM, stupid@STONY-BROOK.SCRC.Symbolics.COM, bouzane@PEGASUS.SCRC.Symbolics.COM
cc: x3j13@sail.stanford.edu
In-Reply-To: <8804211920.AA20298@kali.think.com>
Message-ID: <19880421200448.3.PARMENTER@HARPAGORNIS.SCRC.Symbolics.COM>
Date: Thu, 21 Apr 88 15:20:07 EDT
From: gls@Think.COM
Date: Thu, 21 Apr 88 11:19:00 est
From: Rosemary Bouzane <bouzane@scrc-pegasus.arpa>
X3J13 MEETING
JUNE 13, 1988 - JUNE 17, 1988
The next meeting of X3J13 will be held from 8:00 a.m., Monday,
June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
in Boston, MA. The conference room location will be posted
on the marquis.
I hope they use Scotch tape--thumbtacks in his chest will make him
scream with pain. :-)
(Actually, I *think* that's a typo, though "marquis" and "marquee"
do happen to be etymologically related.)
--The Pedantic Quux
Silly boy, it is the Marquis de Sade and he wanted it that way,
with the thumbtacks.
∂21-Apr-88 1352 X3J13-mailer X3J13 Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Apr 88 13:52:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 387207; Thu 21-Apr-88 16:52:15 EDT
Date: Thu, 21 Apr 88 16:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 Meeting
To: X3J13@SAIL.Stanford.EDU
cc: Symbolics@PEGASUS.SCRC.Symbolics.COM
In-Reply-To: <8804211920.AA20298@kali.think.com>,
<19880421200448.3.PARMENTER@HARPAGORNIS.SCRC.Symbolics.COM>
References: The message of 21 Apr 88 12:38 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 12:19 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 10:48 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>,
The message of 21 Apr 88 12:19 EDT from Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>
Message-ID: <880421165144.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Rosemary Bouzane's inclusion of Symbolics@Pegasus in her messages about
the X3J13 meeting was not really appropriate since most of the recipients
on that list are not involved with X3J13. As such, I'm sure it would
be greatly appreciated by several hundred people if you would NOT cc
that address in any further replies to her message. Send your replies
only to
Bouzane@Pegasus.SCRC.Symbolics.COM
and/or X3J13@SAIL.Stanford.EDU
as appropriate. (And, of course, any replies to this message should
go just to me privately.) Thanks very much.
∂22-Apr-88 0114 X3J13-mailer X3J13 Meeting
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Apr 88 01:14:33 PDT
Received: from en-c06.prime.com by RELAY.CS.NET id ab23998; 21 Apr 88 17:20 EDT
Received: from S51.Prime.COM by EN-C06.Prime.COM; 21 Apr 88 16:25:32 EDT
Received: from ENX.Prime.COM by S51.Prime.COM; 21 Apr 88 16:26:34 EDT
Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA22731; Thu, 21 Apr 88 16:21:09 EDT
Received: by zaphod.prime.com (3.2/SMI-3.2)
id AA08727; Thu, 21 Apr 88 16:26:28 EDT
Date: Thu, 21 Apr 88 16:26:28 EDT
From: Douglas Rand <doug@zaphod.prime.com>
Message-Id: <8804212026.AA08727@zaphod.prime.com>
To: x3j13@SAIL.STANFORD.EDU
Subject: X3J13 Meeting
>> The next meeting of X3J13 will be held from 8:00 a.m., Monday,
>> June 13, 1988 until 5:00 p.m., Friday, June 17, 1988 at the
>> Guest Quarters Suite Hotel (formerly the Embassy Suites Hotel)
>> in Boston, MA. The conference room location will be posted
>> on the marquis.
> I hope they use Scotch tape--thumbtacks in his chest will make him
> scream with pain. :-)
>
> (Actually, I *think* that's a typo, though "marquis" and "marquee"
> do happen to be etymologically related.)
I can't resist; since the meeting is in Boston (and with Guy's thumbtacks
to boot) does this make him the "Marquis De Scrod"?
Doug
∂25-Apr-88 1415 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 14:15:35 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 14:15:19 PDT
Received: from sunvalleymall.lucid.com by edsel id AA05247g; Mon, 25 Apr 88 14:03:46 PDT
Received: by sunvalleymall id AA13882g; Mon, 25 Apr 88 14:05:18 PDT
Date: Mon, 25 Apr 88 14:05:18 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804252105.AA13882@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: June Meeting addendum and varia
Meeting times for the June meeting:
6/13, 6/14 Monday and Tuesday Subcommittee meetings
6/15, 6/16 Wednesday and Thursday Committee Meeting 9:00 - 5:00
6/17 Friday Subcommittee meetings if necessary
Please let Rosemary know by this Friday, April 29 if you need a
room for a subcommittee meeting. Please let her know:
- name of subcommittee
- date needed
- starting and ending time
- approximately how many people will be attending
If she doesn't hear from you this week she will release the rooms.
We've set the fee for registration at $60.
***We are 2 weeks from subcommittee mailing time. Remember the
committee needs to have material in their hands 2 weeks before
the meeting or we can't legally vote.
***Looking ahead, I need a quick head count from those of you who
are seriously thinking about attending the joint X3J13/ISO
meeting in Hawaii in January. Please reply this week, I need to
book the hotel next week.
Thanks.
---jan---
Spring Meeting:
Where: Guest Quarters Suite Hotel
Sub Committee Meetings: 6/13 - 6/14, 6/17 if needed
Committee Meeting: 6/15 - 6/16
Contact: Rosemary Bouzane 617/621-7611
bouzane@scrc.symbolics.com
Fall Meeting:
Where: Contel, 12015 Lee Jackson Highway, Fairfax, VA
Subcommittee Mtgs: 10/10 - 10/11 in Contel Technical Center
Committee Meeting: 10/12 - 10/13 in Contel Auditorium
Contact: Bob Mathis 703/359-0203
mathis@b.isi.edu
Winter Meeting, Joint with ISO:
Where: Kauai, Hawaii
Subcommittee Meetings: 1/17 - 1-18
Committee Meeting: 1/19 - 1/20
Contact: Jan Zubkoff 415/329-8400
edsel!jlz@labrea.stanford.edu
∂25-Apr-88 1830 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 18:30:01 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 18:30:08 PDT
Received: from bhopal.lucid.com by edsel id AA06559g; Mon, 25 Apr 88 18:24:58 PDT
Received: by bhopal id AA29363g; Mon, 25 Apr 88 18:26:52 PDT
Date: Mon, 25 Apr 88 18:26:52 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804260126.AA29363@bhopal.lucid.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
re: ***We are 2 weeks from subcommittee mailing time. Remember the
committee needs to have material in their hands 2 weeks before
the meeting or we can't legally vote.
I hope this is "4 weeks from subcommittee mailing time", not 2 weeks. Two
weeks before the meeting is May 31, and that is 5 weeks from now. Certainly
there is a lot of work that the cleanup committee will be doing "soon", but
will probably not finish in 2 weeks.
-- JonL --
∂25-Apr-88 1937 X3J13-mailer X3J13 Meeting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 19:36:46 PDT
Received: by labrea.Stanford.EDU; Mon, 25 Apr 88 19:36:57 PDT
Received: from bhopal.lucid.com by edsel id AA06593g; Mon, 25 Apr 88 18:28:41 PDT
Received: by bhopal id AA29416g; Mon, 25 Apr 88 18:30:39 PDT
Date: Mon, 25 Apr 88 18:30:39 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804260130.AA29416@bhopal.lucid.com>
To: bouzane@scrc.symbolics.com
Cc: sun!clam!loop-groop@labrea.Stanford.EDU, mathis@a.ISI.EDU,
edsel!jlz@labrea.Stanford.EDU
Cc: Symbolics@scrc-pegasus, x3j13@sail.stanford.edu, bouzane@scrc-pegasus
In-Reply-To: Rosemary Bouzane's message of Thu, 21 Apr 88 11:38:19 est <8804211745.AA18145@edsel.lucid.com>
Subject: X3J13 Meeting
The Iteration subcommittee will need a room in which to meet; I suspect
that 2-5PM on Monday would be fine. We will be under 10 persons.
-- JonL --
∂26-Apr-88 0848 X3J13-mailer June Meeting addendum and varia
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 08:48:48 PDT
Received: by labrea.Stanford.EDU; Tue, 26 Apr 88 08:48:52 PDT
Received: from sunvalleymall.lucid.com by edsel id AA09556g; Tue, 26 Apr 88 08:44:00 PDT
Received: by sunvalleymall id AA15756g; Tue, 26 Apr 88 08:45:36 PDT
Date: Tue, 26 Apr 88 08:45:36 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804261545.AA15756@sunvalleymall.lucid.com>
To: edsel!jonl@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jon L White's message of Mon, 25 Apr 88 18:26:52 PDT <8804260126.AA29363@bhopal.lucid.com>
Subject: June Meeting addendum and varia
I'm allowing 1 week slippage, 2 weeks mailing time and 2
weeks for folks to read it.
---jan---
∂27-Apr-88 0100 X3J13-mailer June Meeting addendum and varia
Received: from altura.Honeywell.COM by SAIL.Stanford.EDU with TCP; 27 Apr 88 00:59:30 PDT
Return-Path: <hadden@src.honeywell.com>
Received: by altura.Honeywell.COM (5.52/smail2.1/05-12-87)
id AA25025; Tue, 26 Apr 88 16:05:08 CDT
Posted-Date: Tue, 26 Apr 88 16:04:08 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA25662; Tue, 26 Apr 88 16:04:08 CDT
Date: Tue, 26 Apr 88 16:04:08 CDT
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8804262104.AA25662@pavo.src.honeywell.com>
To: edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
hi jan, i'm planning to attend the hawaii meeting!
-geo
∂27-Apr-88 0104 X3J13-mailer June Meeting addendum and varia
Received: from altura.Honeywell.COM by SAIL.Stanford.EDU with TCP; 27 Apr 88 01:04:11 PDT
Return-Path: <hadden@src.honeywell.com>
Received: by altura.Honeywell.COM (5.52/smail2.1/05-12-87)
id AA24730; Tue, 26 Apr 88 13:53:07 CDT
Posted-Date: Tue, 26 Apr 88 13:52:08 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA23512; Tue, 26 Apr 88 13:52:08 CDT
Date: Tue, 26 Apr 88 13:52:08 CDT
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8804261852.AA23512@pavo.src.honeywell.com>
To: @CIM-VAX.HONEYWELL.COM:edsel!jlz@labrea.Stanford.EDU
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 25 Apr 88 14:05:18 PDT <8804252105.AA13882@sunvalleymall.lucid.com>
Subject: June Meeting addendum and varia
hi jan, i'm planning to attend the hawaii meeting!
-geo
∂28-Apr-88 1315 X3J13-mailer mail to bouzane for June X3 meeting
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Apr 88 13:15:31 PDT
Received: by labrea.Stanford.EDU; Thu, 28 Apr 88 13:15:40 PDT
Received: from sunvalleymall.lucid.com by edsel id AA02684g; Thu, 28 Apr 88 12:54:12 PDT
Received: by sunvalleymall id AA01699g; Thu, 28 Apr 88 12:55:58 PDT
Date: Thu, 28 Apr 88 12:55:58 PDT
From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
Message-Id: <8804281955.AA01699@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: mail to bouzane for June X3 meeting
For those of you not able to reply to Rosemary's message try:
bouzane@symbolics.com
∂10-May-88 1438 X3J13-mailer X3J13 June Meeting
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 10 May 88 14:37:53 PDT
Received: from VIRGINIA-RAIL.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256317; Tue 10-May-88 16:55:36 EDT
Date: Tue, 10 May 88 16:56 EDT
From: Rosemary Bouzane <bouzane@PEGASUS.SCRC.Symbolics.COM>
Subject: X3J13 June Meeting
To: x3j13@sail.stanford.edu
cc: x3j13@PEGASUS.SCRC.Symbolics.COM, bouzane@PEGASUS.SCRC.Symbolics.COM
Message-ID: <"19880510205606.1.bouzane@PEGASUS"@VIRGINIA-RAIL.SCRC.Symbolics.COM>
REMINDER - Deadline for room reservations at the Guest
Quarters Suite Hotel is MAY 12.
Below is registration form - it needs to be completed
ASAP.
The following is the schedule for Subcommittee Meetings:
6/13 - Monday: 2:00-5:00-Iteration Committee
@ Symbolics, Inc.
Eleven Cambridge Center
Cambridge
BONAIRE Conference Room
6/14 - Tuesday: 10:00-5:30-CLOS Committee
@ Symbolics, Inc.
Same address as above
BONAIRE Conference Room
1:00-5:30-Editorial Sub Committee
@ Symbolics, Inc.
Same address as above
ST. CROIX Conference Room
3:00-5:30-Definition Specs Group
@ Symbolics, Inc.
Same address as above
BERMUDA Conference Room
*******************************************************************
X3J13 JUNE MEETING REGISTRATION FORM
Please mail to:
Rosemary Bouzane
Symbolics, Inc.
Eleven Cambridge Center
Cambridge, MA 02142
(617) 621-7611
NAME:
INSTITUTION:
STREET ADDRESS:
CITY: STATE: PHONE:
NET ADDRESS:
SUBCOMMITTEE NAME:
NEED CONFERENCE ROOM FOR SUBCOMMITTEE MEETING:
DATE OF SUBCOMMITTEE MEETING:
NUMBER OF PEOPLE INVOLVED IN SUBCOMMITTEE MEETING:
WOULD LIKE A GROUP DINNER? YES NO
SUGGESTIONS:
TRAVEL ARRANGEMENTS:
PROPOSED DEPARTURE FROM/DATE/TIME:
AIRLINE PREFERENCE:
FREQUENT FLYER #:
PROPOSED RETURN TO/DATE/TIME:
∂10-May-88 2005 X3J13-mailer Re: June Meeting
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 10 May 88 20:05:10 PDT
Received: from en-c06.prime.com by RELAY.CS.NET id ab17213; 10 May 88 19:20 EDT
Received: from primerd.prime.com by EN-C06.Prime.COM; 10 May 88 18:36:00 EDT
Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA01488; Tue, 10 May 88 18:37:12 EDT
Received: by zaphod.prime.com (3.2/SMI-3.2)
id AA08611; Tue, 10 May 88 18:37:30 EDT
Date: Tue, 10 May 88 18:37:30 EDT
From: Douglas Rand <doug@zaphod.prime.com>
Message-Id: <8805102237.AA08611@zaphod.prime.com>
To: x3j13@SAIL.STANFORD.EDU
Subject: Re: June Meeting
Cc: bouzane@SCRC-PEGASUS.ARPA
>> REMINDER - Deadline for room reservations at the Guest
>> Quarters Suite Hotel is MAY 12.
>> Below is registration form - it needs to be completed
>> ASAP.
Can the list of people already registered be posted?
Cheers,
Doug (doug@zaphod.prime.com)
∂16-May-88 1119 X3J13-mailer agenda items please
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88 11:18:26 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 11:18:29 PDT
Received: from sunvalleymall.lucid.com by edsel id AA25724g; Mon, 16 May 88 11:07:51 PDT
Received: by sunvalleymall id AA28345g; Mon, 16 May 88 11:10:53 PDT
Date: Mon, 16 May 88 11:10:53 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805161810.AA28345@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: agenda items please
If you have something that should be listed on the agenda please
let me know what it is and estimate how long you'll need.
Thanks.
---jan---
∂19-May-88 1621 X3J13-mailer mailing deadline approaches
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 19 May 88 16:21:42 PDT
Received: by labrea.stanford.edu; Thu, 19 May 88 16:21:53 PDT
Received: from sunvalleymall.lucid.com by edsel id AA12251g; Thu, 19 May 88 15:59:23 PDT
Received: by sunvalleymall id AA11292g; Thu, 19 May 88 16:02:38 PDT
Date: Thu, 19 May 88 16:02:38 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805192302.AA11292@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: mailing deadline approaches
Documents need to be in committee hands by June 1 in order to vote on them at
the June 15-16 meeting. To meet this deadline documents should mailed by
Monday, 5/23. If you don't have your mailing labels yet please call Bob
Mathis ASAP.
---jan---
∂23-May-88 1640 X3J13-mailer June agenda draft
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 16:40:19 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 16:40:43 PDT
Received: from sunvalleymall.lucid.com by edsel id AA02178g; Mon, 23 May 88 16:25:52 PDT
Received: by sunvalleymall id AA02202g; Mon, 23 May 88 16:29:25 PDT
Date: Mon, 23 May 88 16:29:25 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805232329.AA02202@sunvalleymall.lucid.com>
To: x3j13@sail.stanford.edu
Subject: June agenda draft
Please let me know if there are any changes or additions.
---jan---
X3J13 Committee Meeting Agenda DRAFT
June 15 - 16, 1988
1 Call to Order, June 15, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
6 Character Subcommittee Report, Thom Linden (20 minutes)
7 Iteration Subcommittee Report, Jonl White (15 minutes)
8 Definition Specs Proposal, Jonl White (30 minutes)
9 Lunch, 12:00pm - 1:00pm
10 CLOS discussion and vote (Doc: 88-002R, 88-003R), Danny Bobrow et.al.
11 Recess, 5:00pm
12 Call to Order, June 16, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Other committee reports
16 Adjournment, 5:00pm
∂30-May-88 1838 X3J13-mailer mailing list and next meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 30 May 88 18:38:41 PDT
Date: 30 May 1988 18:33-PDT
Sender: MATHIS@A.ISI.EDU
Subject: mailing list and next meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]30-May-88 18:33:39.MATHIS>
Dear X3J13 members and observers:
This letter is a last minute reminder about the upcoming meeting
in Boston and a revalidation of our mailing lists.
You should receive two copies of this letter -- one electronic
and one physical. Our electronic mailing list is at x3j13@
sail.stanford.edu. If you did not receive a copy of this letter
through that means, please notify x3j13-request@sail.stanford.
edu. That is the primary means of communication within this
committee. If you do are not able to access electronic mail,
please notify me at the address on the letterhead. If you did not
receive a physical copy of this letter, please notify me at
Mathis@a.isi.edu.
If you wish to remain on the physical mail distribution list and/
or maintain your membership status on X3J13 you must reply to
this letter (either electronically, by physical mail, or by
attending the upcoming meeting in Boston). The cost of physical
mailings has become substantial. The committee is moving into a
stage where more formal voting will take place and I must be sure
about the membership and fee payment status of each participant.
At the meeting in Boston we will be voting on the final version
of the CLOS documents. These are being physically mailed to you
separately. We will also be considering language issues which are
being distributed electronically (hard copies will be available
in Boston). We will also be considering reports from the
iteration, errors and conditions, character set, editorial, and
other subcommittees. Hard copies of the documents will be
available there. With the exception of the CLOS vote we will be
operating in the kind of "committee of the whole" status we have
been using.
If you have not already made your arrangements for the Boston
meeting (which will be June 13-17), please contact Rosemary
Bouzane, Symbolics, Inc., Eleven Cambridge Center, Cambridge, MA
02142, (617) 621-7611. I will be out of town the week proceeding
the meeting. An alternate contact is Jan Zubkoff, Lucid, 707
Laurel St., Menlo Park, California 94025, (415)329-8400.
Thank you,
Robert F. Mathis
Chairman, X3J13
∂02-Jun-88 1614 X3J13-mailer 88-007
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Jun 88 16:14:52 PDT
Received: by labrea.stanford.edu; Thu, 2 Jun 88 16:15:16 PDT
Received: from bhopal.lucid.com by edsel id AA02715g; Thu, 2 Jun 88 16:13:01 PDT
Received: by bhopal id AA27781g; Thu, 2 Jun 88 16:11:01 PDT
Date: Thu, 2 Jun 88 16:11:01 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806022311.AA27781@bhopal.lucid.com>
To: x3j13@sail.stanford.edu
Subject: 88-007
Document 88-007 on The LOOP Facility (James Bond Edition?) is intended to
be a draft proposal for specification of the MIT-style LOOP. I cobbled its
text from Lucid documentation, which is being made available to X3J13 free
of any encumbrances. Unfortunately, some mechanically-generated copyright
notice still crept into one page; it should simply be disregarded.
A number of good comments and suggestions for changes have already come in
on this proposal. I will continue to update the text accordingly [unless
and until the editorial committee wants to take it over].
-- JonL --
∂07-Jun-88 1559 X3J13-mailer Issue: FUNCTION-TYPE (version 11)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jun 88 15:59:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUN 88 15:59:26 PDT
Date: 7 Jun 88 15:59 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 11)
line-fold: NO
Message-ID: <880607-155926-1276@Xerox>
Due to a combination of circumstances, I've been unable to work on cleanup activities. The
committee has proceeded admirably, but I've been behind in summarizing. Since I've been behind,
any decisions made at X3J13 will be preliminary. I will bring some hardcopy of these issues to
the meeting.
However, the issue FUNCTION-TYPE was discussed at length at the last X3J13. This version is our
attempt to recast it according to the wishes expressed at the last meeting.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
24-May-88, Version 11 by van Roggen
(don't coerce lists, relax SYMBOL-FUNCTION reqs)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, correcting a few typos, changing section 2E as
agreed upon at X3J13 March 1988, allowing symbols but not lists to
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
requirements.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
whose CAR is LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. Clarify FUNCALL and APPLY and all Common Lisp functions that
take functional arguments such that they accept objects that
are coerceable to a FUNCTION as the functional argument. It
is an error if the functional argument is not coerceable to a
FUNCTION.
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that FBOUNDP must return true for a symbol naming a macro or
a special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
It is an error to set the SYMBOL-FUNCTION of a symbol to a
symbol or a list or the value returned by SYMBOL-FUNCTION on
the name of a macro or a special form.
5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
6b. Implementations are free to extend the set of objects which
are coerceable to a FUNCTION, particularly lambda-expressions
for compatibility. However, such extensions will not be portable.
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the expansion interface hook by
MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional
arguments.
For compatibility reasons symbols are still acceptable to FUNCALL et al.,
but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
and whose CADR is a list) are no longer acceptable.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or as some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
The original STRICT-REDEFINITION proposal required users to deal with
the use of symbols and lambda-expressions as functional arguments. However
this proposal is compatible with current CLtL definition in the use of
symbols, which would be the hardest change to make. There are probably
relatively few uses of lambda-expressions as ``functions'', which can
be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and the
work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
(LET ((COUNTER 0))
(TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
since it is not the same as
(LET ((COUNTER 0))
(TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
which does pass around a closure incrementing the LET variable.
(These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
∂08-Jun-88 1211 X3J13-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:11:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:07:56 PDT
Date: 8 Jun 88 12:07 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
Line-fold: NO
Message-ID: <880608-120756-2864@Xerox>
!
Issue: ADJUST-ARRAY-FILL-POINTER
References: ADJUST-ARRAY (p297)
Category: CLARIFICATION
Edit history: 15-Mar-88, Version 1 by Pitman
Problem Description:
CLtL does not specify clearly the effect of ADJUST-ARRAY on the fill
pointer.
Proposal (ADJUST-ARRAY-FILL-POINTER:MINIMAL):
Clarify that the :FILL-POINTER keyword argument to ADJUST-ARRAY is treated
as follows...
If :FILL-POINTER argument is not given, then the fill-pointer of the array
to be adjusted (if any) is left alone. It is an error to adjust an array
to a size smaller than its fill pointer without specifying the :FILL-POINTER
option so that its fill-pointer is properly adjusted in the process.
If supplied, the :FILL-POINTER argument must be either an integer between 0
and the new size of the array, the symbol T (indicating that the new size
of the array should be used), or the symbol NIL (indicating that the fill
pointer should left as it is -- as if the :FILL-POINTER option had not been
specified).
An error is signalled if a non-NIL value for :FILL-POINTER is supplied and
the array to be adjusted does not already have a fill pointer.
Test Case:
(SETQ A1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ A2 (ADJUST-ARRAY A1 4))
(FILL-POINTER A1) => 3
(FILL-POINTER A2) => 3
(SETQ B1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ B2 (ADJUST-ARRAY B1 2 :FILL-POINTER 1))
(FILL-POINTER B1) => 1
(FILL-POINTER B2) => 1
(SETQ C1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T))
(SETQ C2 (ADJUST-ARRAY C1 2 :FILL-POINTER T))
(FILL-POINTER C1) => 2
(FILL-POINTER C2) => 2
(SETQ D1 (MAKE-ARRAY 5 :ADJUSTABLE T))
(SETQ D2 (ADJUST-ARRAY D1 2 :FILL-POINTER 2)) signals an error.
(SETQ E1 (MAKE-ARRAY 5 :FILL-POINTER T :ADJUSTABLE T))
(SETQ E2 (ADJUST-ARRAY E1 4)) is an error.
Rationale:
This behavior must be more clearly defined if portable programs are going
to be able to depend on it.
Current Practice:
Symbolics Lisp implements the proposal. In case "E", it does not signal an
error. It simply leaves the illegal fill-pointer in place so that the
programmer can correct it using (SETF (FILL-POINTER E2) ...)
Cost to Implementors:
Probably most implementations do not deviate significantly from the proposed
behavior. The cost to implementors is probably very slight.
Cost to Users:
None. This clarifies a fuzzy area in the manual which users cannot currently
depend upon.
Cost of Non-Adoption:
The interaction between ADJUST-ARRAY and fill-pointers would continue to be
hazy, and portable programs would not be able to rely upon that behavior
being consistent across implementations.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
There is little if any aesthetic impact of this change.
Discussion:
Pitman volunteered to write this issue up for the Cleanup committee. He's
not very passionate about the details one way or another, but figures it's
a good idea that they be clarified.
The cleanup committee didn't object.
∂08-Jun-88 1237 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:25:42 PDT
Date: 8 Jun 88 12:25 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <880608-122542-2920@Xerox>
There's been no discussion (and no objections) to this issue.
!
Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
References: CLtL 33-35 (data types)
CLtL 312 (DEFSTRUCT :INCLUDE option)
Category: CHANGE
Edit history: 24-Mar-88, version 1 by Steele
Problem description:
The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With
the arrival of CLOS, lack of disjointness will be inconvenient because one
cannot reliably use generic function dispatch on these types.
Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
Remove the third and antepenultimate bulleted items from section 2.15 is
CLtL and replace with the following:
* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
Also, in the discussion of the DEFSTRUCT :INCLUDE option, explicitly forbid
the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
RANDOM-STATE.
Rationale:
It would be useful to extend sequence functions to operate on streams
or hash tables, for example, through the CLOS generic function mechanism.
This is not possible under the current specification.
Current practice:
Some implementations in effect use DEFSTRUCT to define data structures
such as hash tables and random-states.
Cost to Implementors:
Small or nonexistent. The main reason this disjointness was not specified
in CLtL was the possibility that structures might not be easily
distinguishable: a stupid concern over a slight efficiency. This
implementation freedom apparently has not been exploited in practice.
Cost to Users:
None.
Cost of non-adoption:
CLOS will be less useful.
Benefits:
CLOS will be more useful.
Esthetics:
This makes the type system simpler and easier to understand.
Discussion:
This suggestion originated in the CLOS committee.
∂08-Jun-88 1244 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 12:44:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:39:58 PDT
Date: 8 Jun 88 12:39 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
Subject: Issue: DECLARATION-SCOPE (Version 2)
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Message-ID: <880608-123958-2954@Xerox>
There was significant discussion of this issue in the cleanup committee after
Version 2 was distributed, but no revision of the proposal has been produced.
This DRAFT is for your information and discussion at the June X3J13 meeting, but
it is not in final form.
!
Status: DRAFT
Issue: DECLARATION-SCOPE
References: Section 9.1 (pp. 153-157).
Cleanup issue FLET-DECLARATIONS.
Category: CHANGE
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Version 2, Moon, 2-Feb-1988 (edits based on discussion)
Problem description:
The description of the scope of declarations made with DECLARE is both
unclear (although unambiguous) and arguably a mistake. The issue is
whether the scope of some or all of the declarations includes code
appearing in the non-body part of the special form containing the
declaration.
Proposal DECLARATION-SCOPING:LIKE-VARIABLE:
For the purposes of this proposal, we divide all declarations introduced
with DECLARE into two classes. When a declaration of a variable appears
before the body of a special form or lambda-expression that binds that
variable, the declaration is called `bound'. All other declarations
are called `free'. This division replaces the division into pervasive,
nonpervasive, and SPECIAL declarations appearing in CLtL.
The scope of a `bound' declaration is exactly the scope of the
associated lexical variable or function. If the declaration is
associated with a special variable, the scope is the scope the variable
would have had if it had not been special.
`Free' declarations are scoped as if they appeared in a new LOCALLY form
which surrounded the entire special form at the beginning of whose body
the declaration appears. This is the same as what CLtL p.155 defines to
be the scope of `pervasive' declarations.
The following is a complete listing of the types of declarations and
their class (`bound' or `free'):
SPECIAL declarations may be either `bound', affecting both a binding and
references, or `free', affecting only references, depending on whether
the declaration is attached to a variable binding, as described above.
TYPE declarations may only be `bound' (see next section).
FTYPE and FUNCTION declarations may only be `free' (see next section).
INLINE declarations may only be `free' (see next section).
NOTINLINE declarations may only be `free' (see next section).
IGNORE declarations may only be `bound'.
OPTIMIZE declarations may only be `free'.
The `free' or `bound' scoping of implementation-dependent declaration
specifiers is implementation-dependent.
Interactions with other proposals:
There has been some discussion in X3J13 of permitting `free' TYPE
declarations. This is a semantic issue, not a scoping issue, and should
be treated independently.
If Common Lisp is extended to permit declarations in FLET and LABELS
forms, by acceptance of cleanup proposal FLET-DECLARATIONS:ALLOW,
then declarations of functions (FTYPE, FUNCTION, INLINE, and
NOTINLINE) which appear before the body of a FLET or LABELS form which
defines that function are `bound'. Such declarations in other contexts
remain `free'.
Common Lisp is ambiguous about whether a variable may be bound several
times by a single form. It has been proposed that multiple bindings be
permitted for LET*, DO*, PROG* forms and for &AUX variables in lambda
expressions. If multiple bindings are permitted, `bound' declarations
are treated as if there were a separate `bound' declaration for each of
the bindings.
Examples:
;;; Some examples of `free' and `bound' declarations.
(let ((a 1))
(declare (optimize speed)) ;this is a `free' declaration
(let ((b 2))
(declare (type integer b)) ;this is a `bound' declaration
(declare (special a)) ;this is a `free' declaration
()))
;;; This example applies if you believe that FLET may have declarations.
(flet ((foo (x) (1+ x)))
(declare (notinline foo)) ;this is a `bound' declaration
(declare (notinline 1+)) ;this is a `free' declaration
())
;;; The following code is from Pavel.
;;; It produces 7 in existing implementations.
;;; If the proposal is adopted, it will produce 8.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let ((foo (1+ foo))) ;is the second FOO special or not?
(declare (special foo)) ;`bound' declaration
foo)))
;;; Treatment of LET* under the proposal if multiple bindings of the same name
are allowed.
;;; This form produces the value 9.
(let ((foo 6)) ;a special binding of FOO
(declare (special foo)) ;`bound' declaration
(let ((foo 7)) ;a lexical binding of FOO
(let* ((foo (1+ foo)) ;special binding, lexical reference
(foo (1+ foo))) ;special binding, special reference
(declare (special foo)) ;`bound' declaration, applies to both bindings
foo)) ;special reference
Rationale:
`Bound' declarations are made to control a particular binding of a
variable and should be scoped the same way as that binding. This is as
true of `bound' declarations which were pervasive under the old rules
as it is of those that were not.
Current practice:
The `bound'/`free' division based on context replaces CLtL's static
pervasive/nonpervasive/SPECIAL division. Most implementations implement
the rules in CLtL. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
The cost of implementing this change should be moderate. The change
will be localized to a handful of places in the compiler and interpreter
which apply declarations to variables. The other cost would be in
providing tools for users to find programs whose meaning will change.
Cost to Users:
The proposal changes only the treatment of `bound' declarations. This
change will break very few existing production programs.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
The ability of a `bound' declaration to affect code outside the scope
of the variable which it appears to declare has led to endless confusion
and discussion at Symbolics, on the Common-Lisp mailing list, and
elsewhere. It will continue to do so unless it is smoothed over somehow.
Benefits:
The costs of non-adoption will be avoided.
Aesthetics:
The distinction between `bound' and `free' declarations introduced by
this proposal is a natural one.
Discussion:
A proposal to forbid `free' declarations except in LOCALLY forms and a
proposal to have `free' declarations affect only the body were discarded
as being too incompatible.
The mapping from the existing pervasive/nonpervasive/SPECIAL division of
declarations and the one proposed here is complex. In general,
nonpervasive declarations are `bound' and pervasive declarations are
`free'. SPECIAL declarations are either `bound' or `free' based on
their context, and are no longer treated as a special case.
Some historical support for having `free' and `bound' declarations:
Date: Tue, 20 Dec 83 15:50 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Declarations
To: Common-Lisp@SU-AI.ARPA
...
There are two disjoint classes of declaration: those that are attached
to a particular variable binding, and those that are not. Note that I
am not discussing proclamations here; they have their own scoping rules
which are different from the rules for declarations.
The scoping rule for the first kind of declaration is that it applies to
precisely the text that is in the lexical scope of the variable binding
with which it is associated. Such declarations are shadowed by a
variable binding for the same name inside their scope. Since the
lexical scoping rules are very well and precisely defined, we already
understand everything about this kind of declaration.
The scoping rule for the second kind of declaration is that it is
pervasive. The declaration is attached to a lambda-expression or to a
form (one of the special forms listed on page 125). The declaration
applies to all text inside that expression or form; there are no special
cases such as init-forms of LET or DO. Such declarations are shadowed
by a conflicting declaration inside their scope.
Possible names for the two kinds of declaration are "lexical" and
"pervasive" or "variable" and "non-variable."
...
∂08-Jun-88 1509 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:09:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:09:25 PDT
Date: 8 Jun 88 15:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880608-150925-3305@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
Test Cases:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error. Checking for it
would be costly so signaling this error is not required.
Current Practice:
In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂08-Jun-88 1524 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:19:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:12:04 PDT
Date: 8 Jun 88 15:11 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-151204-3312@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References: CLtL p.307 & 86-003 p.4
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
Structures defined by defstruct currently are required to have at least
one slot. This seems to have been a mistake in the design of the language.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):
Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct
given at the bottom of page 307 of CLtL.
Test Case:
(defstruct s), which is not allowed according to CLtL, would be allowed.
Rationale:
The current restriction is in marked contrast to the generality allowed
elsewhere in the language. And removing it slightly increases the
usefulness of defstruct - by allowing the zero slot case when it may be
deemed useful and by not requiring a check for it when it doesn't matter.
Current Practice:
KCL allows zero slots.
Cost to Implementors:
None for implementations that currently allow zero slots.
Very slight for others.
Cost to Users:
None.
Benefits:
Slightly increases the usefulness of defstruct and is aesthetic.
Aesthetics:
In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case. And the generality in this case
is consistent with that of many other features of the language, such as
that arrays can be empty, functions like + and list can take zero arguments,
etc.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
∂08-Jun-88 1531 X3J13-mailer Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:31:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 15:24:52 PDT
Date: 8 Jun 88 15:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-152452-3341@Xerox>
!
Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
References: CLtL p.308-10 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
There is some confusion over whether default initialization
forms for defstruct slots get evaluated, when they are not needed
because a keyword argument was supplied to the constructor function.
As a consequence of this confusion, there is confusion over whether
there can be a type-mismatch error between the specified type of the slot
and the type of the default value.
On page 308, it says "The default-init is a form that is evaluated
each time a structure is to be constructed; the value is used as the
initial value of the slot. If no default-init is specified, then the
initial contents of the slot are undefined and implementation-dependent."
On the next page, however, it says that the default-init is evaluated if
the keyword argument is not supplied and the converse, although not stated,
is intended and informally implied.
Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):
Clarify that the converse is true. i.e that the default-init is not evaluated
if the keyword argument is supplied.
In the quote from page 308, delete the second sentence and replace
"a structure is to be constructed; the value is" by "its value is to be".
To section 19.3, add a clarification,
such as the following from Guy's issues file:
"The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Test Case:
In the following sequence, only the last call is an error.
(defstruct person (name 007 :type string))
(make-person :name "James")
(make-person)
Rationale:
It is inefficient, and inconsistent with the rest of the language, for the
default initialization form to be evaluated when it is not needed.
Consequently, when it's not needed, such type-mismatch errors should not be
detectable in general.
Any existing confusion should be clarified by this proposal.
Current Practice:
KCL does not evaluate the default initialization form unless it is needed;
even when it is needed, the type checking is not done at all.
Cost to Implementors:
If there are any implementations that currently behave differently from
the proposed way, then they need some slight modification.
Cost to Users:
None.
Benefits:
Clarity and portability. In particular, clarifying that the unaesthetic
situation mentioned in the next section is allowed should be reassuring.
Aesthetics:
It appears slightly unaesthetic to have a default value that violates a
type specification.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
!
Additional notes:
Several members of the cleanup committee endorsed this proposal.
JonL added:
You can add to the "Current Practice:" section:
LUCID does not evaluate the default initialization form unless it is
needed; even when it is needed, the type checking is not done at all.
However, at structure definition time, if an initial value form is
constanp and doesn't satisfy the :type specification, a warning message
is printed.
Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked. Furthermore, in
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.
I have long suggested that there should be at least one mode of operation
such that all :type information is checked when setting values into structure
slots (setf as well as initialization). Some have suggested that this mode
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED." However, since the wording of
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.
∂08-Jun-88 1806 X3J13-mailer Issue: EVAL-OTHER (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 18:06:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 18:03:17 PDT
Date: 8 Jun 88 18:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EVAL-OTHER (Version 2)
To: X3J13@SAIL.Stanford.EDU
reply-to: CL-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <880608-180317-3640@Xerox>
I have some notes about some possible additional opposition to this proposal. I hope
we can discuss it at the June X3J13 meeting.
!
Issue: EVAL-OTHER
References: 5.1.1 Self-Evaluating Forms (p55)
Category: ADDITION/CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)
Problem Description:
CLtL does not specify what the evaluation behavior of some data types.
Proposal (EVAL-OTHER:SELF-EVALUATE):
Standard data types (those mentioned by CLtL) other than those for which
a more explicit evaluation rule exists would be defined to self-evaluate.
Such data types include, for example, structures, arrays, vectors, and
pathnames.
Structure types defined by users using DEFSTRUCT should also self-evaluate
unless an explicit implementation type for the structure is given in the
DEFSTRUCT, in which case the rule for evaluation of that type should be
used. (This is important in the case of type LIST.)
Test Case:
(LET ((TEMP (MAKE-PATHNAME))) (EQ TEMP (EVAL TEMP))) => T
(LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T
Rationale:
There are numerous possible positions that could be taken, from
requiring that an error be signalled for all of these cases to
requiring that these all have some useful behavior.
By making implementations agree, code portability is enhanced.
By biasing the decision away from the "signal
an error" end of the choice spectrum, the least interruption is
caused to implementations which already have working code.
There is still some chance that implementations will have some other
behavior than either signalling an error or self-evaluating, but there
are probably few if any.
Current Practice:
In many implementations, the other data types besides those mentioned in
CLtL will self-evaluate.
Cost to Implementors:
The cost is probably small. This is probably an "upward compatible"
change for most or all implementations -- a few lines of change in the
interpreter and/or compiler. Some code walkers may be affected as well.
Cost to Users:
None, if they are not exploiting implementation-dependent features of
some implementation that is being forced to make an incompatible change.
There should be no performance impact since the evaluator's test for these
new data types can simply be made to follow other tests already in place,
so existing code will not be slowed.
Cost of Non-Adoption:
Implementations will continue to differ in this relatively
user-visible way.
Benefits:
Portability will be enhanced because implementations will tend to agree
in places where they have traditionally not always agreed.
Aesthetics:
Some fans of 3LISP may find this invasive to their sense of distinction
between objects and the notation used to describe objects. In general,
however, this is a fairly picky detail that is not likely to trouble the
average programmer.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports EVAL-OTHER:SELF-EVALUATE.
Fahlman: "... I do remember the original design discussions. It was
proposed that everything but lists and symbols evaluate to themselves,
but at the time (this was quite early in the process) some people felt
that this might close out interesting parts of the design space that
might turn out to be useful for something. This hasn't happened, and
I think it would be reasonable to close this door now. Some users do
find it confusing that you have to quote vectors but not strings."
There has been some additional discussion of this proposal (for example,
an explaination of why a similar proposal in Scheme might be a bad design.)
∂08-Jun-88 1752 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 17:51:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 17:47:35 PDT
Date: 8 Jun 88 17:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 2)
TO: x3j13@Sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880608-174735-3615@Xerox>
This issue is a DRAFT; I hope that discussion at X3J13 can help the cleanup committee focus on the most popular options.
!
Status: DRAFT - for discussion at June X3J13
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (add Benson's proposal)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:RADICAL):
Remove EQUAL and EQUALP from the language. (Naturally, they could be retained
as implementation-dependent extensions.)
Rationale:
The name "EQUAL" suggests something very generic. It conjures in the mind
of the naive user the notion that there is a single, uniquely selected
predicate which is always good for equality testing. In fact, there is a
large space of useful equality predicates, each good for different
applications, and the choice of the current definition of EQUAL is
exceedingly arbitrary. Although the function chosen is sometimes quite
useful and some work is occassionally saved by having it be defaultly
available, confusion frequently results from its presence. Users for whom
the operator is not appropriate are inclined to describe it as broken,
rather than to recognize that it does a useful thing but that the
application they have does not call for that useful thing. The thing which
would be useful to them would not be useful in other situations. There is
simply no unique solution. The absence of the operator EQUAL would cause
people to think explicitly about what kind of equivalence is appropriate
to their application, and to write something better suited to that
application.
As an aside, this same notion of uniqueness carries over to COPY. People
have been observed to assert that a generic COPY function should be
present for copying arbitrary objects. A single COPY function is not
provided because there are many kinds of copying and no single function is
entitled to the generic name COPY. This argument does not sit well with
programmers who assert that if this is true, there should be no unique
EQUAL operator. We could solve that problem two ways -- one by creating a
COPY operator; another by eliminating the embarrassment of EQUAL and
friends.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Leave things as is.
Rationale:
The intent of a structure is different than the intent of an array. A
list is an anonymous entity which makes sense only in terms of its
length and contents, and is not rightly compared just by object identity
(EQ); a structure, on the other hand, has an identity of its own and is
appropriately compared with EQ.
Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
Rationale:
A structure is a container and, like many other containers in Lisp,
should be compared by recursing into the contents of that container.
Proposal (EQUAL-STRUCTURE:ADD-KEYWORDS):
Add :TEST and :TEST-NOT keywords to EQUAL saying what comparison operator
to use at the leaves.
[This will need more details if anyone decides they want to push this line
of reasoning. I don't claim to have done an adqeuate job of laying the
issue out, though I could imagine someone doing so. -kmp]
Rationale:
There's ample precedent for resolving sticky situations like this in
Common Lisp by just adding a keyword option. :-)
Proposal (EQUAL-STRUCTURE:ADD-OPERATOR)
Introduce new operator(s) like EQUAL (and/or EQUALP) which descends
structures.
Rationale:
If people don't want to make EQUAL more complicated, but still like
the idea of a keyword-driven EQUAL, this is the only way to get it.
Proposal (EQUAL-STRUCTURE:CHANGE-EQUALP):
Change EQUALP so that it descends structures, is case sensitive, and
never considers numbers of different types to be equal.
Rationale:
Several users have independently inquired why there is no predicate
with this definition in Common Lisp. Also, use of EQUALP is not
widespread. Rather than invent a new name for a predicate, it
would be preferable to take an existing name which is not being
heavily used and give it a more useful definition.
It would also be useful to have EQUALP type hashtables, given this
new definition for EQUALP.
EQUALP did not exist in Lisp dialects preceding Common Lisp. There
are few programs that make use of EQUALP and only those depending
on case insensitivity or numeric coercion (or lack of structure
descending) would be affected.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Current Practice:
There is no particular ambiguity in CLtL right now, so presumably
everyone agrees. The only question is whether what CLtL says is
sufficiently useful in practice.
Cost to Implementors:
The cost to implementors of most of these options is generally small.
The exception is that the ADD-KEYWORDS option may require hairy compiler
optimizations in order to get back the efficiency that a keyword would lose.
Cost to Users:
Writing an EQUAL or EQUALP function which is like the one that Common Lisp
now has would not be that hard to do as a compatibility measure in case
EQUAL or EQUALP were changed or removed. So the cost to users is technically
small.
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
Aesthetic considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
The ADD-KEYWORDS option will be the most controversial because some people
don't like keywords and some compiler writers will not like having to
optimize the keywords.
Discussion:
Pitman strongly supports EQUAL-STRUCTURE:RADICAL as the correct choice from
a purely language design standpoint, but acknowledges that it may not
ultimately be deemed practical for pragmatic reasons.
Eric Benson supports EQUAL-STRUCTURE:CHANGE-EQUALP. He has never
used EQUALP in a "serious" program, but in every "casual" use he has
wished that it was case sensitive.
∂08-Jun-88 1918 X3J13-mailer Issue: DEFPACKAGE (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:17:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:17:03 PDT
Date: 8 Jun 88 19:16 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFPACKAGE (version 2)
To: X3J13@Sail.Stanford.EDU
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-191703-3760@Xerox>
This issue is still a DRAFT. The ongoing discussion, however, centers
around the details of the operations of some of the keyword arguments
(e.g., should :IMPORT-FROM take strings instead of/as well as symbols.)
!
Status: DRAFT - for discussion at June 1988 X3J13 meeting
Issue: DEFPACKAGE
References: CLtL section 11.7.
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and give Common Lisp a bad name.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. It encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Also expand MAKE-PACKAGE and IN-PACKAGE to take all the same keyword
arguments as DEFPACKAGE, for consistency.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
package-name is a symbol or a string; if a symbol, only its name
matters, not what package it is in. If a string, capitalization
matters, normally uppercase is used.
Standard options for DEFPACKAGE are listed below. Additional options
might be present in an implementation, and each implementation must
signal an error if an option not recognized by that implementation is
present. Additional implementation-dependent options might take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Each option may appear at most once. If duplicate options are present,
DEFPACKAGE signals an error.
(:EXPORT {symbol}*)
Create symbols with the specified names and export them.
Note that only the name of each argument symbol is used.
The symbol that gets exported is not necessarily the one given
as an argument; it's a symbol with that name but in the package
being defined.
(:IMPORT {symbol}*)
Import the specified symbols.
(:IMPORT-FROM {(package-name {symbol}*)}*)
(:IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined. The second syntax is a
convenient abbreviation when only one package is specified.
Note that only the name of each argument symbol is used. The
actual symbol that gets imported is not necessarily the one
given as an argument; it's a symbol with that name accessible in
the named package.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified strings.
(:SHADOW {symbol}*)
Create the specified symbols in the package and place them on
the shadowing list. Note that only the name of each argument
symbol is used.
(:SHADOWING-IMPORT {symbol}*)
Import the specified symbols into the package and make them
shadow any inherited symbols.
(:SHADOWING-IMPORT-FROM {(package-name {symbol}*)}*)
(:SHADOWING-IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined, making them shadow any
inherited symbols. The second syntax is a convenient
abbreviation when only one package is specified. Note that only
the name of each argument symbol is used. The actual symbol
that gets imported is not necessarily the one given as an
argument; it's a symbol with that name accessible in the named
package.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
(:USE {package}*)
Inherit from the specified packages.
Example:
(DEFPACKAGE MY-PACKAGE
(:USE LISP)
(:SHADOW CAR CDR CONS)
(:NICKNAMES MYPKG MY-PKG))
Rationale:
See first paragraph of Proposal section.
Current practice:
Symbolics Common Lisp has always had this, and uses it in preference
to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL version
of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.
Cost to Implementors:
Should be small as the macro can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" business
described at the end of chapter 11 could be removed, and the special
compiler handling of these functions necessary to support that could be
removed. As this would be an incompatible change, it is not part of
this proposal.
KMP suggests that IN-PACKAGE should be incompatibly changed only to
recognize existing packages, not to create them, which would fix a lot
of bugs. IN-PACKAGE would then not accept any keyword arguments.
Moon thinks this is a reasonable idea but should be the subject of a
separate proposal.
∂08-Jun-88 1946 X3J13-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:46:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:45:16 PDT
Date: 8 Jun 88 19:44 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
to: X3J13@Sail.Stanford.Edu
reply-to: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880608-194516-3779@Xerox>
The only discussion on this issue was a revisiting of the various hiding places
in CLtL where it states requirement that function arguments evaluate from
left to right.
!
Issue: FUNCTION-CALL-EVALUATION-ORDER
References: CLtL p 194 ("...that order is always left to right")
Category: CLARIFICATION
Edit history: Version 1 by Clinger (22 March 1988)
Problem Description:
CLtL does not say whether the function expression of a call is evaluated
before or after the argument expressions.
Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED):
Common Lisp does not specify whether the function expression of a call is
evaluated before or after the argument expressions. Programs that rely on
a particular order of evaluation are in error.
Example:
(defun foo (x) (+ x 3))
(defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
(foo (progn (bar) 20))
; may return 23 or 24
Rationale:
This makes the status quo explicit.
Current Practice:
TI and Symbolics evaluate the function expression last. Lucid and Coral
sometimes evaluate the function expression first and at other times evaluate
the function expression last.
Cost to implementors:
None.
Cost to users:
None.
Benefits:
Codifies an ambiguity.
Aesthetics:
Since Common Lisp evaluates argument expressions from left to right, it would
be more consistent for the function expression to be evaluated before the
argument expressions. On the other hand, the evaluation rules for function
expressions are already quite different from the rules for argument
expressions, and nobody in their right mind would write code that depends on
the order of evaluation, so aesthetics should not count for much in this case.
Requiring left to right evaluation would force some implementations to consume
an extra register for many function calls. The efficiency argument seems more
important than the aesthetic argument.
∂08-Jun-88 1958 X3J13-mailer Issue: LAST-N (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 19:58:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 19:57:18 PDT
Date: 8 Jun 88 19:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LAST-N (Version 2)
To: x3j13@SAIL.Stanford.EDU
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-195718-3790@Xerox>
!
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
12-Mar-88, Version 2 by Pitman
Problem Description:
People always ask why LAST returns a cons and not an element.
BUTLAST takes an argument N but LAST does not.
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
The default for N would be 1.
It is an error if N is negative or L is circular.
If N is zero, then the atom that terminates the list L is returned.
If N is greater than or equal to the number of cons cells in the list
L, then the result is L.
Test Cases:
(LAST '(A B C) 0) => ()
(BUTLAST '(A B C) 0) => (A B C)
(LAST '(A B C) 1) => (C)
(BUTLAST '(A B C) 1) => (A B)
(LAST '(A B C) 2) => (B C)
(BUTLAST '(A B C) 2) => (A)
(LAST '(A B C) 3) => (A B C)
(BUTLAST '(A B C) 3) => ()
(LAST '(A B C) 4) => (A B C)
(BUTLAST '(A B C) 4) => ()
(LAST '(A B C)) => (C)
(BUTLAST '(A B C)) => (A B)
(LAST '(A . B) 0) => B
(LAST '(A . B) 1) => (A . B)
(LAST '(A . B) 2) => (A . B)
Rationale:
BUTLAST and LAST would select complementary parts of a list in general.
That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
and L being a proper list.
This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default.
Current Practice:
Probably nobody does this.
Adoption Cost:
Very slight. The following code would suffice:
(DEFUN LAST (LIST &OPTIONAL (N 1))
(CHECK-TYPE N (INTEGER 0))
(DO ((L LIST (CDR L))
(R LIST)
(I 0 (+ I 1)))
((ATOM L) R)
(IF (>= I N) (POP R))))
Some implementations might want to provide compiler optimizations for
the N=1 case.
Benefits:
This utility is probably needed often enough to warrant its inclusion.
It's present (as a separate function called NLEFT) in Symbolics Common
Lisp and Interlisp.
Conversion Cost:
None. This is an upward compatible extension.
Aesthetics:
This would make things a little prettier.
Discussion:
This suggestion came up recently on a Symbolics design discussion list.
Symbolics is contemplating offering it as an extension, but it seemed like
the rest of the CL community might want to adopt it, too. Pitman thinks
it's a nice idea.
Masinter opposes this extension as gratuitous.
Moon and Daniels think this is very low priority but have expressed a
lack of major objection to this proposal.
∂08-Jun-88 2030 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:30:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:29:25 PDT
Date: 8 Jun 88 20:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
to: X3J13@Sail.stanford.edu
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-202925-3823@Xerox>
This draft is for discussion at the June 1988 X3J13 meeting.
!
Status: DRAFT
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number of
such pairs, including zero. Order is not significant. It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale:
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
Benefits:
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to files.
Current practice:
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.
∂08-Jun-88 2049 X3J13-mailer Issue: MACRO-FUNCTION-ENVIRONMENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:49:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:48:16 PDT
Date: 8 Jun 88 20:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT
To: x3J13@SAIL.Stanford.Edu
cc: Masinter.pa@Xerox.COM
reply-to: CL-Cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-204816-3838@Xerox>
!
Issue: MACRO-FUNCTION-ENVIRONMENT
References: MACRO-FUNCTION, p. 144
MACROLET, pp. 113-4
&ENVIRONMENT, pp. 145-6
MACROEXPAND and MACROEXPAND-1, pp. 151-2
Category: ADDITION
Edit history: Version 1, Pavel, March 21, 1988
Version 2, Masinter, 8-Jun-88, (as per cleanup discussion)
Problem description:
The &ENVIRONMENT argument to a macro-expansion function may only be used as the
second argument to the functions MACROEXPAND and MACROEXPAND-1. It is sometimes
more convenient, however, to be able to work directly with the more primitive
function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are presumably
based. However, since MACRO-FUNCTION does not take an environment argument, it
cannot be used in situations in which that environment must be taken into
account.
Proposal (MACRO-FUNCTION-ENVIRONMENT:YES):
Add an optional second argument to MACRO-FUNCTION, that argument being an
environment that was passed as the &ENVIRONMENT argument to some macro expansion
function. If the argument is not given, or the argument is NIL, the null
environment is used. MACRO-FUNCTION will now consider macro definitions from
that environment in preference to ones in the global environment. It is an error
to supply the environment argument in a use of MACRO-FUNCTION as a SETF location
specifier.
Examples:
(macrolet ((foo (&environment env)
(if (macro-function 'bar env)
''yes
''no)))
(list (foo)
(macrolet ((bar () :beep))
(foo))))
=> (no yes)
(setf (macro-function 'bar env) ...) is an error.
Rationale:
Intuitively, the more primitive operation in macro expansion is MACRO-FUNCTION,
not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
supplied to the latter functions and not to the former one. By changing this
state of affairs, the model of macro expansion becomes somewhat simpler. Also,
more flexible use of the facility is enabled.
Current practice:
Xerox Common Lisp already implements this proposal. Symbolics Common Lisp,
and Kyoto Common Lisp do not. Lucid Common Lisp did not, but version 3.0 does.
Cost to Implementors:
This is presumably a simple change to make, a small matter of moving the
environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.
Cost to Users:
The change is upward-compatible and so poses no cost to users.
Cost of non-adoption:
One more (small) semantic wart on the language.
Benefits:
The function that users think of as being more primitive really is.
Aesthetics:
This slightly cleans up the language.
Discussion:
This issue was discussed starting in January 1987, but got tangled in
a web of other related proposals. In its current form, the only objections
have been that some other proposal or committee might otherwise change
macro handling, or that this proposal doesn't fix enough of the problems.
∂08-Jun-88 2058 X3J13-mailer Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 20:57:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 20:57:13 PDT
Date: 8 Jun 88 20:57 PDT
From: Masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
reply-to: cl-cleanup@Sail.stanford.edu
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
line-fold: no
Message-ID: <880608-205713-3851@Xerox>
!
Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE
References: CLtL, pages 331, 386
Category: CLARIFICATION
Edit history: Version 1, 25-Mar-88 JonL
Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels)
Version 3, 23-May-88 JonL (fix nits raised by Masinter)
Version 4, 23-May-88 JonL (change issue name -- only 1 proposal)
Version 5, 7-Jun-88 Masinter (more nits)
Problem description:
CLtL p386 says that FORMATting to a fill-pointer'd string should add
characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that
WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the
string is adjustable, and otherwise as if using VECTOR-PUSH". It's very
unlikely that the original authors of these parts intended differing
semantics for these two cases. Furthermore, the semantics for
WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters
written to the string, since VECTOR-PUSH will just "drop on the floor"
any characters that would go beyond the end.
Proposal (WITH-OUTPUT-TO-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND):
Change the documentation of WITH-OUTPUT-TO-STRING to be like that under
FORMAT. That is, replace the first sentence of the next-to-last paragraph
on CLtL p331 by:
"If *string* is specified, it must be a string with a fill pointer;
the output is incrementally appended to the string (as if by use of
VECTOR-PUSH-EXTEND)."
Test Case:
(let ((str (make-array 4 :element-type 'string-char :fill-pointer 0)))
(with-output-to-string (s str) (princ "You Luz, Bunkie!" s))
str)
CLtL behaviour will return "You "; proposed behaviour will signal an error.
Rationale:
It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended
to suggest that characters could be quietly "dropped on the floor". In
any case, there is no practical or theoretical reason to make FORMAT and
WITH-OUTPUT-TO-STRING act differently on non-adjustable strings.
Current Practice:
VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier
versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp
implements CLtL. Symbolics Genera 7.2 implements the proposal.
Cost to Implementors:
Very small.
Cost to Users:
Virtually none.
Benefits:
Less special-casing in the semantics of "printing" to strings.
More conformity with naive expectations about printing to strings.
Aesthetics:
Minor impact.
Discussion:
Implementations may want to actually call VECTOR-PUSH, rather than
VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the
result -- nil means an overflow of the total length of the string;
thus they may signal an error more directly related to the problem,
rather than permitting VECTOR-PUSH-EXTEND to complain about a non-
adjustable array. But either way, the semantics is still that of
VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable
strings are extended, and non-adjustable strings cause error signals.
It's perfectly acceptable to use VECTOR-PUSH-EXTEND with a non-adjustable
array. It's the error-signalling property of VECTOR-PUSH-EXTEND, as opposed
to the "dropping on the floor" of VECTOR-PUSH, that motivated this proposal.
∂08-Jun-88 2103 X3J13-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jun 88 21:02:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 21:02:13 PDT
Date: 8 Jun 88 21:01 PDT
From: Masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Subject: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
reply-to: cl-cleanup@Sail.stanford.edu
line-fold: NO
Message-ID: <880608-210213-3853@Xerox>
!
Issue: SUBSEQ-OUT-OF-BOUNDS
References: :START and :END arguments (246-247), SUBSEQ (248)
Category: CLARIFICATION
Edit history: 24-Mar-88, Version 1 by Steele
29-Mar-88, Version 2 by Steele, in response to Moon's comments
Problem description:
The descriptions of :START and :END arguments, and of SUBSEQ, do not
explicitly address the question of out-of-bounds indices. (The language on
page 246, "These arguments should be integer indices into the sequence," is
considered too vague on this point.)
Also, the language on page 246 does not make clear whether the prohibition
against "start > end" applies to defaulted values as well as explicit
values, and does not specify clearly whether the default value for the
end argument is the allocated length or the active length.
Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR):
Specify that it is an error for the :START argument of any standard
function, or the second argument to SUBSEQ, to be less than zero.
Specify that it is an error for the :END argument of any standard function,
or the third argument to SUBSEQ, to be greater than the active length of
the sequence in question (as returned by LENGTH).
Specify that the start value, after defaulting, must not be greater than
the end value, after defaulting.
Specify that the default value for the end argument is the active length of
the sequence in question.
This may be summarized as follows:
Let X be the sequence within which indices are to be considered. Let S be
the :START argument of any standard function, or the second argument to
SUBSEQ, whether explicitly specified or defaulted, through omission, to
zero. Let E be the :END argument of any standard function, or the third
argument to SUBSEQ, whether explicitly specified or defaulted, through
omission or an explicitly passed NIL value, to the active length of X, as
returned by LENGTH. It is an error if the condition (<= 0 S E (LENGTH X))
is not true.
Test Cases/Examples:
(SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where".
(SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "".
(SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ".
(SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "".
Under this proposal each of these situations is an error, and portable
programs may not rely on their behavior.
Rationale:
We don't want code indexing off the ends of arrays.
Current practice:
KCL interpreted and compiled code signals an error.
Symbolics Common Lisp interpreted and compiled code signals an error; the
compiler also issued an out-of-range warning (possible because the
arguments were all constant).
Lucid Common Lisp interpreted and compiled code signals an error.
Cost to Implementors:
None.
Cost to Users:
Users who depended on some specific implementation behavior in these cases
may find that their pragmatically unportable code is now officially
unportable.
Cost of non-adoption:
Confusion.
Benefits:
Removal of a small but important ambiguity in the spec.
Esthetics:
It seems cleaner not to allow indexing off the end of an array, and
by extension not allow it for any sequence.
Discussion:
This merely clarifies the original intent of the passage on page 246.
∂09-Jun-88 0714 CL-Cleanup-mailer Issue: LAST-N (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 07:14:29 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 9 Jun 88 10:11:00 EDT
Received: by kali.think.com; Thu, 9 Jun 88 10:10:57 EDT
Date: Thu, 9 Jun 88 10:10:57 EDT
From: gls@Think.COM
Message-Id: <8806091410.AA03128@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: Masinter.pa@xerox.com's message of 8 Jun 88 19:57 PDT <880608-195718-3790@Xerox>
Subject: Issue: LAST-N (Version 2)
I cast a "grue" vote for LAST-N:ALLOW-OPTIONAL-ARGUMENT; that is,
I support it and will continue to support it until it has consumed
either ten more messages on this mailing list or ten minutes of
meeting time, after which I will fiercely oppose it.
--Guy
∂09-Jun-88 0907 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jun 88 09:03:36 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02943; 9 Jun 88 10:01 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa07565;
9 Jun 88 10:00 BST
To: cl-cleanup@sail.stanford.edu
CC: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-reply-to: Masinter.pa@com.xerox's message of 8 Jun 88 15:07 PDT <880608-150925-3305@Xerox>
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
Date: Thu, 9 Jun 88 10:02:42 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
>>Rationale:
>>
>>Since it would be difficult to prescribe reasonable behavior for
>>this situation, it should be considered an error. Checking for it
>>would be costly so signaling this error is not required.
Sorry, I do not see the great cost. Surely defstruct is in effect a
declaration, and the cost of checking is small and the value great.
==John
∂09-Jun-88 1043 X3J13-mailer [bouzane@scrc-pegasus: X3J13 Meeting]
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 10:43:22 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 10:42:22 PDT
Received: from challenger.lucid.com by edsel id AA14871g; Thu, 9 Jun 88 10:37:09 PDT
Received: by challenger id AA12537g; Thu, 9 Jun 88 10:34:58 PDT
Date: Thu, 9 Jun 88 10:34:58 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8806091734.AA12537@challenger.lucid.com>
To: x3j13@sail.stanford.edu
Subject: [bouzane@scrc-pegasus: X3J13 Meeting]
We only have 34 people registered for X3J13 in Boston. Rosemary needs to know
how many will be at lunches. Please let her know if you will be attending but
haven't let her know yet. If you are unable to reach her please conact me and
I will pass on the information.
---jan---
Registered Attendees:
Arbaugh, William - US Army
Antonisse, H. James - Mitre Corp.
Bartley, David - Texas Instruments
Beiser, Paul - Hewlettt & Packard
Boelk, Mary P. - Johnson Controls
Chapman, Kathy - Digital
Dabrowski, Chris - Nat'l Bureau of Standards
DeMichiel, Linda - Lucid
Dussud, Patrick - TI
Gabriel, Dick - Lucid
Hadden, George, Honeywell
Haflich, Steve - Franz, Inc.
Hewitt, Carl - MIT AI Lab
Keene, Sonya E. - Symbolics, Inc.
Kiczales, Gregor - Xerox Parc
Larson, Aaron - Honeywell
Linden, Thomas - IBM Almaden Research
Loosemore, Sandra - Evans & Sutherland
Mathis, Robt.
Mikelsons, Martin - IBM
Moon, David A. - Symbolics, Inc.
Perdue, Crispin - Sun
Pierson, Dan - Encore
Piazza, Jeffrey - Digital
Rand, Douglas - Prime Computer
Rosenking, Jeff - Grumman Corp
Saji, Nobuyuki - NEC Corp
Slater, David - Computer Sciences Corporation
Van Roggen, Walter - Digital
Van Deusen, Mary - TI
Waldrum, Ellen - Texas Inst.
White, Jon - Lucid
Zubkoff, Jan - Lucid
∂09-Jun-88 1525 X3J13-mailer Issue: DECLARATION-SCOPE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 15:25:08 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 15:24:07 PDT
Received: from bhopal.lucid.com by edsel id AA16555g; Thu, 9 Jun 88 15:19:42 PDT
Received: by bhopal id AA25468g; Thu, 9 Jun 88 15:18:17 PDT
Date: Thu, 9 Jun 88 15:18:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806092218.AA25468@bhopal.lucid.com>
To: Masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, labrea!cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 12:39 PDT <880608-123958-2954@Xerox>
Subject: Issue: DECLARATION-SCOPE (Version 2)
Did you really want to distribute this to the X3J13 committee as a whole?
I had proposed a major rewrite of this issue, based on treating DECLARE
simply as a lexical construct, but haven't had the time to work on it before
the upcoming meeting. I'd hoped to see cleanup subcommittee discuss it
again before bringing the issue to the committee as a whole.
-- JonL --
∂09-Jun-88 2119 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:19:30 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:17:29 PDT
Received: from bhopal.lucid.com by edsel id AA17893g; Thu, 9 Jun 88 21:10:37 PDT
Received: by bhopal id AA26479g; Thu, 9 Jun 88 21:09:17 PDT
Date: Thu, 9 Jun 88 21:09:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100409.AA26479@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: x3j13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 17:47 PDT <880608-174735-3615@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 2)
I thought you were going to incorporate my comments into this issue, which
I sent in reply to its first presentation:
Date: Fri, 18 Mar 88 21:21:51 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 1)
Generally ok write-up of the issues. You left out the option of adding
a jillion-skillion new functions -- one for each conceivable kind of
equivalence relation between s-expressions. But that's ok; I want to
focus on just one of your proposals.
re: Proposal (EQUAL-STRUCTURE:DESCEND):
Change EQUAL and EQUALP to descend structure slots.
EQUALP is already documented to descend structures (CLtL, p81). So this
proposal should just say "Change EQUAL ...".
Had all the negative arguments against this particular proposal -- the one
you call (EQUAL-STRUCTURE:DESCEND) -- been thought of 6 years ago, CL could
not even have an EQUALP function. The logical conclusion of these
"technical details" arguments is that EQUAL cannot be defined either.
These arguments go roughly as follows:
(1) The equivalence which EQUAL implements is not graph-isomorphism --
which *is* uniquely defined -- but rather an ill-defined one
making reference to the underspecified notion of "printing".
Attempts to make it more precise are merely arbitrary.
(2) EQUAL is not a total function since it is permitted to run amok
on circular structures. In fact, it is much more "likely" that
defstruct instances will contain ultimately circular links than
that cons cells will; hence one will "probably" lose more much
often if EQUAL were to descend structures.
The more "wizard", or "theorist" one is, the more compelling the above
arguments seem. On the other hand, the more a "user" one is, the more
likely he will argue as follows:
I've used the EQUAL function for over 15 years, and have almost never
been dissatisfied with it, as the Doctors of Technology say I should be;
and every instance of dissatisfaction was due to its failue to descend
through pointer vectors. I keep my house in order, and know exactly
how my data pyramids are built up; so why should I be punished just
because some Conehead somewhere got lost playing around with his
Klein bottles and Moebius strips?
All the problems alleged for EQUALP's descent into structures also apply
to EQUAL's descent into lists; it's only a matter of probabilities. Hence,
I don't believe this issue can be settled by technical discussion.
The only non-time-wasting effort I can see to do from now on is to look for
some way to present our dilemma to a broad "user" community. We could try
to tell them, in cursory terms and few words, of the technical arguments
that show EQUAL (and EQUALP) to be ill-behaved functions. Then let them
decide (by straw vote?) if the extra functionality provided by this proposal
is worth the extra risk.
Related Issues:
-- Are DEFSTRUCT-defined types and CONS, ARRAY, HASH-TABLE, PACKAGE,
READTABLE, STREAM, etc. pairwise disjoint?
-- Will CLOS require EQUAL to be "generic"? Also, what about COPY?
-- JonL --
∂09-Jun-88 2136 X3J13-mailer Issue: HASH-TABLE-PRINTED-REPRESENTATION
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88 21:36:23 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:34:39 PDT
Received: from bhopal.lucid.com by edsel id AA18027g; Thu, 9 Jun 88 21:27:54 PDT
Received: by bhopal id AA26522g; Thu, 9 Jun 88 21:26:35 PDT
Date: Thu, 9 Jun 88 21:26:35 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100426.AA26522@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 20:24 PDT <880608-202925-3823@Xerox>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
Touretzky actually said he would alter his proposal to account for the
:rehash-size and :rehash-threshold omissions; but this version of the
proposaldoesn't show that. I remember remarking that you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables. I don't seem to have a copy of the mail from Dave in
which he said he would alter his proposal.
Date: Mon, 23 May 88 15:37:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: labrea!Dave.Touretzky@CS.CMU.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Mon, 23 May 88 11:27:58 EDT <361.580404478@DST.BOLTZ.CS.CMU.EDU>
Subject: HASH-TABLE-PRINTED-REPRESENTATION
re: One problem with the currently proposed #H notation is that it provides
no way to specify a rehash-size or rehash-threshold. This should not be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
-- JonL --
∂09-Jun-88 2307 X3J13-mailer Issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jun 88 23:07:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 88 23:05:43 PDT
Date: 9 Jun 88 23:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue status
To: x3j13@Sail.stanford.edu
Message-ID: <880609-230543-6121@Xerox>
For this meeting, I have been broadcasting those issues where either:
a) there has been convergence within the cleanup committee and the issue is
ready for voting by X3J13 or,
b) there has not been any mail in the cleanup committee on the issue for a
significant period of time, even when there have been additional significant
remarks.
I've tried to mark the issues in the latter status as DRAFT, the idea being that
you have some idea of what other significant issues remain before the cleanup
committee, and might have some comments or contributions that will guide our
deliberations. I hope you will understand that the issues for this meeting are
not as uniformly "baked" as our previous submissions.
There are a number of thorny issues that have been in committee for a long time
(some for well over a year); as time goes on, it becomes less useful to attempt
to postpone them to the "next" X3J13 meeting, especially given the schedule for
a draft standard.
I have a number of other issues to mail out; they will be followed by a list of
all of the issues mailed.
Thanks,
Larry
∂10-Jun-88 0056 X3J13-mailer Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 00:56:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 00:55:18 PDT
Date: 10 Jun 88 00:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 4)
To: x3j13@SAIL.STANFORD.EDU
line-fold: no
cc: Masinter.pa@Xerox.COM
REPLY-TO: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <880610-005518-6180@Xerox>
!
Issue: SHARPSIGN-PLUS-MINUS-NUMBER
References: #+ (p358), #- (p359), *features* (p448),
Parsing of Numbers and Symbols (p339-342)
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
Category: ENHANCEMENT
Edit history: Version 1 by Pitman 03/01/87,
Version 2 by Pitman 03/09/87 (address potential numbers)
Version 3 by Masinter 23-May-88, revive
Version 4 by Masinter 10-Jun-88, fix nits
Problem Description:
Features which are not symbols are currently not allowed.
Unfortunately, machine names are used as features. Since
some machines are named only by a number (eg, 360, 3600, 8600,
8080, ...) there is no way to use these names as features.
Alternate, less mnemonic feature names, must be contrived.
`Potential numbers' (as described on p341) should be addressed
specifically if only to say that they are still illegal. There
should be no ambiguity about what is legal and what is not.
An example of such a symbol is 68020A .
Proposal (SHARPSIGN-PLUS-MINUS-NUMBER:OK)
Extend the definition of #+ and #- on pp358-359 to say that
integers are allowable as features. Define that the feature-spec
reader binds base to 10 so that people don't have to do #+7020 to
find the 3600 feature in base 8.
In the case of `potential numbers' (as per p341) in a feature
spec, say that they are allowed for use in this context. If the
implementation does not support the syntax in question, it is
permitted to treat the syntax as if it denoted a feature which
was known not to be present. That is, in any implementation where
a potential number which is denoted by a character sequence <X> can
be parsed by the reader as either a number or a symbol, then
#+<X> will skip the next form iff the expression
(MEMBER (LET ((*READ-BASE* 10.)
(*PACKAGE* (FIND-PACKAGE "KEYWORD")))
(READ-FROM-STRING "<X>"))
*FEATURES*)
yields false, without prejudice to decision about whether <X>
denotes a number or a symbol. If <X> cannot be read by the reader
because it is a potential number, then #+<X> will skip the next
form as if any feature <X> might have been intended to denote was
not present.
Extend the definition of *features* on p448 to say that it is a
"list of symbols and/or numbers".
Comparison is performed by EQL.
Rationale:
There is no deep-rooted reason why numbers shouldn't work.
The current restrictions are somewhat arbitrary. This would
allow arbitrary alphanumeric strings (subject to restrictions
about potential numbers) to be used as identifiers in a
well-defined way.
Current Practice:
Some implementations already allow this (though most probably
do not bind base to 10 -- I've seen some octal feature names).
Other implementations signal an error if they see what they
believe to be an invalid feature name (such as a number).
Cost to implementors:
Changes to implementations not already supporting this feature
would probably be very minor.
Cost to Users:
Some users would view this as an enhancement; others as a bug fix.
I don't think it would be seen in a negative light.
Benefits:
A restriction which seems arbitrary to some people would be removed.
Aesthetics:
No issues not already addressed above.
Discussion:
Pitman initiated this proposal and thinks that it would be a
worthwhile extension.
Steele asks about treatment of potential numbers, such as #+68020a .
Revision 2 of this proposal addresses that issue, by explicitly
stating that this is allowed.
Fahlman reluctantly supported version 1 of this proposal since
some implementations support numbers here and since the purpose of
this feature is to allow selection of such implementations. He
wishes people would write Symbolics-3600 rather than 3600 since it
isn't clear that 3600 is meaningful in the abstract. He wants to
see the potential number issue treated, however.
KMP thinks that the problem of meaningfulness is not unique
to numbers. Many feature names with only alphabetic characters
could be likewise criticized. In practice, brevity is important
because AND and OR will greatly increase horizontal size of
feature-spec expressions and often it's desirable to still have
enough room to the right to grind the conditionalized expression.
Dick Gabriel opposed this proposal: "unless there is a compelling
reason to do otherwise, it is best to have as few different rules and
concepts in a language as possible.
Let `#+' represent either `#+' or `#-'. Currently #+<object> can be such
that <object> is a symbol or a boolean expression. I don't see any gain in
expressive power if we extend this to include numbers, yet we've extended
the complexity of the language a little bit.
Furthermore, the examples given are not compelling at all - someday soon
some people will not know what I mean when I say I mailed this message
from a 10.
Symbolics-3600, IBM-360, MC68020A - these are proper machine names and
hence proper feature names.
Finally, an expression like #-3600 looks like an arithmetic expression
or a slip of the TIP for simply -3600."
∂10-Jun-88 0107 X3J13-mailer Issue: SPECIAL-VARIABLE-TEST (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:07:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 00:59:37 PDT
Date: 10 Jun 88 00:59 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 2)
To: x3j13@SAIL.STANFORD.EDU
cc: masinter.pa@Xerox.COM
reply-to: CL-CLEANUP@SAIL.STANFORD.EDU
line-fold: no
Message-ID: <880610-005937-6183@Xerox>
!
Issue: SPECIAL-VARIABLE-TEST
References: Declaring Global Variables and Named Constants (pp68-69),
Declaration Specifiers (p157)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
21-May-88, Version 2 by Pitman (correct test case, add discussion)
Problem Description:
CLtL does not define a way to test to see if a variable has been
proclaimed special (for the purposes of either binding or reference).
Programs such as macros, code-walkers, and program-generating programs
may need such information from time to time in order to do certain kinds
of reasoning about code-motion, unused variables, etc.
Proposal (SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P)
Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P
which is defined as:
SPECIAL-VARIABLE-P symbol &optional environment [Function]
Returns T iff -symbol- names a variable which is SPECIAL in the
indicated lexical -environment-. Otherwise, it returns NIL.
It is an error if -symbol- is not a symbol. If not supplied, the
-environment- defaults to NIL, meaning the null lexical environment.
This function will be useful in determining whether a reference to
the variable named by SYMBOL in the indicated ENVIRONMENT will be
a special reference.
Note: Since special variable proclamations are pervasive and
declarations are not, the technique for determining whether binding
the variable named by SYMBOL is not dependent on the surrounding
lexical environment. It is instead dependent only on the global
environment and on the declarations of the form which would accomplish
the binding. Whether the variable has been globally proclaimed special
can be determined by doing (SPECIAL-VARIABLE-P 'symbol). Whether the
variable is locally declared SPECIAL can be checked only by parsing
the declarations looking for (DECLARE ... (SPECIAL ... symbol ...)).
Test Case:
(PROCLAIM '(SPECIAL SPECIAL-FOO))
(MACROLET ((TEST (NAME &ENVIRONMENT ENV)
`'(,NAME ,(SPECIAL-VARIABLE-P NAME ENV)) ))
(LIST* (TEST SPECIAL-FOO) ;0
(TEST FOO)
(LET ((SPECIAL-FOO 1) (FOO 1))
(LIST* (TEST SPECIAL-FOO) ;1
(TEST FOO)
(LET ((SPECIAL-FOO 2) (FOO 2))
(DECLARE (SPECIAL FOO))
(LIST* (TEST SPECIAL-FOO) ;2
(TEST FOO)
(LET ((SPECIAL-FOO 3) (FOO 3))
(LIST (TEST SPECIAL-FOO) ;3
(TEST FOO)))))))))
=> ((SPECIAL-FOO T) (FOO NIL) ;0
(SPECIAL-FOO T) (FOO NIL) ;1
(SPECIAL-FOO T) (FOO T) ;2
(SPECIAL-FOO T) (FOO NIL)) ;3
Rationale:
This would allow programs that reason about other programs to obtain
important information about SPECIAL declarations and proclamations.
Current Practice:
Interpreters and compilers must, of necessity, have a way to do this
internally.
In some implementations, information about special variable proclamations
is kept on a symbol's plist, and users eventually "figure out" how to take
advantage of that.
In most implementations, getting information about special declarations
is neither documented nor easy to "figure out".
Symbolics Genera has undocumented internal function which does this.
Cost to Implementors:
By necessity, compilers and interpreters must have a way to get the
information returned by this facility. In general, it should just be
a matter of providing a program interface to that facility.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
Some code-walkers, macros, etc. would continue be hard to write in a
portable way.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Although SPECIAL variables provide some benefit to Common Lisp, that
benefit has not been without price. It's difficult to do proper code
analysis if lexical and special variables look the same. The presence
of this operator makes it easier to write code which reasons clearly
and correctly about other programs, and so will probably tend to
improve the aesthetics of such programs.
Discussion:
This proposal came to the Cleanup committee from the Japanese community.
Pitman wrote it up formally.
Pitman and Moon support SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P.
∂10-Jun-88 0108 X3J13-mailer Issue: STEP-ENVIRONMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:08:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 01:07:49 PDT
Date: 10 Jun 88 01:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: STEP-ENVIRONMENT (Version 1)
To: x3j13@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Reply-to: CL-CLEANUP@Sail.stanford.edu
Line-fold: NO
Message-ID: <880610-010749-6191@Xerox>
!
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 10-Jun-88, Masinter (add discussion)
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
An additional problem is that CLtL says that STEP is a macro. However,
it is unclear what portable expression the macro could expand into,
especially if STEP evaluates the form in the current environment. STEP
is really a variation of the Lisp interpreter, which makes it more like
a special form than like a macro.
The interaction of STEP with the compiler is not specified.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Change STEP from a macro to a special form.
3. Clarify that it is an error to compile a STEP form.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. STEP is really a variation of the Lisp interpreter, which makes it more
like a special form than like a macro.
3. As a debugging TOOL, STEP forms do not need to be compiled. It would
be difficult to specify precisely what should happen when a STEP form is
compiled (which parts of the form are to be executed interpretively), so
it's easier to duck the issue. Use "is an error" rather than "signals
an error" so that compile-only implementations are permitted to compile
STEP forms.
Current practice:
Symbolics Common Lisp behaves as proposed.
Cost to Implementors:
1 requires passing an environment around, which should be easy.
2 and 3 are just restrictions, so they should cost nothing.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
∂10-Jun-88 0154 X3J13-mailer Issues for discussion at June 1988 X3J13 meeting
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jun 88 01:54:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 88 01:53:53 PDT
Date: 10 Jun 88 01:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Issues for discussion at June 1988 X3J13 meeting
TO: x3j13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <880610-015353-6228@Xerox>
The following issues are for discussion at the X3J13 meeting. Except for
FUNCTION-TYPE-REST-LIST-ELEMENT and SETF-FUNCTION-VS-MACRO, you
should have received copies of these.
Issues already discussed at previous meetings:
- FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88)
(allow &rest <type> in function types to refer to element
type)
Released before. not remailed to X3J13 for the June meeting.
* FUNCTION-TYPE (Version 10, 22-May-88)
(Change definition of FUNCTIONP, function type ...)
Rewritten for X3J13/June 1988
- SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
Released before. not remailed to X3J13 for the June meeting.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New issues for the June 1988 X3J13 meeting (some in DRAFT form):
* ADJUST-ARRAY-FILL-POINTER
(Interaction of Adjust-ARRAY and fill pointers.)
* DATA-TYPES-HIERARCHY-UNDERSPECIFIED (Version 1, 24-Mar-88)
( STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE are
required to be disjoint from other types)
* DECLARATION-SCOPE (Version 2, 2-Feb-88)
(What is the scope of SPECIAL declarations?
INLINE declarations? where can declarations be placed?)
*** DRAFT ***
* DEFPACKAGE (Version 2, 23-Mar-88)
(Add new DEFPACKAGE macro to handle common package operations.)
*** DRAFT ***
* DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1, 13-May-88)
(two slots in a single DEFSTRUCT can't have the same name)
* DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER (Version 1, 13-May-88)
(its OK to have zero slots)
* DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1, 13-May-88)
(clarify when initial value forms for defstruct options get evaled)
* EQUAL-STRUCTURE (Version 2, 8-Jun-88)
(What do EQUAL EQUALP and friends do on structures, vectors, etc.)
*** DRAFT: Multiple proposals ***
* EVAL-OTHER (Version 2, 8-Jun-88)
(Allow other data types to self-evaluate.)
* FUNCTION-CALL-EVALUATION-ORDER (Version 1, 22-Mar-88)
(when function cells are extracted isn't defined)
* HASH-TABLE-PRINTED-REPRESENTATION (Version 2, 8-Jun-88)
(make hash tables print as #H).
*** DRAFT ***
* LAST-N (version 2, 12-Mar-88)
(Extend LAST to take an optional N)
* MACRO-FUNCTION-ENVIRONMENT (Version 2, 8-Jun-88)
(Add environment argument to MACRO-FUNCTION)
* SHARPSIGN-PLUS-MINUS-NUMBER
(Allow #+68000, #-3600)
* SPECIAL-VARIABLE-TEST (Version 2, 21-May-88)
(Add SPECIAL-VARIABLE-P)
* STEP-ENVIRONMENT (Version 1)
(STEP isn't a macro, its a special form.)
* SUBSEQ-OUT-OF-BOUNDS (version 2, 29 Mar 88)
(it is an error to give out-of-bounds args to subseq)
* WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5, 7-Jun-88)
(interaction of WITH-OUTPUT-TO-STRING and FORMAT on adjustable arrays)
∂07-Jul-88 0732 X3J13-mailer DRAFT Minutes June meeting
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 7 Jul 88 07:32:06 PDT
Date: 7 Jul 1988 10:29-EDT
Sender: MATHIS@A.ISI.EDU
Subject: DRAFT Minutes June meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Jul-88 10:29:46.MATHIS>
DRAFT
Minutes of the X3J13 Meeting, Boston, June 15, 16 1988.
Wednesday, June 15
09:00 am Item 1, 2, 3, 4.
Item 1. 2a. Call to Order. Bob Mathis
Item 2. Introduction of attendees. Attendees list.
Future meetings. Bob recommended the Holiday Inn in Fairfax, VA for
October meeting which will be hosted by Contel.
Dick Gabriel described a planned Lisp conference for October
or November, 1989, in the Boston area. He also announced that, during
the conference, part of the Lisp museum will be on display.
Hawaii meeting will be Jan 17-20, 1989 (the week after POPL meets in
Austin, TX).
The Spring 1989 meeting will be held in the Palo Alto area.
Item 3. Approval of agenda.
Item 4. Approval of minutes. David Slater moved to table the approval
of the minutes until after JonL White and Larry Masinter's
comments were distributed.
9:30 am Item 5
Item 5 Editorial Subcommittee Report, Kathy Chapman.
Phase 1 document (1000p) will be ready for review in mid-July.
The document will be available for remote FTP access. Bob
Mathis emphasized that special document access needs should
be discussed with Bob or Kathy. The document is in TEX.
Phase 1 involves rewriting the CLTL into the format that
the X3J13 document will use. Review involves verifying the
correctness of the rewrite. The final document for Phase 4
is scheduled for June, 1989. Kathy is looking for volunteers
to suggest actual changes.
10:00 am Item 6
Character Subcommittee Report, Thom Linden
A proposal should be ready for voting on at the next meeting.
Bob Mathis noted that this topic was of great interest to many
different ISO committees and that this was the right time to
distribute our solution to the other committees.
10:05 am Item 7
Iteration Subcommittee Report, JonL White
Of the three proposals, Loop is ready for voting and OSS and
Generators need users. Guy Steele asked for a straw vote on
how many companies used some portion of Loops. Approximately
1/3 indicated that their companies did.
10:45 am Morning Break
11:10 am Item 7 (continued)
Dick Waters presented OSS, its description and status. The
files are available to FTP. Dick encouraged use and feedback.
The copyright on OSS belongs only to Dick, not to MIT. The
restriction on its use is that people will use it unchanged.
If changes are made, the name of the system should be changed.
Chris Perdue discussed the status of Generators. The
discussion focused on how complex proposals are to be included
in CL: ie., as kernel features, as features within a hierarchical
structure, or as optional features. No resolution occured.
12:30 pm Dick Waters raised some potential CL problems, and possible
solutions, in the area of prettyprinting, particularly.
12:35 pm Item 9, Lunch
01:45 pm Item 10
CLOS (88-002R, 88-003R), Gregor Kiczales
Gregor described the responses to comments on the last version of
CLOS, Chapters 1 and 2. Detailed questions were raised and
discussed.
03:00 pm Afternoon Break
03:15 pm Item 10 (continued)
Discussion continued on remaining issues to be resolved and
the form a resolution should make. Gregor moved and David
Moon seconded that:
The X3J13 Committee hereby votes to accept Chapters 1 and 2 of
the Common Lisp Object System, as defined in document 88-002R, for
inclusion in the Common Lisp language being specified by this
committee. Subsequent substative and wording changes will be
handled with the usual editorial and cleanup process.
Jim Antonio (who?) moved and JonL seconded an amendment to strike
the second sentence. The motion was defeated 9-12.
Dick Gabriel moved, and Larry Masinter seconded, to change the
motion to the following:
The X3J13 Committee hereby accepts chapters 1 and 2
of the Common Lisp Object System, as defined in document
88-002R, for inclusion in the Common Lisp language being
specified by this committee. Subsequent changes will be handled
through the usual editorial and cleanup processes.
The motion passed 22-0.
The original motion, as amended, passed 24-1.
Guy Steele stated the appreciation of himself and the committee
for the work of the CLOS subcommittee.
04:55 pm Ending remarks
Bob Mathis encouraged people to join relevant subcommittees. Larry
Masinter gave an overview to the Cleanup status that will be the
topic of the agenda tomorrow.
05:05 pm Item 11 Meeting adjourned
Thursday, June 16
09:10 am Item 12
Item 12 Call to Order. Bob Mathis
Attendance at the ISO meeting at Sunbird is limited to people
appointed by the committee. The present attendees are planned
to be Bob Mathis, Dick Gabriel, Kathy Chapman, Patrick Dussud,
and one person from the Scheme standardization effort.
David Bartley discussed IEEE Scheme Standardization meeting. Will
Clinger and someone else (who?) will be co-chairs.
Macro Subcommittee
Members of the subcommittee will be contacted by Bob Mathis to
find out status and intentions.
CLOS Subcommittee
Dick Gabriel announced that chapters 1 and 2 will be published
in SIGPLAN Notices and Lisp Journal and made available in such a
way as to allow republication by any vendor.
Error Subcommittee
Kent Pittman distributed a document describing what would
happen if an error were signalled. Gregor moved, and
Dick Gabriel seconded, that:
The X3J13 committee hereby accepts revision 18 of the Common
Lisp Condition System, as defined in document 88-005, for
inclusion in the Common Lisp language being specified by this
committee. Subsequent changes will be handled through the
usual editorial and cleanup processes. These changes will
include any necessary to reconcile the proposal with CLOS.
Bob Mathis called for a straw vote asking whether the second
sentence should be included in the motion. The straw vote
passed. Bob Mathis called for a straw vote asking whether
the third sentence should be included. The straw vote passed
13-11.
The motion was voted and passed unanimously. The committee
applauded Kent Pittman's work. Guy Steele moved, and JonL
White seconded, a vote of appreciation for Kent's efforts.
This motion also passed unanimously.
Compiler Cleanup Subcommittee
Sandra Loosemore discussed three proposals which had been
distributed yesterday. She encouraged comments to be sent
to the subcommittee by August 1st to:
CL-COMPILER@SAIL.STANFORD.EDU
Volunteers were asked to contact Sandra Loosemore or Steve
Haflich. Bob Mathis noted that the X3J13 committee was expecting
an overview of the issues and specific proposals to be
distributed in time to allow a vote at the October meeting.
Editorial Subcommittee
Kathy Chapman suggested that a member of each subcommittee
whose work is voted into CL should migrate first to the
Cleanup Subcommittee and then to the Editorial Subcommittee.
Kathy also suggested that each subcommittee should be
represented in the Editorial Subcommittee. There will be a
meeting of the Editorial Subcommittee during lunch.
10:40 am Morning Break
11:00 am Item 8
Item 8, Definition Specs Proposal, JonL White
JonL White repeated the Palo Alto proposal. The ensuing
discussion brought out the need for a written version of
the proposal that addresses implementation costs. It was
hoped that a written version would be available in advance
of the October meeting.
11:30 am Item 13
Item 13 Cleanup, Larry Masinter
Larry presented a status report showing that of the 21 issues
now under consideration, only three are still in "draft"
form. It is expected that a final vote will be taken in
October on currently known issues. The work after October
would then focus on ambiguities noted by the Editorial
Subcommittee and problems encountered with language areas
added to CL.
Larry Masinter moved, and JonL White seconded, that
FUNCTION-TYPE-REST-LIST-ELEMENT be added to the language.
Jeff moved, and Beckerly seconded, that the function
will be tabled until the next meeting. The motion to table
passed.
Larry Masinter moved, and JonL White seconded, that
FUNCTION-TYPE be added to the language.
12:30 pm Item 14 Lunch
01:20 pm Item 13 (continued)
Discussion centered on the automatic coercion of lambda
expressions. JonL White moved, and Gregor seconded, to
Change Section 2e
Clarify FUNCALL and APPLY and all CL functions that take
function arguments to also take a symbol, which will be
coerced to a function as with SYMBOL-FUNCTION.
Change Section 6b
(COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
Mike Beckerley moved, and JonL seconded, to amend the amendment
to eliminate the word "clarify" from 2e and to replace
"similar to" with "as if by".
02:30 pm Afternoon break
02:40 pm Item 13 (continued)
David Moon moved, and David Slater seconded, to amend the
motion on the floor to
Add Section 2f:
FUNCALL and APPLY and all CL functions that take function
arguments also take a list whose car is LAMBDA, which will
be coerced to a function as if by
(EVAL '(FUNCTION ,x))
The amended motion failed 9-13.
A move to call off debate was called. The motion failed 8-12.
Steve Haflich moved, and Chris Perdue seconded to
Add Section 2f:
This is an incompatible change, in that FUNCALL, APPLY, and
all CL functions that take function arguments are not
required to take a list beginning with LAMBDA.
Barry Margolin moved, and Steve Haflich seconded, a friendly
amendment to Steve's amendment to
Add Section 2f:
This is an incompatible change in that it is an error to pass
anything other than a function or symbol as the function
The motion to amend the amendment passed 21-0.
The amendment to the cleanup proposal passed 20-1.
David Moon moved, and Barry Margolin seconded, to cut off
debate. The movement passed 17-4.
Jeff Dalton moved, and David Slater seconded, to table the
amended motion. The motion to table failed 6-13.
The chair announced that if 5 people believe the issue should
be sent to a mail ballot, it will be. No one challenged this
decision. Five people did not vote for a mail ballot.
The amended motion, FUNCTION-TYPE, passed 16-7.
Larry Masinter moved, and Guy Steele seconded, to add
SETF-FUNCTION-VS-MACRO to the language.
Following discussion and acquiring of a volunteer to help,
Larry Masinter moved to table the motion. The
tabling motion passed 15-6.
The discussion then moved on to the 18 new proposals.
Larry Masinter moved, and Sandra Loosemore seconded, to add
ADJUST-ARRAY-FILL-POINTER to the language. The motion passed
unanimously.
Larry Masinter moved, and xx seconded, to add
DATA-TYPES-HIERARCHY-UNDERSPECIFIED to the language.
Discussion noted that this is an incompatible change to
existing implementations, although the representatives of the
implementations felt this was a positive change.
Guy Steele moved, and Dan Pierson seconded, to change the
wording of the proposal as follows:
"explicitly forbid" to be replaced by "it is an error for"
The amendment passed unanimously.
The amended proposal passed unanimously.
Larry Masinter moved, and Dan Pierson seconded, to add
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME to the language. Discussion
on this was delayed.
Barry Margolin moved, and Steve Haflich seconded, to add
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER to the language. The
motion passed unanimously.
The motion to add DEFSTRUCT-SLOTS-CONSTRAINTS-NAME was tabled
by general consent.
The discussion of DEFSTRUCT-DEFAULT-VALUE-EVALUATION led to
no resolution of opinion so it was decided not to bring the
proposal to a motion.
The discussion of EVAL-OTHER led to no resolution of opinion
so it was decided not to bring the proposal to a motion.
The discussion of FUNCTION-CALL-EVALUATION-ORDER led to no
resolution so it was decided not to bring the proposal to a
motion.
Dan Pierson moved,and Barry Margolin seconded, to add LAST,
with an argument, to the language. The motion passed 16-3.
Larry Masinter moved, and Dan Pierson seconded, to add
MACRO-FUNCTION-ENVIRONMENT to the language. The motion passed
unanimously.
Larry Masinter moved, and Barry Margolin seconded, to add
SHARPSIGN-PLUS-MINUS-NUMBEr to the language. The motion
moved was the proposal with the phrase "list of symbols and/or
numbers" changed to "list of symbols and/or integers".
The motion failed 7-10.
The discussion of SPECIAL-VARIABLE-TEST led to no resolution
of opinion so it was decided not to bring the proposal to a
motion.
The discussion of STEP-ENVIRONMENT led to no resolution of
opinion so it was decided not to bring the proposal to a
motion.
Larry Masinter moved, and Dan Pierson seconded, to add
SUBSEQ-OUT-OF-BOUNDS to the language. The motion passed
unanimously.
The discussion of WITH-OUTPUT-TO-STRING-APPEND-STYLE led to
no resolution of opinion so it was decided not to bring the
proposal to a motion.
Larry brought up a list of issues which are currently under
discussion.
05:05 pm Closing Comments
Jim Allard will talk to Bob Mathis about starting a working group on
delivery issues.
Dan Pierson offered to work with Barry Margolin on a position
paper on how implementations have to deal with the standard.
Bob Mathis emphasized that the October meeting would be a wrapup
of many technical issues. January will be a joint meeting with
ISO. The Palo Alto meeting will be a review of full document so
that at the following meeting we have the goal of having a document
which can be made public.
05:20 pm Item 16 Adjournment
Minutes submitted by Mary S. Van Deusen (June 16, 1988)
∂11-Aug-88 1444 X3J13-mailer CLOS workshop
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88 14:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 14:38:15 PDT
Date: Thu, 11 Aug 88 14:33 PDT
From: Gregor.pa@Xerox.COM
Subject: CLOS workshop
To: Common-Lisp@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM,
X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880811213330.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
This is the second announcement of the CLOS workshop to be held at PARC
October 3rd and 4th. This is a reminder to help us with our planning by
letting us know soon if you are planning to attend. My apologies to
people who receive multiple copies of this message.
To clarify the position paper requirement, the workshop is not limited
exclusively to those who have extensive experience writing CLOS code.
Anyone planning CLOS implementations, extensions, environments or CLOS
based application development is encouraged to attend. A position paper
can simply be a description of the kinds of issues you feel should the
CLOS community should address at the workshop.
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
∂11-Aug-88 1607 X3J13-mailer CLOS workshop
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88 14:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 AUG 88 14:38:15 PDT
Date: Thu, 11 Aug 88 14:33 PDT
From: Gregor.pa@Xerox.COM
Subject: CLOS workshop
To: Common-Lisp@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM,
X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880811213330.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
This is the second announcement of the CLOS workshop to be held at PARC
October 3rd and 4th. This is a reminder to help us with our planning by
letting us know soon if you are planning to attend. My apologies to
people who receive multiple copies of this message.
To clarify the position paper requirement, the workshop is not limited
exclusively to those who have extensive experience writing CLOS code.
Anyone planning CLOS implementations, extensions, environments or CLOS
based application development is encouraged to attend. A position paper
can simply be a description of the kinds of issues you feel should the
CLOS community should address at the workshop.
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
∂19-Aug-88 1210 X3J13-mailer Virginia and Hawaii X3J13 meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Aug 88 12:10:21 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA04379g; Fri, 19 Aug 88 11:10:09 PST
Received: by challenger id AA12057g; Fri, 19 Aug 88 12:08:20 PDT
Date: Fri, 19 Aug 88 12:08:20 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8808191908.AA12057@challenger>
To: x3j13@sail.stanford.edu
Cc: jlz@lucid.com
Subject: Virginia and Hawaii X3J13 meetings
Date: 17 Aug 1988 21:02-EDT
Sender: MATHIS@A.ISI.EDU
The next meeting of X3J13 will be held October 10-13, 1988, in Fairfax,
Virginia, at the Contel Technology Center at 12015 Lee Jackson Highway (US
Route 50). Monday (October 10) will be used for subcommittee meetings and
Tuesday and Wednesday (October 11 and 12) will be used for the general
meeting. If necessary Thursday can also be used for subcommittee meetings.
The Contel Technology Center is located in the same building with Contel
Federal Systems across the parking lot from Fair Oaks Shopping Center. On the
other side of the shopping Center is the Holiday Inn Fair Oaks (11787 Lee
Jackson Highway, 703-352-2525) where some rooms are being held for our group.
These facilities are located at the intersection of US Route 50 and Interstate
66. This is outside the beltway two exits further west along I-66 from where
the Metro Orange line ends. Coming from National Airport, one would go by the
Pentagon along 110 through Rosslyn to go west on I-66. From Dulles airport,
take the first exit south onto Route 28 and then east on Route 50. The cab
fare from Dulles should be about $20 and from National about $30. There is
also bus service to Fair Oaks Shopping Center.
To register contact the hotel directly (and memtion Contel and this group) and
Jan Zubkoff at Lucid. The meeting fee will be $50 (make checks payable to
Lucid). For special local questions, contact Bob Mathis. We need an
indication, as soon as possible, about attendance and subcommittee meeting
needs.
The agenda of this meeting should be quite full. We expect final (or almost
final) reports from ALL subcommittees. The CLOS committee is working toward
presenting chapter 3. The clean-up committee will have a number of issues to
review. The editorial committee has the beginnings of a draft. The compiler,
character, and iteration committees should also have reports. Will there be
any others? From the subcommittee leaders, I need any documents they want
distributed, their subcommittee meeting plans, their expectations about full
X3J13 actions, and their anticipated time on the agenda.
The meeting after next will be held January 16-18, 1989, in Kauai, Hawaii. Jan
Zubkoff will be handling the arrangements and needs an indication of
anticipated attendance as soon as possible. We are not anticipating
subcommittee meetings there because we want to have final resolution of any
remaining issues, not just progress reports from the subcommittees. The
subcommittees may need to communicate between the Fairfax and Hawaii meetings.
For the January meeting agenda, it is anticipated that there will be a full
day on final clean-ups, a half day on final CLOS issues, a half day for other
yet-to-be-resolved issues from other sub-committees, and a full day on an
initial review of the draft of the standard.
*******************************************************************************
X3J13/ISO Meeting
X3J13: 1/16/89 - 1/18/89
ISO: 1/19/89 - 1/20/89
Kauai, Hawaii
Committee Meeting:
Dates: 1/16/89 - 1/18/89
Time: 9:00 - 5:00
City: Kapaa, Kauai, Hawaii
Place: Sheraton Coconut Beach Hotel
REGISTRATION FEE: $75 Payable to: LUCID, Inc.
ISO Meeting:
Dates: 1/19/89 - 1/20/89
Hotel Accomodations:
Hotel: Sheraton Coconut Beach Hotel
Address: Coconut Plantation
Phone: 808/822-3455
Directions from airport:
Turn right onto route 56 north (Kuhio Highway)
Look for the 7 mile marker and take next right (can see hotel from the
road but it is not on the main road)
Rate: $80/night
Mention: "X3J13 Standards Committee" for rate
Group Luau:
Place: Shearton Coconut Grove
Date: 1/17/89
Time: TBA
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13/ISO January Meeting Registration Form
Please include check for $75.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________ Attend ISO _________
Lunch 1/16: _________ yes _______ no
Lunch 1/17: _________ yes _______ no
Lunch 1/18: _________ yes _______ no
Luau 1/17 $38.50: _________ yes _______ no
∂04-Sep-88 1352 X3J13-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 13:52:29 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 13:51:24 PDT
Date: 4 Sep 88 13:51 PDT
From: Masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED (version 2)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <880904-135124-8828@Xerox>
This is the final version as amended & subsequently passed.
>Guy Steele moved, and Dan Pierson seconded, to change the
>wording of the proposal as follows:
> "explicitly forbid" to be replaced by "it is an error for"
>The amendment passed unanimously.
>The amended proposal passed unanimously.
!
Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED
References: CLtL 33-35 (data types)
CLtL 312 (DEFSTRUCT :INCLUDE option)
Category: CHANGE
Edit history: 24-Mar-88, version 1 by Steele
4-Sep-88, version 2 by X3J13 June 88
Problem description:
The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL,
ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With
the arrival of CLOS, lack of disjointness will be inconvenient because one
cannot reliably use generic function dispatch on these types.
Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT):
Remove the third and antepenultimate bulleted items from section 2.15 is
CLtL and replace with the following:
* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE,
PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created
by DEFSTRUCT [or DEFCLASS] are pairwise disjoint.
Also, in the discussion of the DEFSTRUCT :INCLUDE option, it is an error for
the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER,
CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or
RANDOM-STATE.
Rationale:
It would be useful to extend sequence functions to operate on streams
or hash tables, for example, through the CLOS generic function mechanism.
This is not possible under the current specification.
Current practice:
Some implementations in effect use DEFSTRUCT to define data structures
such as hash tables and random-states.
Cost to Implementors:
Small or nonexistent. The main reason this disjointness was not specified
in CLtL was the possibility that structures might not be easily
distinguishable: a stupid concern over a slight efficiency. This
implementation freedom apparently has not been exploited in practice.
Cost to Users:
None.
Cost of non-adoption:
CLOS will be less useful.
Benefits:
CLOS will be more useful.
Esthetics:
This makes the type system simpler and easier to understand.
Discussion:
This suggestion originated in the CLOS committee.
----- End Forwarded Messages -----
∂04-Sep-88 1342 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 13:42:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 13:39:41 PDT
Date: 4 Sep 88 13:39 PDT
From: Masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO
Message-ID: <880904-133941-8818@Xerox>
This is the final version of the FUNCTION-TYPE issue, as passed at the June 88 X3J13 meeting; that is, it incorporates the amendments that were adopted before the issue was adopted.
I hope to be getting issues out to the X3J13 list as the cleanup committee comes to some final agreement on them, over the next two weeks.
!
Issue: FUNCTION-TYPE
References: functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category: CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)
24-May-88, Version 11 by van Roggen
(don't coerce lists, relax SYMBOL-FUNCTION reqs)
4-Sep-88, Version 12 by Masinter
(incorporate amendments adopted at June 88 X3J13)
Problem Description:
The definition of the term ``function'' in CLtL includes all symbols and
many lists in addition to `true' functions.
Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.
A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).
Proposal FUNCTION-TYPE:X3J13-MARCH-88
This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, correcting a few typos, changing section 2E as
agreed upon at X3J13 March 1988, allowing symbols but not lists to
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP
requirements.
1. Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.
1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint. In particular, a list may not be used
to implement any FUNCTION subtype.
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
2. Define that a ``function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.
2a. This type no longer includes objects of type SYMBOL or lists
whose CAR is LAMBDA.
2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible
change.
2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.
2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.
2e. FUNCALL and APPLY and all Common Lisp functions that
take function arguments to also take a symbol, which will
be coerced to a function as if by SYMBOL-FUNCTION.
2f. This is an incompatible change in that it is an error to pass
anything other than a function or symbol as the functional
argument.
3. Clarify that the result of a FUNCTION special form must be a function.
3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).
4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.
4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a `useful' behavior.
5. Clarify that FBOUNDP must return true for a symbol naming a macro or
a special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.
5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. SETF of SYMBOL-FUNCTION requires a FUNCTION as the new value.
It is an error to set the SYMBOL-FUNCTION of a symbol to a
symbol or a list or the value returned by SYMBOL-FUNCTION on
the name of a macro or a special form.
5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
6. COERCE is extended to allow objects to be coerced to type FUNCTION.
6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the expansion interface hook by
MACROEXPAND-1.
Rationale:
The fuzzy definition of ``function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.
It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
``true function.''
This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and a STRICT-REDEFINITION proposal,
which incompatibly changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional
arguments.
For compatibility reasons symbols are still acceptable to FUNCALL et al.,
but for aesthetic reasons lambda-expressions (lists whose CAR is LAMBDA
and whose CADR is a list) are no longer acceptable.
Current Practice:
In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.
Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.
Few current Common Lisp implementations have exactly the
semantics described in this proposal.
Cost to Implementors:
Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.
Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or as some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).
Cost to Users:
The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.
Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error when this is done.
The original STRICT-REDEFINITION proposal required users to deal with
the use of symbols and lambda-expressions as functional arguments. However
this proposal is compatible with current CLtL definition in the use of
symbols, which would be the hardest change to make. There are probably
relatively few uses of lambda-expressions as ``functions'', which can
be dealt with by (EVAL `(FUNCTION ,lambda-expresssion)).
Benefits:
The term ``function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.
The type hierarchy would be simplified.
This proposal brings Common Lisp slightly closer to Scheme and the
work of the EuLisp committee. Scheme, for example, also has the concept
of a ``procedure'' which is compatible with the FUNCTION type.
Aesthetics:
This proposal improves the aesthetics of the language.
Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
The following code does -not- count the number of nodes in a graph:
(LET ((COUNTER 0))
(TRAVERSE-THING '(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
since it is not the same as
(LET ((COUNTER 0))
(TRAVERSE-THING #'(LAMBDA (NODE) (INCF COUNTER))
(THING-ROOT)))
which does pass around a closure incrementing the LET variable.
(These examples assume COUNTER wasn't PROCLAIMed SPECIAL.)
Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Discussion:
This issue has been discussed at great length; this section attempts
only to summarize the important points.
There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.
The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.
Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.
This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write
(MAPCAR 'FROB my-list)
It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,
(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)
(MAPCAR 'FROB '(-1 -1 1 1))
may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.
∂08-Sep-88 1751 X3J13-mailer Fairfax X3 registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Sep 88 17:51:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00481g; Thu, 8 Sep 88 16:50:15 PST
Received: by challenger id AA05802g; Thu, 8 Sep 88 17:48:06 PDT
Date: Thu, 8 Sep 88 17:48:06 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809090048.AA05802@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax X3 registration form
I've had a few people ask about the dates of the next meeting... The dates in
the last message were correct. It was decided to have only 1 day of
subcommittee meetings before the committee meeting in October. I have
included the last message pertaining the the Fairfax meeting and a
registration form. See you there! ---jan---
The next meeting of X3J13 will be held October 10-13, 1988, in Fairfax,
Virginia, at the Contel Technology Center at 12015 Lee Jackson Highway (US
Route 50). Monday (October 10) will be used for subcommittee meetings and
Tuesday and Wednesday (October 11 and 12) will be used for the general
meeting. If necessary, Thursday can also be used for subcommittee meetings.
The Contel Technology Center is located in the same building with Contel
Federal Systems across the parking lot from Fair Oaks Shopping Center. On the
other side of the shopping Center is the Holiday Inn Fair Oaks (11787 Lee
Jackson Highway, 703-352-2525) where some rooms are being held for our group.
These facilities are located at the intersection of US Route 50 and Interstate
66. This is outside the beltway two exits further west along I-66 from where
the Metro Orange line ends. Coming from National Airport, one would go by the
Pentagon along 110 through Rosslyn to go west on I-66. From Dulles airport,
take the first exit south onto Route 28 and then east on Route 50. The cab
fare from Dulles should be about $20 and from National about $30. There is
also bus service to Fair Oaks Shopping Center.
To register contact the hotel directly (and mention Contel and this group) and
Jan Zubkoff at Lucid. The meeting fee will be $50 (make checks payable to
Lucid). For special local questions, contact Bob Mathis. We need an
indication, as soon as possible, about attendance and subcommittee meeting
needs.
The agenda of this meeting should be quite full. We expect final (or almost
final) reports from ALL subcommittees. The CLOS committee is working toward
presenting chapter 3. The clean-up committee will have a number of issues to
review. The editorial committee has the beginnings of a draft. The compiler,
character, and iteration committees should also have reports. Will there be
any others? From the subcommittee leaders, I need any documents they want
distributed, their subcommittee meeting plans, their expectations about full
X3J13 actions, and their anticipated time on the agenda.
!
X3J13 October Meeting Registration Form
Please include a check for $50.00 payable to `LUCID' mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________
Lunch 10/11: _________ yes _______ no
Lunch 10/12: _________ yes _______ no
∂12-Sep-88 0841 X3J13-mailer Availability of the standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 08:41:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA25711; Mon, 12 Sep 88 08:40:11 PDT
Message-Id: <8809121540.AA25711@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 11:33
To: x3j13@sail.stanford.edu
Subject: Availability of the standard
For you information:
A copy of the phase 1 standard (CLtL only) is available on
hudson.dec.com, username: ftp_user, password: ftppleasework.
This copy is VERY preliminary. Please do not spend time reviewing
this information because it will change shortly.
At the completion of phase 2, comments from the X3J13 committee
will be accepted. At this time, only comments from the editorial
committee are being processed.
kathy chapman
∂12-Sep-88 1344 X3J13-mailer Common Lisp Mailing Lists
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I intend to stop maintaining the various Common Lisp mailing lists
(including X3J13) by the end of this year. I would like someone else to
take over my duties (which I have performed since 1981). Because the SAIL
computer will be de-commissioned within 1 year from now, the lists will
need to move anyway.
-rpg-
∂12-Sep-88 1954 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 19:54:09 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00892g; Mon, 12 Sep 88 18:52:49 PST
Received: by bhopal id AA02266g; Mon, 12 Sep 88 19:52:12 PDT
Date: Mon, 12 Sep 88 19:52:12 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809130252.AA02266@bhopal>
To: Masinter.pa@Xerox.COM
Cc: X3J13@Sail.stanford.edu, Masinter.pa@Xerox.COM
In-Reply-To: Masinter.pa@Xerox.COM's message of 4 Sep 88 13:39 PDT <880904-133941-8818@Xerox>
Subject: Issue: FUNCTION-TYPE (version 12)
There are several gaffs in this version, and I don't remember the previous
versions well enough to know if they are recently introduced or have been
around since the beginning. In fact, until the June 1988 X3J13 meeting, the
whole issue was divided enough (because of the coercion issue) that minor
gaffs like those pointed out below were not worth bothering about.
re: 5c. The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.
Surely the distinction between FUNCTION and SYMBOL-FUNCTION is the access
to lexical redefinitions, versus access restricterd to the global database
(the symbol-function attributes of all symbols). I *** would not *** try
to discourage use of, nor disparage, the SYMBOL-FUNCTION function. Further-
more, this isn't the time nor the place to debate the issue of how symbols
are implemented -- *must* they really be implemented as little structures,
or could their "attributes" be done other ways? There is no need to relegate
SYMBOL-FUNCTION to a set of "accessors on symbols", nor to bring up that
red-herring at all.
re: 6a. (COERCE symbol 'FUNCTION) extracts the SYMBOL-FUNCTION of the
given symbol, signalling an error if the symbol is not FBOUNDP or
if the symbol names a macro or a special-form.
"Extracts" seems a bit rude here; other documentary places probably would
just have said "returns the symbol-function of the given symbol", assuming
that the notion of a symbol having a 'symbol-function' attribute is already
well understood. A very similar issue is the accessing of the global value
of a variable -- one would talk about the symbol-value of the variable.
re: 6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
It's surely bassackwards to describe what COERCE does by having to resort
to what EVAL does. Why not, for example, describe it in terms of what
(FUNCTION <x>) *** compiles into ***? On the contrary -- rather than
depending on an uncertain definition of either EVAL or COMPIL -- wouldn't
it be much cleaner (and clearer) to let FUNCTION be "primary", and then
document this case of COERCE in terms of what FUNCTION does. E.g.:
6b. (COERCE x 'FUNCTION), where the value of x is a list of form
(LAMBDA ...), will return a closure that is the functional
interpretation of x in the null lexical environment (see
CLtL, p87). If x is a list not of this form, an error
is signalled. [Note: a closure is always a function.]
This leaves out the issue of whether it's EVAL's action, or COMPILE's action,
that is the defining term. Unless these "actions" are sidestepped, then
it would be impossible to define this function unless EVAL were sufficiently
elaborated in the standard [e.g., such as Henry Lieberman's Common EVAL
proposal would do].
Under "Aesthetics:", the discussion is again not easy to follow.
re: Lambda-expressions do not obey the normal, apparent scoping rules because
free variables cannot refer to lexical bindings. This is because
coercing a list to a function would mean (EVAL `(FUNCTION ,list)).
I honestly don't know what this is trying to say. If it is trying to
highlight the difference between the interpretations of:
(QUOTE (LAMBDA ...))
and
(FUNCTION (LAMBDA ...))
then I certainly didn't get that from reading this paragraph [but rather
from a belief that this issue should be explicitly stated somewhere in the
proposal].
re: Making the coercion of lambda-expressions to functions explicit with
the use of EVAL will encourage less confusing code and also highlight
that use of EVAL.
Again, isn't this completely backwards? The whole point of this cleanup
issue to to *** stop *** programmers from writing "quotified" lambda
expressions, and to strongly encourage them to use "real" functions
instead. I'm sure we don't need to encourage the use of EVAL!
-- JonL --
∂13-Sep-88 0841 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 08:41:23 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 13 Sep 88 11:38:00 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Sep 88 11:39:06 EDT
Date: Tue, 13 Sep 88 11:39 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-TYPE (version 12)
To: Jon L White <jonl@lucid.com>
Cc: Masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: <8809130252.AA02266@bhopal>
Message-Id: <19880913153928.7.BARMAR@OCCAM.THINK.COM>
Date: Mon, 12 Sep 88 19:52:12 PDT
From: Jon L White <jonl@lucid.com>
Further-
more, this isn't the time nor the place to debate the issue of how symbols
are implemented -- *must* they really be implemented as little structures,
or could their "attributes" be done other ways? There is no need to relegate
SYMBOL-FUNCTION to a set of "accessors on symbols", nor to bring up that
red-herring at all.
Whether symbols are actually implemented as structures, they are
conceptually structures with several slots.
re: 6b. (COERCE x 'FUNCTION), where the value of x is a list that
begins with LAMBDA, will return a FUNCTION similar to
(EVAL '(FUNCTION ,x)).
It's surely bassackwards to describe what COERCE does by having to resort
to what EVAL does. Why not, for example, describe it in terms of what
(FUNCTION <x>) *** compiles into ***? On the contrary -- rather than
depending on an uncertain definition of either EVAL or COMPIL -- wouldn't
it be much cleaner (and clearer) to let FUNCTION be "primary", and then
document this case of COERCE in terms of what FUNCTION does. E.g.:
6b. (COERCE x 'FUNCTION), where the value of x is a list of form
(LAMBDA ...), will return a closure that is the functional
interpretation of x in the null lexical environment (see
CLtL, p87). If x is a list not of this form, an error
is signalled. [Note: a closure is always a function.]
This leaves out the issue of whether it's EVAL's action, or COMPILE's action,
that is the defining term. Unless these "actions" are sidestepped, then
it would be impossible to define this function unless EVAL were sufficiently
elaborated in the standard [e.g., such as Henry Lieberman's Common EVAL
proposal would do].
We debated long and hard at the last meeting to get the wording of this
particular clause, although I think it was mostly over the phrase that
finally turned into "similar to" (I think I originally wrote "equivalent
to", but people weren't sure what kind of equivalence it implied).
First of all, not all implementations will bother creating a closure for
a function that is in the null lexical environment (Symbolics doesn't),
so it would be wrong to specify that it returns a closure.
The reason this particular form was used as the definition is that the
justification given in the previous versions of the proposal, which
lacked this explicit coercion mechanism, was that this conversion could
be done by calling (EVAL '(FUNCTION x)). Therefore, we decided to
codify that particular idiom.
Since most uses of (COERCE <lambda-exp> 'FUNCTION) will not have a
constant <lambda-exp> (because then #'<thing> could have been used), I
think it is pretty unlikely to be compiled, although there is nothing
preventing it. By the same token, there's nothing preventing (EVAL
`(FUNCTION ,<lambda-exp>)) from compiling the function, either. They
really are equivalent at the language level.
barmar
∂13-Sep-88 1139 X3J13-mailer Re: Issue: FUNCTION-TYPE (version 12)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 11:39:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 88 11:29:28 PDT
From: masinter.PA@Xerox.COM
Date: 13 Sep 88 11:27:26 PDT
Subject: Re: Issue: FUNCTION-TYPE (version 12)
In-reply-to: barmar@Think.COM's message of Tue, 13 Sep 88 11:39 EDT,
<19880913153928.7.BARMAR@OCCAM.THINK.COM>
To: Barry Margolin <barmar@Think.COM>
cc: Jon L White <jonl@lucid.COM>, Masinter.PA@Xerox.COM, X3J13@sail.stanford.edu
Message-ID: <880913-112928-3452@Xerox>
I'd just as soon lay this to rest. The cleanup issue writeups are intended
primarily for ourselves -- that we understand what we're voting on. The
proposals are intended for the editor and the editorial committee -- that they
understand the language they are describing. Certainly I would expect that the
language we use to describe how CLtL should change is not the same as the
language used to describe the language once changed.
If you have some suggestions for wording and terminology in the standard (and I
think the issues you both raise are valid), you should take them up with the
editor and the editorial committee (cl-editorial@sail.stanford.edu) and not the
committee of the whole.
Thanks,
Larry
∂15-Sep-88 0225 X3J13-mailer "passed" cleanup issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 02:25:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 01:35:24 PDT
Date: 15 Sep 88 01:35 PDT
From: masinter.pa@Xerox.COM
Subject: "passed" cleanup issues
To: x3J13@sail.stanford.edu
reply-to: Masinter.pa@Xerox.COM
Message-ID: <880915-013524-2103@Xerox>
The cleanup issues passed at previous meetings of X3J13 are now available for
anonymous FTP from host arisia.xerox.com (address 13.1.100.206). The files are
plain text, although some of the files may be missing line-breaks. If you do not
have network access, I can mail you copies of any issue.
I will be making text of the pending issues available in the same way.
user anonymous, any password will do.
The passed issues on the directory clcleanup/passed.
I will be making the text of pending issues available in the same way, in the
directory clcleanup/pending.
ftp arisia.xerox.com
Connected to arisia.
220 arisia FTP server (Version 4.15 Sat Nov 7 15:24:41 PST 1987) ready.
Name (arisia.xerox.com:masinter): anonymous
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> cd clcleanup/passed
ftp> ls
200 PORT command okay.
150 Opening data connection for /bin/ls (13.1.100.218,1029) (0 bytes).
adjust-array-displacement
adjust-array-fill-pointer
append-dotted
aref-1d
assoc-rassoc-if-key
colon-number
compiler-warning-stream
data-types-hierarchy-underspecified
declare-macros
defstruct-slots-constraints-number
defvar-documentation
defvar-init-time
defvar-initialization
disassemble-side-effect
do-symbols-duplicates
dribble-technique
flet-declarations
flet-implicit-block
format-atsign-colon
format-colon-uparrow-scope
format-comma-interval
format-op-c
function-type
function-type-key-name
get-setf-method-environment
import-setf-symbol-package
keyword-argument-name-package
last-n
macro-function-environment
princ-character
push-evaluation-order
reduce-argument-extraction
shadow-already-present
sharpsign-plus-minus-package
226 Transfer complete.
767 bytes received in 2.3 seconds (.32 Kbytes/s)
∂15-Sep-88 1617 X3J13-mailer additional passed clean-up issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 16:17:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 15:42:33 PDT
Date: 15 Sep 88 15:42 PDT
From: masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
Subject: additional passed clean-up issues
reply-to: Masinter.pa@Xerox.COM
Message-ID: <880915-154233-3261@Xerox>
It was pointed out that I missed some passed issues:
PATHNAME-STREAM
PATHNAME-SYMBOL
I can't find a record of this issue being voted on:
SUBSEQ-OUT-OF-BOUNDS
It was distributed before the June 1988 meeting. I will include it in the set of
pending issues unless someone has a record of it being accepted already.
∂16-Sep-88 1145 X3J13-mailer agenda items please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Sep 88 11:45:09 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02073g; Fri, 16 Sep 88 10:43:32 PST
Received: by challenger id AA04779g; Fri, 16 Sep 88 11:41:19 PDT
Date: Fri, 16 Sep 88 11:41:19 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809161841.AA04779@challenger>
To: x3j13@sail.stanford.edu
Subject: agenda items please
If you have anything you wish to bring to a vote, please remember committee
member need to RECEIVE proposals 2 weeks before the meeting. (Mail early next
week.) Call Bob Mathis for mailing labels 703/359-0203.
Below is a rough draft of the agenda. Please let me know ASAP if you have
anything to add. See you soon!
---jan---
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Gregor Kiczales
8 Compiler Subcommittee Report and Vote, Sandra Loosemore (1.5 hrs)
9 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
10 ??
11 Recess, 5:00pm
12 Call to Order, October 12, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Other committee reports
16 Adjournment, 5:00pm
Next X3J13 meeting: 1/16 - 1/18 1989 Kauai, Hawaii
∂16-Sep-88 1157 X3J13-mailer subcommittee meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Sep 88 11:57:10 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02080g; Fri, 16 Sep 88 10:55:43 PST
Received: by challenger id AA04785g; Fri, 16 Sep 88 11:53:30 PDT
Date: Fri, 16 Sep 88 11:53:30 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809161853.AA04785@challenger>
To: x3j13@sail.stanford.edu
Subject: subcommittee meetings
As you can see there is some overlap. Any other subcommittee meetings should
be scheduled on Sunday or Monday evening. Please let me know of any changes
or additions.
Subcommittee meetings
October 10, 1988
9:30 - 5:00 Characters (4-5)
9:30 - 12:30 Cleanup (?)
11:30 - 3:30 Editorial (?)
2:00 - 5:00 Compiler (?)
∂19-Sep-88 1857 X3J13-mailer Issue: FUNCTION-TYPE (version 12)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 18:57:18 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03895g; Mon, 19 Sep 88 17:55:36 PST
Received: by bhopal id AA15915g; Mon, 19 Sep 88 18:55:04 PDT
Date: Mon, 19 Sep 88 18:55:04 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809200155.AA15915@bhopal>
To: barmar@Think.COM
Cc: Masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 13 Sep 88 11:39 EDT <19880913153928.7.BARMAR@OCCAM.THINK.COM>
Subject: Issue: FUNCTION-TYPE (version 12)
re: First of all, not all implementations will bother creating a closure for
a function that is in the null lexical environment (Symbolics doesn't),
so it would be wrong to specify that it returns a closure.
See CLtL, p87: "If fn is a lambda-expression, then a ``lexical closure''
is returned, that is a function that when invoked will execute the body
of the lambda-expresssion in such a way as to observe the rules of
lexical scoping properly." This applies regardless of whether or not
the lexical environment is null.
What many persons miss is the fact that a perfectly ordinary compiled
function with a null lexical environment satisfies the definition of
"closure". Possibly they are misled, as you may have been, by the
fact that some vendors have a lower-level data-type that distinguishes
functions closed over the null lexical environment from those closed
over something more significant.
Incidentally, I thought this was a "Cleanup" subcommittee issue, and only
now notice that is beng cc'd to X3J13 as a whole. Was this a mistake?
-- JonL --
∂23-Sep-88 1056 X3J13-mailer issue COMPILE-FILE-PACKAGE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:56:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28982; Fri, 23 Sep 88 11:54:35 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02517; Fri, 23 Sep 88 11:54:31 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231754.AA02517@defun.utah.edu>
Date: Fri, 23 Sep 88 11:54:30 MDT
Subject: issue COMPILE-FILE-PACKAGE
To: x3j13@sail.stanford.edu
Issue: COMPILE-FILE-PACKAGE
References: CLtL p. 182, 183
Category: CHANGE, CLARIFICATION
Edit History: 1 Sep 1988, Sandra Loosemore (initial version)
21 Sep 1988, Sandra Loosemore (minor tweak to current practice)
Problem Description:
The variable *PACKAGE* is rebound by the function LOAD, so that its
old value will be restored in spite of any calls to IN-PACKAGE
appearing in the file being loaded. Since COMPILE-FILE must evaluate
any top-level calls to IN-PACKAGE that it sees, it may also alter the
value of *PACKAGE*. It is inconsistent to have COMPILE-FILE and LOAD
behave differently regarding the rebinding of this variable.
Proposal COMPILE-FILE-PACKAGE:REBIND:
Require COMPILE-FILE to rebind *PACKAGE* before processing the file.
Rationale:
This makes COMPILE-FILE and LOAD more consistent. It is a more
compatible solution than either requiring LOAD not to rebind
*PACKAGE*, or removing the specialness of IN-PACKAGE and the other
package functions.
Current Practice:
Lucid Common Lisp, the TI Explorer, and VaxLisp already implement this
proposal.
Cost to implementors:
Trivial.
Cost to users:
I find it hard to believe that users would consider COMPILE-FILE altering
the value of *PACKAGE* as a useful side effect.
Benefits:
The language is made more uniform.
Discussion:
-------
∂23-Sep-88 1053 X3J13-mailer compiler cleanup issue status
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:53:25 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28898; Fri, 23 Sep 88 11:52:03 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02492; Fri, 23 Sep 88 11:52:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231752.AA02492@defun.utah.edu>
Date: Fri, 23 Sep 88 11:51:59 MDT
Subject: compiler cleanup issue status
To: x3j13@sail.stanford.edu
X3J13 Compiler Cleanup Status as of 23 Sep 1988:
================================================
Old issues (distributed for comments at the June meeting), ready to be
voted upon:
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
What are the compile-time side-effects of the various defining
macros?
EVAL-WHEN-NON-TOP-LEVEL
What does EVAL-WHEN mean when it does not appear as a top-level
form?
DEFINING-MACROS-NON-TOP-LEVEL
Can defining macros such as DEFUN appear in non-top-level
locations?
This issue provoked the only comments that were received since
the last meeting:
* The wording of section 4 was garbled.
This has been fixed in the latest version of the proposal.
* Many implementations do not allow a lexical environment to be
shared between compiled and interpreted functions.
A new issue, COMPILE-ARGUMENT-PROBLEMS, has been written up
to deal with this problem.
* Forms within a COMPILER-LET and the expansion of a top-level
macro should also be considered top-level.
This has been fixed.
New issues that are ready to be voted upon:
COMPILE-ARGUMENT-PROBLEMS
What functions can be compiled with COMPILE?
COMPILE-FILE-PACKAGE
COMPILE-FILE should rebind *PACKAGE*.
OPTIMIZE-DEBUG-INFO
What OPTIMIZE quality controls debuggability of compiled code?
PROCLAIM-INLINE-WHERE
INLINE proclamations should be placed before the corresponding
DEFUN.
Issues in draft form (comments requested):
COMPILE-ENVIRONMENT-CONSISTENCY
What things can the compiler safely "wire in" to code being
compiled?
PROCLAIM-ETC-IN-COMPILE-FILE
Add PROCLAIM, REQUIRE to list of N random package functions that
COMPILE-FILE must eval at compile time.
Issues in progress (no proposals ready yet):
LOAD-TIME-EVAL
What does #, mean? Where can it appear?
COMPILED-CONSTANTS
Are quoted constants in compiled code read-only? Must the compiler
handle circular constants? Preserve nonprintable aspects of constant
data?
-------
∂23-Sep-88 1056 X3J13-mailer issue OPTIMIZE-DEBUG-INFO
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:56:32 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28993; Fri, 23 Sep 88 11:55:10 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02522; Fri, 23 Sep 88 11:55:07 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231755.AA02522@defun.utah.edu>
Date: Fri, 23 Sep 88 11:55:06 MDT
Subject: issue OPTIMIZE-DEBUG-INFO
To: x3j13@sail.stanford.edu
Issue: OPTIMIZE-DEBUG-INFO
References: CLtL p. 160
Category: ADDITION
Edit History: V1 9 Sep 1988, David Gray (initial version)
V2 19 Sep 1988, David Gray (delete first alternative)
Problem Description:
The OPTIMIZE declaration provides a way to tell the compiler how important
various qualities are in order to guide which optimizations are done.
There is another quality, however, that is not mentioned, but is an
important consideration for the compiler: how much information
should be included in the object code to facilitate debugging. This
includes both annotation added to enable a debugger to display more
information to the user, and also suppression of optimizations that would
confuse debugging by making it harder to connect the object code with the
source code.
Proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY:
In the description of the OPTIMIZE declaration, add an additional quality
named DEBUG, described as "ease of debugging".
Rationale:
Since ease of debugging is an issue that the user will be concerned with,
and is an issue that the compiler needs to consider, this provides a clear
way for the user to control the amount of debugging information placed in
the object module, with DEBUG=0 meaning none and DEBUG=3 meaning "as much
as possible".
Current Practice:
No current implementation of this is known.
Cost to implementors:
All would have to update their handling of OPTIMIZE declarations to accept
the new quality.
Cost to users:
One more little feature to learn. Some problems may result from the
addition of the symbol DEBUG to the LISP package.
Benefits:
Provides users a standard way to control the interaction between
the compiler and debugger, and saves implementors from having to invent
implementation-dependent solutions.
Costs of Non-Adoption:
Continued confusion about how debug information should be controlled.
Discussion:
Concern has been raised that there is already a problem with the
non-orthogonality of SPEED, SAFETY, and SPACE that would be made even
worse with DEBUG added, since users tend to be perplexed by the
interactions of these qualities.
-------
∂23-Sep-88 1057 X3J13-mailer issue PROCLAIM-INLINE-WHERE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:57:11 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29014; Fri, 23 Sep 88 11:55:45 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02527; Fri, 23 Sep 88 11:55:42 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231755.AA02527@defun.utah.edu>
Date: Fri, 23 Sep 88 11:55:41 MDT
Subject: issue PROCLAIM-INLINE-WHERE
To: x3j13@sail.stanford.edu
Issue: PROCLAIM-INLINE-WHERE
References: CLtL p. 156, 159
Category: CLARIFICATION
Edit History: 16 Sept. 88 V1 by David Gray
Problem Description:
CLtL does not specify whether a (PROCLAIM '(INLINE ...)) should come
before or after the DEFUNs that it refers to, but in most
implementations the compiler can't expand a function inline
unless it knows at the time it processes the DEFUN that the definition
needs to be saved for use in inline expansion.
Proposal PROCLAIM-INLINE-WHERE:BEFORE:
Clarify that (PROCLAIM '(INLINE ...)) tells the compiler both that it is
desirable to use inline expansion for calls to the functions indicated
and that the compilation of any subsequent DEFUN of one of the functions
should record whatever information is used for performing inline
expansions. Consequently, the proclamation should precede the
definition of the functions that it names. When compiling a function
call, if the function has been proclaimed INLINE but the current
definition of the function was established before the PROCLAIM was
processed, it is implementation-dependent whether the function will
actually be expanded inline.
Rationale:
This clarification brings the specification in line with current
practice. The only alternative would appear to be to require the
compiler to always save the definition of every function, and that
doesn't seem reasonable.
Test Cases/Examples:
Given the following input to COMPILE-FILE, does F1 get expanded inline
in F2?
(defun f1 (a) (+ a 100))
(proclaim '(inline f1))
(defun f2 (b) (f1 b))
Current Practice:
The documentation for Lucid and the TI Explorer both say that INLINE
proclamations need to precede the function definition. Symbolics
doesn't appear to document this, but requires it anyway. Thus none of
these three implementations do the inline expansion in the example
above.
Cost to implementors:
Probably none required, although given this clarification it would be
nice if compilers warned about an INLINE proclamation that follows the
indicated DEFUN in the same file.
Cost to users:
None.
Benefits:
Users will know how to use INLINE proclamations correctly.
Costs of Non-Adoption:
Continued confusion over cases such as the example above, which
conform to CLtL but don't do what is expected.
Discussion:
-------
∂23-Sep-88 1055 X3J13-mailer issue COMPILE-ARGUMENT-PROBLEMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:37 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28972; Fri, 23 Sep 88 11:54:12 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02512; Fri, 23 Sep 88 11:54:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231754.AA02512@defun.utah.edu>
Date: Fri, 23 Sep 88 11:54:07 MDT
Subject: issue COMPILE-ARGUMENT-PROBLEMS
To: x3j13@sail.stanford.edu
Issue: COMPILE-ARGUMENT-PROBLEMS
References: CLtL p. 438-439
Issue FUNCTION-TYPE
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, CHANGE
Edit History: V1, Sandra Loosemore (8 Aug 1988)
V2, Sandra Loosemore (21 Sep 1988)
Problem Description:
The description of what arguments can legitimately be passed to the
function COMPILE in CLtL is too vague. There are two specific
problems:
(1) Acceptance of the FUNCTION-TYPE proposal makes it nonsensical to
speak of a lambda-expression being an interpreted function (it is not)
or to require a symbol to have a lambda-expression as its definition
(the SYMBOL-FUNCTION must be a true FUNCTION object).
(2) Many implementations cannot correctly compile functions that are
defined interpretively in a non-null lexical environment, because the
compiler and interpreter use different representations for closures.
Although this problem arose in conjunction with the
DEFINING-MACROS-NON-TOP-LEVEL proposal, the situation can also arise
if SETF is used to store a lexical closure in the SYMBOL-FUNCTION of
the symbol.
Proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY:
If the optional "definition" argument to COMPILE is supplied, it may
be either a lambda expression (which is coerced to a function) or a
function to be compiled. Otherwise, the SYMBOL-FUNCTION of the symbol
is extracted and compiled. It is an error if the function to be
compiled was defined interpretively in a non-null lexical environment,
or if it is already compiled.
Rationale:
Saying "it is an error" to try to compile the wrong kind of function
allows implementations that can compile functions defined in a
non-null lexical environment to go ahead and do so.
Current Practice:
Implementations that do not allow sharing of lexical environments
between compiled and interpreted functions include VaxLisp, Allegro
CL, and Lucid. Lucid and VaxLisp already accept an interpreted function
object as the "definition" argument to COMPILE.
Cost to implementors:
Most of the changes required for this proposal are already necessary
to correctly implement the FUNCTION-TYPE proposal. The primary addition
is that COMPILE must be extended to accept a FUNCTION object as well
as a lambda expression as the "definition" argument.
Cost to users:
None. This is an upward-compatible change, since a lambda expression
can still be passed as an argument to COMPILE. Also, since most
existing implementations refuse to compile a function with a non-empty
lexical environment, user code which depends on being able to do this
is already nonportable.
Benefits:
An area of ambiguity in the language is resolved.
Discussion:
An alternative behavior when trying to COMPILE as function that is
already compiled would be to do nothing.
-------
∂23-Sep-88 1054 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:38 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28938; Fri, 23 Sep 88 11:53:11 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02502; Fri, 23 Sep 88 11:53:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231753.AA02502@defun.utah.edu>
Date: Fri, 23 Sep 88 11:53:07 MDT
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: x3j13@sail.stanford.edu
Issue: EVAL-WHEN-NON-TOP-LEVEL
References: CLtL p. 69-70
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Other proposals being considered by the compiler cleanup
committee require that we clarify how the compiler should process
EVAL-WHENs appearing at non-top-level, such as within LET or FUNCTION
special forms.
Proposal: EVAL-WHEN-NON-TOP-LEVEL:CLARIFY
In this proposal, we view EVAL-WHEN as a macro which expands into a
PROGN containing the body of the EVAL-WHEN when the context in which it
is expanded matches one of the situations listed, or NIL otherwise.
However, it is explicitly *not* proposed that EVAL-WHEN's status as
a special form be changed.
The EVAL situation corresponds to the normal processing of the
interpreter. If EVAL is specified, the interpreter evaluates each
form in the body of the EVAL-WHEN as an implicit PROGN, using the
current lexical environment. If the EVAL situation is not specified,
then the interpreter must return NIL as the value of the EVAL-WHEN
form, without evaluating the body.
The LOAD situation corresponds to the normal processing of the
compiler. If LOAD is specified, the compiler treats the EVAL-WHEN as
a PROGN and compiles the body in the normal way in the appropriate
lexical environment. Otherwise, the form is equivalent to specifying
a constant value of NIL. (The name LOAD is something of a misnomer,
because ``evaluation'' of the body happens not at LOAD time, but when
the EVAL-WHEN form would normally be ``evaluated''. For example, if
an EVAL-WHEN form appears in the body of a DEFUN, it is ``evaluated''
when that function is called.)
The COMPILE situation is a special case; it indicates that the
compiler itself should evaluate the body of the EVAL-WHEN form as an
implicit PROGN in the null lexical environment. During the
evaluation, if a nested EVAL-WHEN appears in the body, the interpreter
follows its usual rule of checking only whether or not the EVAL
situation is specified to decide whether or not the body of the nested
EVAL-WHEN should be processed.
If both the COMPILE and LOAD situations are specified, the compiler
first performs the evaluation for the COMPILE situation. Then, the
normal processing for the LOAD situation takes place, except that the
compile-time evaluation of nested (EVAL-WHEN (COMPILE) ...) forms in
the body is suppressed, preventing repeated evaluations of subforms.
(EVAL-WHEN (COMPILE) ...) should be used with caution in non-top-level
situations. For example, if the following appears as a top level form
in a file being compiled
(let ((x (some-hairy-computation)))
(eval-when (eval compile load) (print x)))
the variable X will be treated as special during the compile-time
evaluation, and the value printed will be its symbol-value. To
guarantee consistency between compile-time evaluation and the normal
processing, one should wrap the entire top-level form in an EVAL-WHEN,
as follows:
(eval-when (eval-compile load)
(let ((x (some-hairy-computation)))
(print x)))
Rationale:
The behavior of top-level EVAL-WHENs as specified in this proposal
remains almost identical to that specified in CLtL. The major
addition is specifying the lexical environment in which non-top-level
EVAL-WHENs are processed. It is clear that the COMPILE situation must
always be processed in the null lexical environment, since the actual
lexical environment is not available at compile time. Having the EVAL
and LOAD situations evaluate in the proper environment leads to
differing semantics, but it appears to be the behavior that most
people expect, and it is also the easiest to implement.
Suppression of COMPILE evaluations in nested EVAL-WHENs is necessary
to achieve certain desirable behaviors, such as the macro example in
section 4 of the DEFINING-MACROS-NON-TOP-LEVEL proposal.
Although viewing EVAL-WHEN as a macro is useful for purposes of
explanation, user code is likely to want to continue to treat EVAL-WHEN
as a special form. For example, a preprocessor that performs a code
walk should leave EVAL-WHENs intact, since the context in which the
preprocessor runs may not be the same as the context in which the code
it produces runs.
Current Practice:
Cost to implementors:
Probably fairly minor in most implementations.
As an implementation technique, we suggest implementing EVAL-WHEN as a
macro which uses a state variable to keep track of the current context.
A sample implementation might look something like:
(defvar *compiling-p* nil "Are we compiling or interpreting?")
(defmacro eval-when (situations &body body)
(cond
;; If the COMPILE situation applies, evaluate the body now
;; and also see if we need to do the LOAD situation too.
;; If so, shadow the definition of EVAL-WHEN to make it
;; ignore nested compile-time evaluation requests, and
;; return the body.
((and *compiling-p* (member 'compile situations))
(eval `(progn ,@body))
(if (member 'load situations)
`(macrolet ((eval-when (situations &body body)
(if (member 'load situations)
`(progn ,@body)
'nil)))
,@body)
'nil))
;; If either the EVAL or LOAD situation applies, return a PROGN.
((if *compiling-p*
(member 'load situations)
(member 'eval situations))
`(progn ,@body))
;; Otherwise no situation applies, so just return NIL.
(t
'nil)))
;;; Eval must bind *compiling-p* to NIL.
(defun eval (form)
(let ((*compiling-p* nil))
:
))
;;; Compile and Compile-file must bind *compiling-p* to a non-nil value.
(defun compile (name &optional definition)
(let ((*compiling-p* t))
:
))
(defun compile-file (input-pathname &key output-file)
(let ((*compiling-p* t))
:
))
Cost to users:
Since CLtL does not currently specify what the meaning of EVAL-WHEN
forms at non-top-level is, existing code which depends on their use is
already nonportable. Preventing repeated evaluations of subforms when
EVAL-WHENs are nested is unlikely to cause any serious compatibility
problems, since the current model would already result in only a
single evaluation in the case when the code is processed
interpretively.
There are also some situations concerning nested top-level occurences
of EVAL-WHEN that CLtL does not completely specify, to which this
proposal does assign a specific interpretation. For example, CLtL is
unclear on whether or not (FOO) would ever be called, while in the
current proposal it would definitely not be called:
(eval-when (compile)
(eval-when (compile)
(foo)))
Benefits:
Clarifying the meaning of EVAL-WHEN allows the behavior of defining
macros such as DEFMACRO to be specified in terms of EVAL-WHEN. As a
side effect, it would then become meaningful for defining macros to
appear at other than top-level.
Discussion:
This proposal reflects what appears to be the consensus of the
compiler cleanup committee on this issue.
-------
∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:57:54 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29038; Fri, 23 Sep 88 11:56:26 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02532; Fri, 23 Sep 88 11:56:23 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231756.AA02532@defun.utah.edu>
Date: Fri, 23 Sep 88 11:56:22 MDT
Subject: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
To: x3j13@sail.stanford.edu
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
Status: **DRAFT**
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program. While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase. For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation. User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.
In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.
In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well. Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.
(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.
(a) Macro definitions must be available in the compiletime environment.
The compiler may assume that forms that are lists beginning with
a symbol that does not name a macro or special form is a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) Special variables must be declared as such before they are bound.
The compiler must treat any undeclared variable binding as a
lexical binding.
(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment. However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment. Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation. In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(f) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
retain the same definition in the runtime environment as in the
compiletime environment. (Note that it is not an error for an
unknown type to appear in a declaration at compiletime, although
it is reasonable for the compiler to emit a warning in such a
case.)
(g) The compiler may assume that a class name defined by DEFCLASS
that is present in the compiletime environment will also be a
class name at runtime, and that class will be an instance of the
same metaclass. There may be additional conformance requirements
imposed by the metaclass, but there are none for STANDARD-CLASS.
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the behavior of the program is undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2d) above. It is, however,
reasonable for the compiler to emit warning messages about
calls to functions that are defined at compiletime, but where
the wrong number or type of arguments are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible to emit
a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
I know of no compiler that does not implement the provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
-------
∂23-Sep-88 1054 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:54:04 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28914; Fri, 23 Sep 88 11:52:40 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02497; Fri, 23 Sep 88 11:52:36 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231752.AA02497@defun.utah.edu>
Date: Fri, 23 Sep 88 11:52:35 MDT
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: x3j13@sail.stanford.edu
Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References: CLtL pages 66-70, 143
Category: CLARIFICATION
Edit history: V1, 07 Oct 1987 Sandra Loosemore
V2, 15 Oct 1987 Sandra Loosemore
V3, 15 Jan 1988 Sandra Loosemore
V4, 06 May 1988 Sandra Loosemore
V5, 20 May 1988 Sandra Loosemore
V6, 09 Jun 1988 Sandra Loosemore
Problem Description:
Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled. However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly. In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are.
Inter-file compilation dependencies are distinct from, and not
addressed by, this issue.
Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled. A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form. This is also the recommended implementation technique.
(2) The affected defining macros and their specific side effects are
as follows:
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations.
DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly. The body of the macro (but not necesarily its expansion) must
be evaluable at compile time.
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline. Portable code should not rely on DEFUN making
the function definition available at compile time.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. The initial value
form must not be evaluated at compile time.
DEFCONSTANT: The compiler must recognize the symbol as being constant
(for example, to suppress warnings about references to the symbolic
constant as an unbound variable or to enable warnings about binding or
SETQ'ing the constant in the code being compiled). Neither evaluation
of the value-form or SETQ'ing of the symbol may occur at compile-time.
However, if the (unevaluated) value-form is CONSTANTP, the compiler is
allowed to build assumptions about the value of the constant into
programs being compiled, as described on p. 68-69 of CLtL.
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file. The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be.
DEFSTRUCT: The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE. The structure slot accessors must be made
known to SETF. In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE. For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:
(defmacro foo (x) `(car ,x))
(eval-when (eval compile load)
(print (foo '(a b c))))
A portable way to do the same thing would be to include the macro definition
inside the EVAL-WHEN:
(eval-when (eval compile load)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Rationale:
The proposal reflects standard programming practices. The primary
purpose of the proposal is to make an explicit statement that CL
supports the behavior that most programmers expect and many
implementations already provide.
Current Practice:
Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.
In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent calls
to COMPILE or COMPILE-FILE), but are not available to the interpreter
(even within the file being compiled).
Kyoto Common Lisp is a notable offender. By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL. There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.
Cost to implementors:
Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique. The
intent of the proposal is specifically not to require the compiler to
have special knowledge about each of these macros.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.
Benefits:
Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.
Discussion:
Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive.
It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism. A separate proposal
seems more appropriate.
There has also been a suggestion that DEFCONSTANT should always
evaluate the value provided. The behavior specified in this proposal
makes DEFCONSTANT similar to DEFVAR and DEFPARAMETER, while allowing
the user to explicitly ask for compile-time evaluation using the #. read
macro.
Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter. The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.
-------
∂23-Sep-88 1058 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:58:36 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29064; Fri, 23 Sep 88 11:57:04 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02537; Fri, 23 Sep 88 11:57:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231757.AA02537@defun.utah.edu>
Date: Fri, 23 Sep 88 11:56:59 MDT
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE
To: x3j13@sail.stanford.edu
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
References: CLtL p. 182 [package functions],
p. 156 [PROCLAIM], P. 188 [REQUIRE],
p. 439 [COMPILE-FILE];
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CLARIFICATION
Edit History: 15 Sept. 88, V1 by David Gray
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
Status: **DRAFT**
Problem Description:
Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
to the following package functions as though they were wrapped in an
(EVAL-WHEN (COMPILE LOAD EVAL) ...):
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
There are other things that need special handling by the compiler that
are not explicitly specified by CLtL. The proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY addresses the part of
the problem pertaining to macros that define things. The following
proposal adds PROCLAIM and REQUIRE to the list of functions needing
special handling.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:CLARIFY:
Clarify that when COMPILE-FILE encounters a call to one of the following
functions at top level in a file, the form will be evaluated at compile
time as well as at load time:
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE PROCLAIM REQUIRE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
Note that the compile-time evaluation of these package functions can
affect the way that the remaining top-level forms in the file are read.
In the case of PROCLAIM, it is implementation-dependent whether the
evaluation affects the global environment or is only recorded in data
structures used by the compiler, and whether the effect of the
evaluation remains in the global environment after COMPILE-FILE returns.
(PROCLAIM '(OPTIMIZE ...)) is a special case that is evaluated only at
compile-time and not at load time, and that affects only the current
file being compiled.
Note that the behavior specified here can still be altered by the
user by wrapping an explicit EVAL-WHEN around the form.
Rationale:
Experience seems to have shown that this behavior best matches what
people expect to have happen. The examples on pages 189 and 191 of CLtL
won't work right unless REQUIRE takes effect at compile-time. Since
most of the things that PROCLAIM can be used for only affect the
compiler, it doesn't make much sense for the compiler to not take notice
during compilation. Optimization control is something that one usually
wants to control locally, rather that having a proclamation in one file
affect other unrelated files compiled later.
Current Practice:
This proposal follows what the Explorer does, except that (EVAL-WHEN
(LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything. The Symbolics
compiler has special top-level handling for all of these functions,
although the details are not clear. The Lucid documentation indicates
that certain functions at top-level are treated as though within an
(EVAL-WHEN (EVAL COMPILE LOAD) ...): REQUIRE, all of the package
functions listed above, INTERN, and UNINTERN; it is not clear what
happens with PROCLAIM.
Cost to implementors:
Since implementations are already required to have a mechanism for
compile-time handling of the package functions, it should only require
minor adjustments to add handling for PROVIDE and REQUIRE if they aren't
handled already. The main thing that most implementations would need to
do is to make OPTIMIZE proclamations local to the file, but that should
be fairly simple.
Cost to users:
If someone has a use of REQUIRE that they want to only be a load-time
dependency and their implementation did not previously do REQUIRE at
compile-time, they may want to wrap (EVAL-WHEN (EVAL LOAD) ...) around
it.
If someone has a use of (PROCLAIM '(OPTIMIZE ...)) that they really want
to be global, they would need to wrap (EVAL-WHEN (EVAL COMPILE LOAD)
...) around it.
Benefits:
Users will know what to expect when they use PROCLAIM and REQUIRE.
Costs of Non-Adoption:
In order to write programs that would be sure to be portable, the user
would have to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around each use
of PROCLAIM or REQUIRE in order to be sure of what will happen.
Aesthetics:
Programs look cleaner if EVAL-WHEN is only needed for unusual cases
instead of being required for the normal cases.
Discussion:
Cleanup proposal PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE wanted to add an
option to PROCLAIM to control whether the effect is local to the current
file. That may be better handled by an extension to EVAL-WHEN since
that kind of control might be wanted for definitions as well as
proclamations. If the handling of OPTIMIZE specified here is taken as a
default, that issue can be pursued separately from this one.
There have been objections raised to treating (PROCLAIM '(OPTIMIZE...))
specially.
If DEFPACKAGE is accepted, we may wish to remove the "magical" behavior
of the package functions entirely, and propose a macro (DEFPROCLAIM?)
to deal with PROCLAIM. How do people feel about making this kind of
incompatible change to the language?
-------
∂23-Sep-88 1055 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 10:55:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28959; Fri, 23 Sep 88 11:53:47 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02507; Fri, 23 Sep 88 11:53:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231753.AA02507@defun.utah.edu>
Date: Fri, 23 Sep 88 11:53:41 MDT
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: x3j13@sail.stanford.edu
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unspecified.
Resolution of other issues (EVAL-WHEN-NON-TOP-LEVEL and
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS) now allows reasonable
semantics to be assigned to defining forms which appear at
non-top-level.
Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW
(1) Clarify that while defining macros normally appear at top level,
it is meaningful to place them in non-top-level contexts and that the
compiler must handle them properly in all situations. Remove the
language on p. 66 of CLtL which states that the compiler is not
required to recognize defining macros at other than top-level.
(2) The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
defines a model for specifying how defining macros work. To
summarize, the expansion of the macro (rather than its expander
function) is responsible for storing information about the definition.
Compile-time side effects are typically handled by including one or
more EVAL-WHEN forms in the expansion. A compiler may choose
some other implementation, such as treating defining macros as
implementation-specific special forms, provided that the semantics
are compatible.
(3) Defining macros which define functional objects (such as DEFUN and
DEFMACRO) must ensure that the functions are defined in the lexical
environment in which the defining macro appears. In the model
referred to above, this would normally be implemented by producing a
FUNCTION special form in the macro expansion. For example, the
following code causes the function BAR to be closed over the variable
X:
(let ((x (some-hairy-computation)))
(defun bar (y) (+ x y)))
(4) The language on p. 145 of CLtL, which states that macro functions
are always defined in the null lexical environment, should be removed.
Instead, the defining forms DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and
the complex form of DEFSETF, which make functional definitions
available at compile time, use the environment which is apparent at
the time of evaluation. When calls to these macros appear in a
non-null lexical environment, an explicit (EVAL-WHEN (COMPILE) ...)
must normally be wrapped around the entire containing top-level form
to ensure that the correct lexical environment is seen at both compile
time and load time.
An example may help clarify why this is necessary. The code fragment
(let ((x (some-hairy-computation)))
(defmacro bar-macro (y) `(+ ,x ,y)))
would macroexpand into something similar to
(let ((x (some-hairy-computation)))
(eval-when (eval compile load)
(setf (macro-function 'bar-macro)
#'(lambda (form env)
(let ((y (second form)))
`(+ ,x ,y))))
'bar-macro))
Since the rules for (EVAL-WHEN (COMPILE) ...) state that evaluation
takes place in the null lexical environment, in this situation X would
be treated as a special variable within the macro function. However,
in the EVAL or LOAD situations, the lexical value of X would be used.
To ensure consistency, the correct definition would be:
(eval-when (eval compile load)
(let ((x (some-hairy-computation)))
(defmacro bar (y) `(+ ,x ,y))))
(5) Clarify that ``top-level forms'' are evaluable data objects read
in from an input source (such as a keyboard or disk file) by
successive calls to the function READ; these forms would be evaluated
by the interpreter in a null lexical environment. As special cases,
forms within a top-level PROGN or COMPILER-LET are also considered to
be top-level forms, as is the expansion of a macro call appearing at
top-level. Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, but the order in which
subforms of a top-level form are processed by the compiler is
explicitly left unspecified. It is an error for user code to depend
upon the compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.
Rationale:
The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').
There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there. However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether.
Current Practice:
CLtL mentions only that forms within a top-level PROGN, and not
COMPILER-LET, are treated as top-level. However, COMPILER-LET is
also treated specially in implementations derived from the MIT Lisp
Machine (TI and Symbolics), as well as Lucid and Coral (but not
VaxLisp).
Cost to implementors:
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special is removed from
the language. Allowing defining macros to appear anywhere instead of
restricting them to certain positions results in a cleaner language
design.
Discussion:
-------
∂23-Sep-88 1212 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 12:12:09 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 23 Sep 88 15:11:42 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 23 Sep 88 15:09:39 EDT
Date: Fri, 23 Sep 88 15:10 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02507@defun.utah.edu>
Message-Id: <19880923191014.6.BARMAR@OCCAM.THINK.COM>
Date: Fri, 23 Sep 88 11:53:41 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, but the order in which
subforms of a top-level form are processed by the compiler is
explicitly left unspecified. It is an error for user code to depend
upon the compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.
I don't understand this part. Could you give an example of code that
has such a dependency?
barmar
∂26-Sep-88 0931 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:16 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465233; Sun 25-Sep-88 15:09:13 EDT
Date: Sun, 25 Sep 88 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02502@defun.utah.edu>
Message-ID: <880925150859.4.KMP@GRYPHON.SCRC.Symbolics.COM>
I'm sorry. At the last meeting, I stated that I had reservations about
this proposal and said I would send some mail and I never did. I did say
at that time, though, that the root of my problem was that there were
insufficient examples and that this made me nervous because this is a
hard issue to reason about and (I think) an easy one to get wrong.
-- Specific Remarks --
Your use of phrases like "the interpreter" in the proposal make me
nervous because I work with at least one compiled-only implementation
(Cloe).
Your remarks about
(let ((x (some-hairy-computation)))
(eval-when (eval compile load) (print x)))
treating X as special in the compile situation are not supported by any
part of CLtL that I know of. X is treated as "free", but that situation
is not defined by CLtL as far as I know.
Btw, I don't see why the term "hairy" needs to be in that example.
The issue would be the same for a trivial computation.
Your references to EVAL being like "normal processing of the interpreter"
and LOAD being like "normal processing of the compiler" are too obscure
for me to figure out. Perhaps you mean "normal execution of interpreted
code" and "normal execution of compiled code"? If so, I might begin to see
what you mean, but since the presence of compiled-only and interpreted-only
implementations makes these phrases vague, I'd want to see this clarified.
I am also unconvinced that LOAD really corresponds to "normal execution".
In my code, it often addresses things that really only want to be done
once and never again because at top-level, things can't happen more than
once. I'm not at all clear that if I had a DEFFOO macro which expanded
into (EVAL-WHEN (LOAD) ...) and someone put the DEFFOO in the body
of (DEFUN BAR ...) -- a thing you're apparently advocating -- that I
would want the thing in the LOAD clause executing every time they called
BAR.
Also, you don't offer enough info for me to figure out what happens when
both EVAL and LOAD are specified in the interpreter.
In general, the absence of examples makes this just hard to follow.
-- General Remarks --
I believe that the real problem with EVAL-WHEN is that its keywords do
not map straightforwardly onto the things we really need to say. For
example, when we really want to do something abstract like "provide
macro support at semantic analysis time" we are instead forced to
designate times (EVAL COMPILE) because we happen to know that that is
when semantic analysis takes place and we must cover our bets.
I think there is no fix for EVAL-WHEN other than to identify keywords
which are equally meaningful to interpreter-only and compiled-only
implementations. I would rename COMPILE to something meaning ``semantic
analysis time,'' LOAD to something meaning ``first occurrence in
execution environment'' and EVAL to mean something like ``execution
time.'' But then I would also want to require interpreted-only
implementations to do a semantic-prepass so that ``semantic analysis
time'' where all macros were expanded at once and all EVAL-WHEN's
figured out at a definite time rather than being permitted to occur
lazily.
Since I don't really feel convinced about what you're proposing and since
I think what I might propose is a ``research'' project too ambitious
to get into at this point, I would prefer that EVAL-WHEN continue to
be illegal except at toplevel and that we just pin down a status-quo
description of what EVAL-WHEN already does, asking Kathy to acknowledge
in the manual that we know its design is less than pretty and that
the design of a better primitive is a research topic.
∂26-Sep-88 0931 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465246; Sun 25-Sep-88 16:59:01 EDT
Date: Sun, 25 Sep 88 16:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231753.AA02507@defun.utah.edu>
Message-ID: <880925165852.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Since this proposal is apparently (although not explicitly) dependent on
your EVAL-WHEN-NON-TOP-LEVEL:CLARIFY, and since I don't support that
proposal, it shouldn't come as a surprise that I can't support this one.
In addition to whatever comments might carry through from my objections
to that proposal, however, I also have these concerns:
* I don't think the nesting under the proposed definition of DEFMACRO
is consistent. Consider:
(DEFUN FOO ...
(DEFMACRO BAR ...))
Under your proposed EVAL-WHEN semantics, the definition of BAR will
be available at compile time for all forms following FOO's definition,
but it will not become available at runtime until FOO is called.
This strikes me as very baroque.
* We have a charter to do something about establishing normative
practice. When McCarthy was visiting, he suggested that one thing
that goes with that is making sure that if you're encouraging people
to do something, it's something you can reasonably expect to support
efficiently. It follows, I think, that if you change the language
to encourage people to do DEFUN inside of DEFUN, DEFMETHOD inside of
DEFMETHOD, etc., you'd better make it efficient. In fact, though,
many implementations do lots of "junk" at compiled file load time
which you wouldn't want executed every time you ran a function.
* For the most part, it doesn't make any sense to do
(DEFUN ... (DEFUN ...)) so it seems strange to encourage it.
The only practical reason I can think of for doing this is to do
some sort of module facility where you selectively activate definitions
that you need by calling the outer function. I think this is what
LOAD and packages are already in CL for, and although I don't think they
are the answer to all the world's problems, they are better than
doing nested defuns.
* The Scheme language attaches a very different meaning to
(DEFUN FOO (X)
(DEFUN BAR (X) ...) ... (BAR ...) ...)
than we do. I've seen novices screwed by doing this and having it work.
[It does in most interpeters.] They -think- they are getting a local
function when really they're getting BAR globally redefined every time
they run FOO. They don't find out until they do
(DEFUN BAZ (X)
(DEFUN BAR (X) ...) ... (BAR ...) ...)
and start calling FOO and BAZ in complicated, mutually recursive situations
with BAR getting clobbered back and forth until disaster finally strikes.
The CL style for local definitions is LABELS, FLET, etc. and I think
we should just stick to that.
I don't pretend that these are all the objections that I would have if I
thought for more than ten minutes on this issue, but they seem to me to
be sufficiently major to warrant some pretty careful thought before
proceeding on this.
I would prefer that defining forms just be restricted to toplevel
because we don't have time in the next three months to do any better
than that.
∂26-Sep-88 0931 X3J13-mailer issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 09:31:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 465244; 25 Sep 88 16:41:52 EDT
Date: Sun, 25 Sep 88 16:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: sandra%defun@cs.utah.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8809231752.AA02497@defun.utah.edu>
Message-ID: <880925164139.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Sorry about the delay in replying. I have a number of comments
about this proposal...
Date: Fri, 23 Sep 88 11:52:35 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Ultimately, I expect to support this proposal though I have some
reservations about many sections in the current draft...
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, ...
A convenient model for explaining how these side effects happen is
that the defining macro expands into one or more EVAL-WHEN forms ...
This is also the recommended implementation technique.
This last sentence is gratuitous. It adds nothing to the proposal
and makes me very nervous. For example:
(PROGN (PROCLAIM '(SPECIAL *WHATEVER*))
(SETQ *WHATEVER* 3))
is a better expansion for DEFVAR than anything involving EVAL-WHEN.
As another example, many implementations get by fine with DEFUN
turning into
(SETF (SYMBOL-FUNCTION 'WHATEVER) #'(LAMBDA ...))
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations.
If it uses SATISFIES of a named, user-defined function in its expansion,
must the function be available at compile time for the type specifier to
be considered `valid' ? Can/should implementations give an undefined-function
warning at compile time?
DEFMACRO, DEFINE-MODIFY-MACRO: Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
"occurrences"
correctly. The body of the macro (but not necesarily its expansion) must
"necessarily"
be evaluable at compile time.
Whether the expansion is necessary depends on whether the macro is itself used
subsequently in the file in the body of another macro being defined. eg,
(DEFMACRO FOO ...)
(DEFUN BAR-FUNCTION ... (FOO ...)) ;Needs FOO body
(DEFMACRO BAR-MACRO ... (FOO ...)) ;Needs FOO body and expansion
By similar reasoning, whether the macro body needs to be executable is not a
given. You might not plan to use the macro in the remainder of the file, in which
case it need only be compilable but not executable until load time.
The two situations seem symmetric to me in this respect, so I don't understand
the use of the asymmetric construction "The body ... (but not necesarily its
expansion) must ...".
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline. Portable code should not rely on DEFUN making
the function definition available at compile time.
Does this imply that it's permitted? That may make sense for COMPILE, but
it doesn't make sense for COMPILE-FILE. COMPILE-FILE should be a no-op (or
a ``copy-file'' equivalent) in interpreter-only implementations. There should
be no side-effect of doing COMPILE-FILE, so that (COMPILE-FILE "A") followed
by (LOAD "A") will load "A" only once.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. The initial value
form must not be evaluated at compile time.
DEFCONSTANT: The compiler must recognize the symbol as being constant
This sentence is pretty vacuous unless you intend to make the "for example"
items that follow into requirements (which would make this an incompatible
change for some). Do you really mean to imply anything useful by this
sentence and if so, what?
(for example, to suppress warnings about references to the symbolic
constant as an unbound variable or to enable warnings about binding or
SETQ'ing the constant in the code being compiled).
I assume these are just examples and not something you're trying to require.
Be clear.
Neither evaluation
of the value-form or SETQ'ing of the symbol may occur at compile-time.
My guess is that this might be an incompatible change for some environments.
I think some implementations permit
(DEFCONSTANT FOO 3)
(DEFCONSTANT BAR (+ FOO 1))
The effects of incompatible changes aren't really addressed adequately in
the subsequent sections. Rather than CLARIFICATION for category above, you
might want to write CLARIFICATION/CHANGE to alert people to the fact that
some (technically "non-portable", but possibly "intended to be portable")
code may be affected.
However, if the (unevaluated) value-form is CONSTANTP, the compiler is
allowed to build assumptions about the value of the constant into
programs being compiled, as described on p. 68-69 of CLtL.
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file. The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be.
As with DEFMACRO, this depends on whether this SETF is used in the remainder
of the file. In general, I find this wording awkward because the first sentence
is a restriction on the compiler and the second is a restriction on the user
and they're just haphazardly mixed together. This isn't the only place where
that happens in this topic writeup.
DEFSTRUCT: The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE. The structure slot accessors must be made
"in subsequent declarations" ?
known to SETF. In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.
I'm not sure it's wise to be ambiguous on this. What's the motivation here?
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
... In particular, ...
If you mean that
(DEFMACRO FOO ...)
(DEFMACRO BAR ... (FOO ...))
is not permissible, again your are talking [a fairly major] incompatible change
to some implementations for which you've insufficient cost analysis.
Rationale:
The proposal reflects standard programming practices.
With one or two notable exceptions, cited above.
... Current Practice: ...
Kyoto Common Lisp is a notable offender.
This statement is not adequately qualified and somewhat inflammatory.
Your current practice statement would be no less complete and somewhat
more diplomatic if you just struck this sentence altogether.
... Cost to implementors: ...
Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique.
What's easy (or even desirable) in one implementation may not be in another.
I don't think you've motivated this statement adequately.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.
Not so in all cases. See remarks above.
Benefits:
Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.
I agree with the intent here, but until the issues raised above have been
addressed, I can't agree with the specifics.
Discussion:
Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive....
Please don't take my reaction as negative, but don't count me as overwhelmingly
positive either.
∂26-Sep-88 1041 X3J13-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 26 Sep 88 10:41:39 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA00628; Mon, 26 Sep 88 10:37:14 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA16788; Mon, 26 Sep 88 10:40:00 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA18918; Mon, 26 Sep 88 10:39:55 PDT
Message-Id: <8809261739.AA18918@suntana.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL
In-Reply-To: Your message of Sun, 25 Sep 88 15:08:00 -0400.
<880925150859.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 10:39:52 -0700
From: kempf@Sun.COM
>analysis time,'' LOAD to something meaning ``first occurrence in
>execution environment'' and EVAL to mean something like ``execution
Or LOAD should mean something like "mapping of relative addresses
to absolute physical addresses", i.e. linking of separately compiled
code.
I agree that this is a thorny issue which needs more thought and
think EVAL-WHEN should remain illegal except at "top level" as
it currently is.
jak
∂26-Sep-88 1203 X3J13-mailer Hawaii hotel arrangements
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 12:03:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA09281g; Mon, 26 Sep 88 11:01:19 PST
Received: by challenger id AA13605g; Mon, 26 Sep 88 11:59:03 PDT
Date: Mon, 26 Sep 88 11:59:03 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809261859.AA13605@challenger>
To: X3J13@sail.stanford.edu
Subject: Hawaii hotel arrangements
We have a block of rooms reserved the 14th - 22nd of January at the Sheraton
for $80/night. Unless I change these dates you will be charged $120/night for
any dates before or after the reserved block (I know, they're bogones). If
you are planning to be there longer than the week of the conference (or arrive
earlier) please let me know ASAP what those dates are so I can try to adjust
the block to include those dates. I have to call them back Thursday morning.
Aloha,
---jan---
∂29-Sep-88 1544 X3J13-mailer Fairfax attendees
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:43:19 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00246g; Thu, 29 Sep 88 14:41:12 PST
Received: by challenger id AA00805g; Thu, 29 Sep 88 15:38:54 PDT
Date: Thu, 29 Sep 88 15:38:54 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292238.AA00805@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax attendees
Thus far:
X3J13 Attendee Information
09/23/88
Name Institute Paid L1 L2
Jim Antonisse The MITRE Corporation - y -
Kim Barrett USC - - -
David Bartley TI y y y
Paul Beiser HP - y y
Danny Bobrow Xerox y y y
Skona Brittian MSC y y y
Kathy Chapman Digital Equipment Corporation - - -
Jeff Dalton University of Edinburgh - y y
Jerry Duggan HP - y y
Dick Gabriel Lucid, Inc. - y y
David Gray TI y y y
George Hadden Honeywell Systems \& Research - y y
Gregor Kiczales Xerox PARC - y y
Timothy Koschmann Southern Illinois University y y y
Aaron Larson Honeywell - y y
Thom Linden IBM y y y
David Loeffler MCC - y y
Sandra Loosemore Evans & Sutherland - y y
Barry Margolin Thinking Machines - y y
Larry Masinter Xerox PARC y y y
Bob Mathis Contel - y y
Crispin Perdue Sun Microsystems - y y
Dan Pierson Encore - y y
Kent Pitman Symbolics - y y
Rick Tucker Mitre Corporation - y y
David Unietis Lucid, Inc. - y y
Mary Van Deusen IBM Research y y y
Walter van Roggen Digital Equipment Corporation - y -
Ellen Waldrum TI - y y
JonL White Lucid, Inc. - y y
Jan Zubkoff Lucid, Inc. - y y
∂29-Sep-88 1546 X3J13-mailer Fairfax Subcommittee Meetings Update
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:46:06 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00255g; Thu, 29 Sep 88 14:44:00 PST
Received: by challenger id AA00811g; Thu, 29 Sep 88 15:41:40 PDT
Date: Thu, 29 Sep 88 15:41:40 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292241.AA00811@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Subcommittee Meetings Update
Subcommittee meetings
October 10, 1988
9:30 - 5:00 Characters (4-5)
9:30 - 12:30 Cleanup (?)
12:30 - 4:30 Editorial
2:00 - 5:00 Compiler (12)
2:30 - 5:00 Iteration (4)
∂29-Sep-88 1544 X3J13-mailer Fairfax Updated Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 15:44:29 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00252g; Thu, 29 Sep 88 14:42:24 PST
Received: by challenger id AA00808g; Thu, 29 Sep 88 15:40:06 PDT
Date: Thu, 29 Sep 88 15:40:06 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809292240.AA00808@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Updated Agenda DRAFT
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Danny Bobrow (20 minutes)
8 CLOS Chapter 3, Gregor Kiczales (20 minutes)
9 Compiler Subcommittee Report and Vote, Sandra Loosemore (2 hrs)
10 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
11 Recess, 5:00pm
12 Call to Order, October 12, 9:00am
13 Clean-up, Larry Masinter
14 Lunch, 12:00pm - 1:00pm
15 Error Terminology, Dan Pierson (30 minutes)
16 Registry for Packages, Modules, Features, Larry Masinter
17 Public-ftp access, Larry Masinter
18 Other committee reports
19 Adjournment, 5:00pm
∂29-Sep-88 1825 X3J13-mailer Re: Fairfax Updated Agenda DRAFT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88 18:25:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 SEP 88 18:16:24 PDT
Date: 29 Sep 88 18:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Fairfax Updated Agenda DRAFT
In-reply-to: Jan Zubkoff <jlz@lucid.com>'s message of Thu, 29 Sep 88
15:40:06 PDT
To: Jan Zubkoff <jlz@lucid.com>
cc: x3j13@sail.stanford.edu
Message-ID: <880929-181624-1531@Xerox>
The two other topics I wanted to discuss -- registry for packages, modules,
features, and public-ftp access for public Common Lisp programs, I thought
would only take about 30 minutes, mainly just to organize something.
∂30-Sep-88 0956 X3J13-mailer Fairfax attendees
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Sep 88 09:55:45 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 30 Sep 88 12:44:03 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 30 Sep 88 12:52:50 EDT
Date: Fri, 30 Sep 88 12:53 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Fairfax attendees
To: Jan Zubkoff <jlz@lucid.com>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8809292238.AA00805@challenger>
Message-Id: <19880930165324.8.BARMAR@OCCAM.THINK.COM>
Date: Thu, 29 Sep 88 15:38:54 PDT
From: Jan Zubkoff <jlz@lucid.com>
Thus far:
X3J13 Attendee Information
09/23/88
Name Institute Paid L1 L2
Barry Margolin Thinking Machines - y y
I had our purchasing department send you a check with the registration
form. Did you receive the registration form without a check?
barmar
∂30-Sep-88 1236 X3J13-mailer March '89 X3J13/ISO meeting host needed
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Sep 88 12:36:18 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00792g; Fri, 30 Sep 88 11:34:12 PST
Received: by challenger id AA01696g; Fri, 30 Sep 88 12:31:53 PDT
Date: Fri, 30 Sep 88 12:31:53 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809301931.AA01696@challenger>
To: x3j13@sail.stanford.edu
Subject: March '89 X3J13/ISO meeting host needed
I need a volunteer from the Boston area to host the X3J13 meeting March 27 -
29 and the ISO meeting March 30 - 31. Please let me know if you're
interested.
---jan---
∂30-Sep-88 1405 X3J13-mailer Arpanet access during Fairfax meeting
Received: from hqda-ai.ARPA by SAIL.Stanford.EDU with TCP; 30 Sep 88 14:05:48 PDT
Received: by hqda-ai.ARPA; Fri Sep 30 16:43:12 1988
From: Bill Arbaugh <arbaugh@hqda-ai.ARPA>
Message-Id: <8809302043.AA02302@hqda-ai.ARPA>
To: x3j13@sail.stanford.edu
Date: Fri, 30 Sep 88 16:43:10 EDT
Subject: Arpanet access during Fairfax meeting
X-Mailer: Elm [version 1.5b]
If you do not have a TAC card and would like to have access
to the arpanet for mail and etc., contact me directly and I can
help.
Bill
==========================================================
Bill Arbaugh Phone: (202) 694-6912
UUCP: *!uunet!cos!hqda-ai!arbaugh ARPA: arbaugh@hqda-ai.arpa
==========================================================
∂03-Oct-88 1122 X3J13-mailer Subcommittee Meetings at Contel
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 11:22:04 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00587g; Mon, 3 Oct 88 10:19:33 PST
Received: by challenger id AA00351g; Mon, 3 Oct 88 11:15:46 PDT
Date: Mon, 3 Oct 88 11:15:46 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810031815.AA00351@challenger>
To: x3j13@sail.stanford.edu
Subject: Subcommittee Meetings at Contel
Please note that the subcommittee meetings will be held at Contel. Ask for
Bob Mathis. Security will escort you to the meeting rooms.
---jan---
∂03-Oct-88 1252 X3J13-mailer Error terminology
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 12:52:40 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06841; Mon, 3 Oct 88 12:51:06 PDT
Message-Id: <8810031951.AA06841@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Oct 88 15:42
To: x3j13@sail.stanford.edu
Subject: Error terminology
Following is the proposed error terminology for the forthcoming standard. The
editorial committee has not completely finished shaking the bugs out of this
document, but we thought you might like to comment on it yourselves both
now and at the October meeting. We hope to have consensus on this terminology
in the near future so that it can be used during the writing of phase 2 of
the standard.
Thanks in advance for your review time.
Condition Terminology
September, 1988
Edited by Kathy Chapman, Kent Pitman, Walter Van Roggen
!
Page 2
1 INTRODUCTION
Common Lisp constructs are described in the forthcoming
standard in terms of their behavior in "situations" during which
they are intended to be used (see "Description" and
"Environment/Evaluation" parts of each construct specification),
and in all other "situations" (see "Conditions" part of
specification).
A "situation" is the evaluation of an expression in some
specific context. A "condition", represented by a condition
object, is a situation which has been detected. Some types of
conditions are predefined by the Common Lisp system, and all types
of conditions are subtypes of type CONDITION, i.e. (typep c
'condition) is true if and only if C is a condition. An "error"
is a condition in which normal program execution may not continue
without some form of intervention (either interactively by the
user or under some sort of program control).
"Signalling" is the process by which a situation is announced
by a program and SIGNAL is a mechanism by which such announcement
is done. ERROR and CERROR are also used to signal errors.
Signalling an error has no side-effect on the condition associated
with the error, and there is no dynamic state contained in a
condition object. The interactive interface for signalling is
implementation-dependent.
The process of signalling involves the search for and
invocation of a handler, which is a function of one argument (the
condition) that attempts to deal with the situation. Handlers are
established dynamically using HANDLER-BIND or abstractions built
on HANDLER-BIND such as HANDLER-CASE and IGNORE-ERRORS.
IGNORE-ERRORS is used to inhibit entry to the debugger when all
errors are detected, while HANDLER-CASE is used to perform
specified actions when the specified situations occur. If a
handler is found, it may either handle the situation by performing
some non-local transfer of control or "decline" by failing to
perform a non-local transfer of control. If it declines, other
handlers are sought. If no handler is found and the error was
signalled by ERROR or CERROR, the debugger is entered with no
context change.
The debugger prints the description of the situation
represented by the error being signalled along with contextual
information perhaps including information such as which function
detected the error. The debugger should prefix all lines in a
multiline condition message with the character or indentation used
in the first of the lines of the message. The debugger allows
interactive examination or modification of the state of the
program and restarting from the situation.
The condition object given to the handler is created
explicitly by an operation such as MAKE-CONDITION or implicitly by
an operation such as SIGNAL. The handler is executed in the
dynamic context of the program which has invoked it, except that
!
Page 3
the set of available condition handlers will have been rebound to
the value that was active at the time the condition handler was
made active.
2 TERMINOLOGY
Situations in which errors might, should, or must be
signalled are referred to in the standard. The wording used to
describe such situations is intended to have precise formal
meaning. The following list is a glossary of those meanings.
- A VALID PROGRAM
is a program whose code adheres to the requirements of
conforming code listed as follows:
- Conforming code shall not use any constructions that are
prohibited by the standard.
- Conforming code shall not depend on extensions included in
an implementation.
- Conforming code shall not use any extension included in an
implementation.
- A SAFE SITUATION
is a situation in which interpreted code, or code
compiled with the safest optimization level is run.
- AN UNSAFE SITUATION
is a situation in which code compiled with lower safety
levels is run.
- AN ERROR "IS SIGNALLED"
means that
- If this situation occurs, the error will be signalled, in
both safe and unsafe situations.
- Valid programs may rely on the fact that the error will be
signalled in both safe and unsafe situations.
- Every implementation is required to detect the error in
both safe and unsafe situations.
For example, "an `error is signalled' if UNEXPORT is
given a symbol not accessible in the current package."
!
Page 4
- AN ERROR "SHOULD BE SIGNALLED"
means that
- If this situation occurs, the error will be signalled in
safe situations but may not be signalled in unsafe ones.
- Valid programs may not rely on the fact that the error
will be signalled.
- Every implementation is required to detect the error at
least in safe situations.
- When the error is not signalled, the "consequences are
undefined" (see below).
In summary, the situation which has been identified as an
error is illegal in all implementations, but some
implementations do not actually detect the situation.
For example, "an error `should be signalled' if ENDP is
given a non-list argument."
- THE "CONSEQUENCES ARE UNDEFINED"
means that
- If this situation occurs, the consequences are
unpredictable. The consequences may range from harmless
to fatal.
- Implementations are allowed to detect this situation and
signal an error, but no implementation is required to
detect the situation.
- No valid program may depend on the effects of this
situation, and all valid programs are required to treat
the effects of this situation as unpredictable.
- In places where the words "must", "must not" or "may not"
are used, then "the consequences are undefined" if the
stated requirement is not met, and no specific consequence
is explicitly stated.
There are two principal reasons why this language permits
a situation to have an undefined consequence rather than
requiring an error to be signalled:
- Detecting the situation might be prohibitively expensive
in some or all implementations.
!
Page 5
- An "implementation may be extended" to cover this
situation.
For example, "the `consequences are undefined' is there
is an attempt to redefine the name of a special form."
- THE "RETURN VALUES ARE UNDEFINED"
means that only the number and nature of the return
values of a construct are not well defined but any side-effect
and transfer-of-control behavior is well defined.
For example, if the return values of some function F are
undefined, then an expression such as (length (list (F))) is
still well-defined because it does not rely on any particular
aspect of the value or values returned by F.
- THE "CONSEQUENCES ARE UNSPECIFIED"
means that
- The consequences of this situation are not specified in
the standard, but will not, by themselves, cause execution
to abnormally terminate.
- Implementations are allowed to specify the consequences of
this situation.
- No portable program can depend on the consequences of this
situation, and all portable programs are required to treat
the situation as unpredictable but harmless.
For example, "if the second argument to SHARED-INITIALIZE
specifies a name that does not correspond to any slots
accessible in the instance, the `consequences are
unspecified.'"
- "IMPLEMENTATIONS MAY BE EXTENDED" TO COVER THIS SITUATION
means that an implementation is free to treat the
situation in ANY ONE of the following ways.
1. When the situation occurs, an error is signalled at least
in safe situations,
OR
2. When the situation occurs, the "consequences are
undefined",
OR
!
Page 6
3. When the situation occurs, the consequences are defined
and specified.
Also, no portable program can depend on the consequences
of this situation, and all portable programs are required to
treat the consequences of the situation as undefined.
For example, "`implementations may be extended' to define
other type specifiers to have a corresponding class."
- IMPLEMENTATIONS ARE "FREE TO EXTEND THE SYNTAX"
means that in this situation
- Implementations are allowed to define unambiguous
extensions to the syntax of the construct being described.
- No portable program can depend on this extension, all
portable programs are required to treat the syntax as
meaningless.
The standard may disallow certain extensions while
allowing others.
For example, "no `implementation is free to extend the
syntax' of DEFCLASS."
- A "WARNING IS ISSUED"
means that
- If this situation occurs, a warning is issued, as
described in WARN, in both safe and unsafe situations.
- Valid programs may rely on the fact that a warning will be
issued in both safe and unsafe situations.
- Every implementation is required to detect this situation
in both safe and unsafe situations.
- The presence of a warning will in no way alter the value
returned by the form which caused the situation to occur.
For example, "a `warning is issued' by the compiler if a
declaration specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
- A "WARNING SHOULD BE ISSUED"
!
Page 7
means that
- If this situation occurs, a warning will be issued at
least in safe situations.
- Valid programs may not rely on the fact that a warning
will be issued.
- Every implementation is required to detect such a
situation at least in safe situations.
- The presence of a warning will in no way alter the value
returned by the form which caused the situation to occur.
For example, "a warning `should be issued' by a compiler
if a variable declared to be ignored is ever referred to or is
also declared special, or if a variable is lexical, never
referred to, and not declared to be ignored." (see Chapter 9,
CLtL)
∂04-Oct-88 1159 X3J13-mailer Hotel reservations for Hawaii
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Oct 88 11:58:04 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01362g; Tue, 4 Oct 88 10:55:36 PST
Received: by challenger id AA03260g; Tue, 4 Oct 88 11:53:17 PDT
Date: Tue, 4 Oct 88 11:53:17 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810041853.AA03260@challenger>
To: x3j13@sail.stanford.edu
Subject: Hotel reservations for Hawaii
There seems to be a little confusion regarding my last note. I asked for the
dates people would be staying in Hawaii only as a reference point to extend
the time in which the reduced fee would be available. This was not an offer
to make hotel reservations. You should contact the hotel directly if you wish
to make reservations.
808/822-3455 ask for Liz Anne
Cheers!
---jan---
∂04-Oct-88 2041 X3J13-mailer Re: error definitions
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Oct 88 20:41:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 88 19:59:52 PDT
Date: Tue, 4 Oct 88 19:59 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: error definitions
To: Barry Margolin <barmar@Think.COM>, Dick Gabriel
<RPG@SAIL.Stanford.EDU>, chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.Stanford.EDU, x3j13@sail.stanford.edu,
DJAHANDARI%TOWNS.DEC@decwrl.dec.com, POPA%TOWNS.DEC@decwrl.dec.com
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <19881003194959.0.BARMAR@OCCAM.THINK.COM>,
<OlxIJ@SAIL.Stanford.EDU>,
<19881003212644.4.BARMAR@OCCAM.THINK.COM>,
<8810031951.AA06841@decwrl.dec.com>,
<km9wo@SAIL.Stanford.EDU>
Message-ID: <19881005025941.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 04 Oct 88 11:01 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I might point out that the CLOS committee didn't come up with this
terminology as a joke or in a fit of stupidity. Nor did we accidentally
forget the CLtL terminology. We designed it deliberately and in full
knowledge that it differed from CLtL terminology. Furthermore, we used
that terminology very carefully in the CLOS document.
Right, and more detail about this to follow.
Date: 03 Oct 88 14:06 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'm not following the debate on this, but I see the question raised
about what these two phrases mean:
1. ``consequences are undefined''
2. ``implementations may be extended''
This terminology was introduced after a great deal of thought about how
to prevent the so called "number of arguments to IF" bug. We believe
that we have restricted the syntactic extensions that can be made to
CLOS, and that that restriction is important for a variety of reasons.
CLOS is a language which provides a great deal of extensibility, and
given that it is a very important concept to be able to restrict that
in places where it is appropriate.
- THE "CONSEQUENCES ARE UNSPECIFIED"
I am not up to speed on this issue, and I am tired, but I believe it is
important that "THE CONSEQUENCES ARE UNSPECIFIED" must not include
"IMPLEMENTATIONS MAY BE EXTENDED" in any way.
-------
∂06-Oct-88 1249 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:49:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472004; Thu 6-Oct-88 15:48:14 EDT
Date: Thu, 6 Oct 88 15:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881006154802.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
The following issue will be presented at the upcoming meeting.
We might try to vote on this if people feel it non-controversial
enough, but the "two-week rule" could be invoked to suppress a
vote if someone felt they had inadequate time to consider it.
-----
Issue: ERROR-NOT-HANDLED
References: Interactive Condition Handling (Condition System, Rev 18, p19)
Category: CLARIFICATION/CHANGE
Edit history: 25-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
For delivery purposes, some implementations will want to leave out
major sections of runtime support in programs that do not require
them. The debugger is one such section.
However, since ERROR may be called implicitly by a number of Common
Lisp built-in functions, and since the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled, the interactive debugger must be retained in
a saved image of any program that might signal an error unless the
compiler can prove that the error will never go unhandled. This
may be undesirable in some cases and may cause unnecessary bloating
of the saved image.
Proposal (ERROR-NOT-HANDLED:PERMIT-TERMINATION):
Permit implementors to designate an implementation-specific mechanism
for asking that unhandled errors cause `termination of the running
program' rather than entry into the system's debugger.
Implementations choosing to offer such a facility must clearly define
the nature and scope of such program termination, since the concept
of `program termination' is an ill-defined concept in present-day
Common Lisp.
Even when program termination rather than debugger entry would be
the ultimate effect of an unhandled error, the value of
*DEBUGGER-HOOK* (if non-NIL) must be called to provide programmers
the ability of customized debugging.
All implementations must at least provide the option of a system
debugger for use in program development.
Test Case:
(ERROR "Foo"), if unhandled, must now enter the debugger.
Under this proposal, it might also `terminate program execution'
in implementations which choose to provide such a facility and to
clearly define that concept.
Rationale:
Although technically an incompatible change, we're dealing at
the very edge of what the user can expect from the system. Once
an error is signalled and not handled, we're in the domain of
implementation-dependent effect anyway.
Current Practice:
Probably no one does this yet.
Cost to Implementors:
None. This change is upward compatible with existing implementations.
Cost to Users:
None.
Cost of Non-Adoption:
Saved Lisp images might be forced to be gratuitously larger than
they need to be in some implementations.
Benefits:
Addressing this issue will make Lisp more able to compete with
other languages which permit small saved images to result from
small user programs.
Aesthetics:
No significant impact.
Discussion:
This change was requested by Christian Queinnec of France
(queinnec@inria.inria.fr). Pitman supports the change.
∂06-Oct-88 1317 X3J13-mailer Fairfax Registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:17:15 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00489g; Thu, 6 Oct 88 13:16:04 PDT
Received: by challenger id AA05749g; Thu, 6 Oct 88 13:12:27 PDT
Date: Thu, 6 Oct 88 13:12:27 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810062012.AA05749@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax Registration
X3J13 Attendee Information
10/05/88
Name Institute Paid L1 L2
Jim Allard Gensym - y y
Jim Antonisse The MITRE Corporation - y -
Bill Arbaugh U.S. Army AI Center - y y
Kim Barrett USC - - -
Kim Barrett Integrated Inference Machines y y y
David Bartley TI y y y
Paul Beiser HP - y y
Danny Bobrow Xerox y y y
Mary Boelk Johnson Controls - y y
Skona Brittian MSC y y y
Tom Bucken Prime Computer y - -
Kathy Chapman Digital Equipment Corporation - - -
Chris Dabrowski NBS - - -
Jeff Dalton University of Edinburgh - y y
Jerry Duggan HP - y y
Dick Gabriel Lucid, Inc. - y y
David Gray TI y y y
George Hadden Honeywell Systems \& Research - y y
Gregor Kiczales Xerox PARC - y y
Timothy Koschmann Southern Illinois University y y y
Aaron Larson Honeywell - y y
Thom Linden IBM y y y
David Loeffler MCC - y y
Sandra Loosemore University of Utah - y y
Barry Margolin Thinking Machines y y y
Larry Masinter Xerox PARC y y y
Bob Mathis Contel - y y
Tracey Miles Unisys - y y
Crispin Perdue Sun Microsystems - y y
Dan Pierson Encore - y y
Kent Pitman Symbolics y y y
Jeff Rosenking ISI - y y
Rick Tucker Mitre Corporation - y y
Tom Turba Unisys y - y
David Unietis Lucid, Inc. - y y
Mary Van Deusen IBM Research y y y
Walter van Roggen Digital Equipment Corporation - y y
Ellen Waldrum TI - y y
JonL White Lucid, Inc. - y y
Jan Zubkoff Lucid, Inc. - y y
----------------
35 35
∂06-Oct-88 1328 X3J13-mailer Revised DRAFT Agenda
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:28:44 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00522g; Thu, 6 Oct 88 13:27:37 PDT
Received: by challenger id AA05784g; Thu, 6 Oct 88 13:24:00 PDT
Date: Thu, 6 Oct 88 13:24:00 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8810062024.AA05784@challenger>
To: x3j13@sail.stanford.edu
Subject: Revised DRAFT Agenda
**************DRAFT**************
X3J13 Committee Meeting Agenda
October 11 - 12, 1988
1 Call to Order, October 11, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
- Report on ISO meeting, Dick Gabriel
- Report on Scheme meeting, David Bartley
3 Approval of Agenda
4 Approval of Minutes
5 Character Subcommittee Report and Vote, Thom Linden (3 hrs)
6 Lunch, 12:00pm - 1:00pm
7 CLOS Workshop Report, Danny Bobrow (20 minutes)
8 CLOS Chapter 3, Gregor Kiczales (20 minutes)
9 Loop, JonL White (20 minutes)
10 Compiler Subcommittee Report and Vote, Sandra Loosemore (2 hrs)
11 Editorial Subcommittee Report, Kathy Chapman (30 minutes)
12 Recess, 5:00pm
13 Call to Order, October 12, 9:00am
14 Clean-up, Larry Masinter
15 Lunch, 12:00pm - 1:00pm
16 Registry for Packages, Modules, Features, Larry Masinter (15 minutes)
17 Public-ftp access, Larry Masinter (15 minutes)
18 Other committee reports
19 Adjournment, 5:00pm
20
!
Next meeting: 1/16 - 1/18 1989 Kauaii Hawaii
∂06-Oct-88 1714 X3J13-mailer X3J13 issues to be emailed: stay tuned for barrage
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:14:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 17:09:44 PDT
Date: 6 Oct 88 17:09 PDT
From: masinter.pa@Xerox.COM
Subject: X3J13 issues to be emailed: stay tuned for barrage
To: X3J13@Sail.stanford.edu
Message-ID: <881006-170944-1740@Xerox>
We have had a huge barrage of mail on numerous cleanup
issues; a number have come in at the last minute.
Some issues are ready for voting at X3J13; it will be nice
to get as many of these out of the way as possible. Others,
as will be identified, are in draft form and not ready for voting; we'll
cover the issue at the plenary session in any case, since we
need to have all open issues completely resolved by
the January meeting.
I hope to have hardcopy available at the meeting as well.
∂06-Oct-88 1718 X3J13-mailer Issue: ALIST-NIL (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:18:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 17:12:44 PDT
Date: 6 Oct 88 17:12 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: ALIST-NIL (Version 4)
To: x3j13@SAIL.Stanford.EDU
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <881006-171244-1747@Xerox>
!
Issue: ALIST-NIL
References: Definition of "a-list" (p279), ASSOC (p280)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
04-Sep-88, Version 2 by Masinter (reflect discussion)
21-Sep-88, Version 3 by Masinter (minor edits)
01-Oct-88, Version 4 by Pitman (remove some bias)
Problem Description:
NIL is permitted to be an element of an a-list but very little of
use can be done with such an element, and the idea can be confusing.
In most situations where an a-list entry is to be removed, it is
done by straightfoward uses like
(SETQ THE-ALIST (REMOVE THE-ENTRY THE-ALIST))
or (SETQ THE-ALIST (DELETE THE-ENTRY THE-ALIST)).
Relatively few situations require the more advanced technique of
(SETF (CAR THE-ALIST-TAIL) NIL)
in order to remove an entry from a list. Usually these situations
involve multiple pointers into different parts of the same a-list,
or very long a-lists where DELETE or REMOVE would take a long time.
Proposal ALIST-NIL:DISALLOW:
Change the definition of an a-list to require all elements to be
real conses. Uses of ASSOC with non-standard a-list would be an error.
Test Case:
(ASSOC 'X '(NIL (X . 3)))
is currently defined to return (X . 3).
Under this proposal, this would be an error.
Rationale:
An a-list is a commonly used data structure that should be easy to
explain. Permitting NIL in an a-list complicates the description
considerably.
This change would make the relationship between FIND (with key of
#'CAR) and ASSOC simpler and easier to explain.
Current Practice:
All valid implementations permit NIL in an a-list.
Cost to Implementors:
Since the proposal is to make this an "is an error" situation, no
implementation would be forced to change.
Cost to Users:
There are two basic ways in which we expect this feature is used
currently.
#1: A user wants a leading NIL on an a-list so that if the list
is empty, there's still be a tail to which cells could be
attached in the future. That is,
(DEFVAR *MY-ALIST* (CONS NIL '()))
so that
...(NCONC *MY-ALIST* (LIST new-cell))...
would always be possible as a side-effect and
...(ASSOC element *MY-ALIST*)...
would always be possible for lookup. It might be argued that
this is more clearly written:
(DEFVAR *MY-TABLE* (CONS NIL '()))
(DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
(DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
...(ADD-ENTRY new-cell *MY-TABLE*)...
...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving
the place that the element occupied in the list. In the very rare cases
where this was necessary, one could rewrite:
(DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
as:
(DEFUN VOID-FIRST-ENTRY (ALIST)
(LET ((ENTRY (CONS NIL NIL)))
(SETF (CAR ENTRY) (GENSYM)) ;or ENTRY or something otherwise unique
(SETF (CAR ALIST) ENTRY)))
This might change the behavior of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF
and RASSOC-IF-NOT depending on the predicate used.
Also, in this case, the user must also consider that whatever is used
as the unique key must be acceptable to ASSOC.
In rare cases where neither of these rewrites were acceptable, the user could
still write his own variant of ASSOC to handle NIL even if the system version
did not.
Cost of Non-Adoption:
The only consequence of non-adoption is the burden of carrying around
the additional complexity in each implementation, in the documentation,
and in teaching. The cost of this burden is likely to be a subjective
matter.
Benefits:
FIND (with a :KEY of #'CAR) and ASSOC (with no key) would be identical.
Aesthetics:
This change would simplify the language.
Discussion:
The description of association lists is currently cluttered by this
unmotivated feature; no strong motivation or widespread use
of the feature has been found.
Some people consider this change gratuitous.
The cleanup committee discussed some interesting optimizations
of ASSOC where the existing situation (special-casing NIL) didn't
actually cost in performance (at least in the special case where
the predicate was EQ or EQL), so performance issues were dismisse
d
as a rationale for this change.
∂06-Oct-88 1752 X3J13-mailer Arpanet access during Dallas PI meeting
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:52:18 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 141274; Thu 6-Oct-88 20:51:07 EDT
Date: Thu, 6 Oct 88 20:51 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Arpanet access during Dallas PI meeting
To: Bill Arbaugh <arbaugh@hqda-ai.ARPA>
cc: x3j13@sail.stanford.edu, Hewitt@XX.LCS.MIT.EDU
In-Reply-To: <8809302043.AA02302@hqda-ai.ARPA>
Message-ID: <19881007005108.0.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Bill,
I would like to obtain a TAC card.
Thanks,
Carl
∂06-Oct-88 1806 X3J13-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 18:06:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 18:02:04 PDT
Date: 6 Oct 88 18:02 PDT
From: masinter.pa@Xerox.COM
to: x3j13@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Message-ID: <881006-180204-1855@Xerox>
apologies if you got this twice; there was a mailer hiccup here.
!
Issue: ARGUMENTS-UNDERSPECIFIED
References: LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363),
MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
SET (p 92)
Issue: RANGE-OF-START-END-PARAMETERS.
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
4-Sep-88, version 2 by Masinter
19-Sept-88, Version 3 by Chapman
21-Sep-88, Version 4 by Masinter
Problem Description:
The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER
are not clear about the types of the arguments supplied to these
constructs.
Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
Clarify that the arguments for the listed constructs are as follows:
Construct Argument Type
LOGBITP index non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER char character
MAKE-HASH-TABLE size non-negative integer
MAKE-SEQUENCE size non-negative integer
MAKE-SEQUENCE type type specifier
MAKE-STRING size non-negative integer
MAKE-STRING initial-element string-char
NTHCDR n non-negative integer
SET-SYNTAX-FROM-CHAR to-char,from-char characters
READ and others eof-value any value
SET value any value
(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
their respective SIZE arguments; for example, MAKE-STRING may detect an error if
SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. Some additional
restriction on the range of characters which can have syntax in readtables
and are allowable to MAKE-DISPATCH-MACRO-CHARACTER SET-SYNTAX-FROM-CHAR might
be required in some other proposal.)
Rationale:
This clarification allows predictible results to occur when
arguments are supplied to these constructs.
Current Practice:
This proposal seems to be in line with current implementations.
Cost to Implementors:
None, since this is consistent with current practice.
Cost to Users:
None, since this is consistent with current practice.
Benefits:
This clarification will assist users in writing portable code.
Aesthetics:
The standard would be less clean were the allowed ranges of its functions not
specified.
Discussion:
There is a separate cleanup proposal RANGE-OF-START-END-PARAMETERS which
addresses a possible incompatible change. This proposal contains what we
think are non-controversial clarifications.
----- End Forwarded Messages -----
∂06-Oct-88 1921 X3J13-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:21:12 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:18:51 PDT
Date: 6 Oct 88 19:18 PDT
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Subject: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881006-191851-1973@Xerox>
!
Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
References: CLtL p.194
Category: CHANGE
Edit history: Version 1, 14-Sep-88, Moon
Problem description:
The numerical contagion rules specified on CLtL p.194 make it impossible
for the numerical comparison functions to be transitive when given
arguments of mixed floating and rational types (see example below).
Proposal (CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE):
Instead of using the same contagion rule both for combining functions
and for comparing functions, make the present rule apply only to
combining functions and add the following rule: When rational and
floating-point numbers are compared by a numerical function, the
function RATIONAL is called to convert the floating-point number to a
rational and then an exact comparison is performed. In the case of
complex numbers (RATIONAL is for some unknown reason only allowed on
reals), the real and imaginary parts are handled individually.
It is of course valid to use a more efficient implementation than
actually calling RATIONAL, as long as the result of the comparison is
the same.
Test Cases/Examples:
(defvar a (/ 10.0 single-float-epsilon))
(= a (1+ (floor a)))
should be NIL, since
(= a (floor a))
is certainly T and
(= (floor a) (1+ (floor a)))
is certainly NIL. However, by the rule of floating-point contagion,
(= a (1+ (floor a)))
is the same as
(= a (float (1+ (floor a)) a))
and the latter form is certainly T.
To understand this example better, it helps to realize that
(= a (+ a 1.0))
is always true, by the definition of single-float-epsilon.
Here is a second example:
(defvar i (floor a))
(<= a (+ i 1)) is T.
(< (+ i 1) (+ i 2)) is T.
(<= (+ i 2) a) is T by CLtL, NIL by this proposal.
Thus CLtL requires
a <= i+1 < i+2 <= a
which ought to imply
a < a
which is absurd.
Rationale:
Transitivity of = and of < are important to many algorithms. What CLtL
says now was probably not intentional, but just the result of thinking
that comparing and combining could be lumped together without really
thinking about it.
Without this change, it is impossible to extend the :TEST argument to
MAKE-HASH-TABLE to allow = or EQUALP, since there could be two table
entries with rational keys that are not =, then GETHASH could be
presented with a floating-point argument that is = to both keys.
Current practice:
Lucid is said to implement the proposal. As far as I know all other
implementations do what CLtL currently says.
Cost to Implementors:
This requires a change in what is likely to be intricate and
implementation-dependent code. However, the total effort should
be small compared to the cost of writing that code originally.
Cost to Users:
This is an incompatible change. It's difficult to know if any users
are depending on the current behavior. It seems likely that most users
would expect the proposed behavior, and may be wondering why their
programs don't quite work when the numbers get large.
Cost of non-adoption:
Comparison functions in Common Lisp will be non-transitive.
Benefits:
Comparison functions in Common Lisp will be transitive.
Esthetics:
Having two rules of floating-point contagion may seem less esthetic,
but I'm certain that having the comparison functions behave in a more
mathematically correct fashion outweighs that esthetically.
Discussion:
Everyone who has expressed an opinion has thought this was the right
thing for years, but we never got around to writing it up as a cleanup
proposal.
----- End Forwarded Messages -----
∂06-Oct-88 2007 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:06:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472330; Thu 6-Oct-88 23:05:17 EDT
Date: Thu, 6 Oct 88 23:05 EDT
From: Masinter.PA@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Reply-To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881006230506.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable not
to be a member of the declared type, within the scope of the declaration.
Clarify that the above programs are valid, and that this kind of
declaration means the same thing as wrapping a THE form around every
reference to the variable, including modifying references by setq or
setf.
Clarify that if nested type declarations refer to the same variable, then
the value of the variable must be a member of the intersection of the
declared types.
Rationale:
It enables optimizing compilers to make use of the otherwise ignored
type information. Many people have often asked for it, and there is
no strong reason to forbid it.
Current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already; but under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂06-Oct-88 2058 X3J13-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:12:18 PDT
Date: 6 Oct 88 20:12 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
to: x3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
REPLY-TO: Cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881006-201218-2044@Xerox>
apologies if you get this twice; more mailer problems...
!
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
Problem description:
Currently, defstruct constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow combination of &OPTIONAL, &KEY and &AUX arguments in
constructor forms of defstructs.
The current wording in CLtL (p314):
"In addition, the keywords &optional, &rest, and &aux are recognised
in the argument list. They work in the way you might expect ..."
would be extended accordingly.
Example:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Some implementations to signal an error. Envos Medley (Xerox Common Lisp)
implements the proposed behavior.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
∂06-Oct-88 2057 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:57:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:30:02 PDT
Date: 6 Oct 88 19:30 PDT
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
REPLY-TO: CL-CLEANUP@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Message-ID: <881006-193002-1990@Xerox>
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Issue FUNCTION-TYPE (passed X3J13/June 1988)
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
#3, 30-Sep-88, Masinter
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
Using the same declaration for two completely different purposes can lead
to confusion among people writing or reading such code.
It is now more useful to declare that variables have a value which
is of type FUNCTION, since the type FUNCTION has a more well-specified
meaning.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
Many current implementations treat FUNCTION declarations
only as abbreviations for FTYPE declarations, primarily because
the proposal FUNCTION-TYPE has not been widely implemented.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods.
Since all cases can be disambiguated after all, compatibility considerations
might deem this proposal to be unnecessary. However, making declarations
simpler and less confusing is possibly more important than compatibility.
There is no consensus on the cleanup committee.
∂06-Oct-88 2058 X3J13-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:57:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 19:40:12 PDT
Date: 6 Oct 88 19:40 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
To: x3j13@SAIL.STANFORD.EDU
REPLY-TO: CL-CLEANUP@Sail.stanford.edu
line-fold: NO
Message-ID: <881006-194012-2001@Xerox>
!
Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT
References: DECODE-UNIVERSAL-TIME (p445)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
30-Sep-88, Version 2 by Masinter
Problem Description:
The description of DECODE-UNIVERSAL-TIME does not say what happens with
TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that
its behavior differs depending on whether a time zone is explicitly passed,
some implementors may have assumed that DECODE-UNIVERSAL-TIME should do
likewise.
Even if all implementations did the same thing, it should still be clarified
whether an implementation were permitted to return dsp=NIL tz=n rather than
dsp=T tz=n+1 for time zones in which daylight savings time was believed to
be (or known to be) in effect. Currently, you cannot tell whether "NIL" for
daylight-savings-time-p means "daylight savings time is in effect" or
just "daylight savings time is not known to not be in effect".
These tools appear to be more portable than they are.
Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE):
Specify that, like ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores
daylight savings information if a timezone is explicitly specified.
Rationale:
This makes things consistent with ENCODE-UNIVERSAL-TIME.
Test Case:
;; ### This test case relies on time zone not changing in real
;; ### time, in defiance of warning in note at bottom
;; ### of p445.
(LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone
(RECENTLY (GET-UNIVERSAL-TIME))
(A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY))))
(B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE)))))
(LIST A B (EQUAL A B)))
Under this proposal, this would return ((T 5) (NIL 5) NIL) in EDT, for example.
Current Practice:
Symbolics Genera, Symbolics Cloe, Lucid 3.0 and Envos Medley seem to
implement this proposal. Some other implementations do not.
Cost to Implementors:
The cost of changing this should be trivial.
Cost to Users:
This feature is already not well-defined since no portable program can rely
on the current behavior, so the cost is small.
Cost of Non-Adoption:
The time primitives are considerably less useful if this point is not
clearly spelled out.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Anything that improves the intelligibility of language primitives improves
language aesthetics.
Discussion:
An alternative would be to specify that, unlike ENCODE-UNIVERSAL-TIME,
DECODE-UNIVERSAL-TIME treats daylight savings information the same
regardless of whether a time zone argument is explicitly or not. This seems
actually to be what was intended originally.
This problem arose while trying to port Macsyma between different
Common Lisp implementations. The cleanup committee does not have
a strong opinion on this matter, as long as the behavior is specified.
∂06-Oct-88 2058 X3J13-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:16:51 PDT
Date: 6 Oct 88 20:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-201651-2055@Xerox>
!
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
V2, 15 Sep 1988, Sandra Loosemore
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type. A print function that uses the
default #S syntax (overriding any print function for the parent type)
can be specified by providing the :PRINT-FUNCTION option without an
argument.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Implementations may wish to use something like CLOS' DEFMETHOD to
implement structure printing, and such methods will naturally be
inherited from the :INCLUDE'd type.
Current Practice:
Lucid Common Lisp makes structures inherit print functions, as do both
Symbolics Genera and Cloe. VaxLisp uses #S syntax unless an explicit
:PRINT-FUNCTION is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Pitman and VanRoggen support this proposal.
The original version of the proposal did not provide for a way to
force #S syntax to be used. This functionality was added to the
current version because there seemed to be general agreement that it
would be useful. Other alternatives would be to name the function
that does what the #S printer does, or to provide a function that
returns the #S information as a list (as suggested by Waters) so users
can write their own.
-------
----- End Forwarded Messages -----
∂06-Oct-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:58:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 20:49:35 PDT
Date: 6 Oct 88 20:49 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: EXPT-RATIO (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-204935-2100@Xerox>
!
Issue: EXPT-RATIO
References: CLtL pages 204 and 211
Category: CLARIFICATION
Edit history: Version 1, 4-Oct-88, by Aspinall and Moon
Version 2, 6-Oct-88, Masinter (very minor discussion)
Problem description:
The comment (page 204, 2nd para) that "... an implementation [of expt]
might choose to compute (expt x 3/2) as if it had been written
(sqrt (expt x 3) 2)" disagrees with the principal value definition on
page 211. See the example below for a case where the two disagree. We
believe the principal value definitions are consistent and reasonable,
therefore the implementation comment is wrong.
Proposal (EXPT-RATIO:211):
Clarify that (sqrt (expt x 3) 2) is not equivalent to (expt x 3/2)
and that page 211 rules.
Test Cases/Examples:
(defvar x (exp (/ (* 2 pi #c(0 1)) 3))) ;exp(2.pi.i/3)
(expt x 3) => 1 (except for round-off error)
(sqrt (expt x 3)) => 1 (except for round-off error)
(expt x 3/2) => -1 (except for round-off error)
There can be no question that
(expt x 3) ==> 1
because expt is single-valued with an integer second argument, and
(sqrt 1) ==> 1
definitely follows the principal branch of the square root function.
But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
(log x) ==> 2.pi.i/3
according to the definition of the logarithm's branch cuts on page 211
(which really comes down to the branch cuts of phase - page 210), so
(* (log x) 3/2) ==> pi.i
and
exp(pi.i) is -1.
Rationale:
We believe the principal value definitions are consistent and
reasonable, therefore the implementation comment is wrong.
Current practice:
Symbolics Genera 7.3 currently returns the wrong answer, following page
204 rather than page 211. Lucid Common Lisp, and
Envos Medley implement the proposal.
Cost to Implementors:
The obvious code changes in complex expt.
Cost to Users:
None.
Cost of non-adoption:
Self-contradictory language specification.
Benefits:
Users can better predict the branch cuts in expt.
Discussion:
Mathematical Explanation: When the expt function returns a complex result
in CL (Cartesian) form, the phase of the complex number is effectively
canonicalized. Information is lost, and that information is necessary to
specify upon which branch of the sqrt function the final result should lie.
Another way to put it would be that although
sqrt(expt(x,3)) = expt(x,3/2)
where expt and sqrt are the mathematical multi-valued functions, it is not
true that:
pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
where pvexpt and pvsqrt denote the principal value versions of those functions.
∂06-Oct-88 2111 X3J13-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:11:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:08:51 PDT
Date: 6 Oct 88 21:08 PDT
From: masinter.pa@Xerox.COM
Subject: Issue FIXNUM-NON-PORTABLE (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-210851-2113@Xerox>
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88 (Sandra Loosemore)
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarly mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
∂06-Oct-88 2123 X3J13-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:23:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:20:45 PDT
Date: 6 Oct 88 21:20 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-212045-2149@Xerox>
!
Issue: FORMAT-E-EXPONENT-SIGN
References: CLtL pp. 366, 393
Category: CLARIFICATION
Edit history: Bob Cassels, 13 Sep 88
Masinter, 2-Oct-88 (change issue name)
Related issues: <none>
Problem description:
The result of (format nil "~E" 1.0) is specified in a contradictory way.
The ambiguity is whether a plus sign should be printed in front of
the exponent.
The top of page 393 says, "Next, either a plus or a minus sign is
printed, followed by e digits ... [decimal exponent]"
Later on page 393 we see, "If all of w, d, and e are omitted, then the
effect is ... [like prin1].
Page 366 [presumably where prin1 is defined] doesn't explicitly say that
the plus sign is omitted from the exponent, but all the examples (and
usual practice) indicate that.
So the posssibilities are:
A. "1.0e+0"
B. "1.0e0"
The first reference implies that A is correct, the third reference
implies that B is correct. The second reference implies that A and B
are the same.
Proposal (FORMAT-E-EXPONENT-SIGN:FORCE-SIGN):
Specify that ~E always prints a plus or minus sign in front of the
exponent.
This would cause the language on page 393 of CLtL to to change:
"If all of w, d, and e are omitted, then the effect is to print the
value using ordinary free-format exponential-notation output; PRIN1 uses
a similar format for any non-zero number whose magnitude is less than
10**-3 or greater than or equal to 10**7. The only difference is that
the ~E directive always prints a plus or minus sign in front of the
exponent, while PRIN1 omits the plus sign if the exponent is
non-negative."
Test Case:
(format nil "~E" 1.0) => "1.0e+0"
Rationale:
This proposal makes ~E self-consistent. That is more important than
making ~E consistent with PRIN1.
Current practice:
Symbolics Common Lisp, Ibuki Lisp, and VAX Lisp all print the plus
sign as in the test case above. Apollo DOMAIN Common Lisp (version
2.10) and Xerox Common Lisp produce "1.0", which is wrong because
it includes no exponent at all.
Adoption Cost:
Minimal changes to one printing routine for non-conforming
implementations. (No change to the three implementations mentioned
above.)
Cost of non-adoption:
Minor confusion and possible incompatibility among implementations.
Benefits:
Less confusion, more compatibility.
Conversion Cost:
Minimal. It is doubtful that any user programs depend on this
obscure distinction.
Esthetics:
A matter of opinion.
Discussion:
Fortran ~E format requires a sign before the exponent, since the exponent
mark character may be dropped. Since Common Lisp ~E always prints
the exponent marker, the exponent sign may be dropped in the case
that it would be a plus sign.
∂06-Oct-88 2150 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:50:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 21:47:56 PDT
Date: 6 Oct 88 21:48 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881006-214756-2172@Xerox>
Version 2 was distributed at a previous X3J13 meeting.
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Version 4, 2-Oct-88 Masinter (update references, discussion)
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
REST-LIST-ALLOCATION
Problem description:
The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, this is actually of limited usefulness in the context of a declaration, where one normally wants type information about the actual arguments which can be passed to the function rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always bound to a value of type LIST. For the sake of consistency, it would seem that the corresponding type given in the FUNCTION declaration must also be LIST, but since this provides no information about the actual arguments, some users/implementors have instead adopted the convention of supplying the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST is the type of each actual argument, not the type of the corresponding lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp implementations currently ignore FUNCTION type declarations. The only examples found so far are in a text book on Common Lisp, which follows the proposed syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do so. Probably only a small amount of code would have to be written/changed in implementations that currently think that the &REST argument should be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must be LIST will have to change their code. However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it would be cleaner and less confusing to provide the type of the lambda variable rather than the type of the actual arguments. However, considering the types specified in the FUNCTION specifier to be the types of the actual arguments rather than the types of the parameters as seen on the receiving end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee and at X3J13. It seems like a vote on LIST-TYPE-SPECIFIER would help clarify some of the issues; if there is a LIST type specifier, there would be more support for the alternative proposal to require that the &REST argument declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE argue that the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a sequence type when in fact there are numerous other places in the language where it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if it is not already in CLtL somewhere) that the following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an obscure case (that doesn't even work in some implementations), it's the sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 07:43:06 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 7 Oct 88 10:42:59 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 7 Oct 88 10:39:56 EDT
Date: Fri, 7 Oct 88 10:40 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue FIXNUM-NON-PORTABLE (Version 3)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881006-210851-2113@Xerox>
Message-Id: <19881007144039.0.BARMAR@OCCAM.THINK.COM>
Date: 6 Oct 88 21:08 PDT
From: masinter.pa@xerox.com
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(2) remove the type BIGNUM from the language.
I don't really see the point of this. Isn't BIGNUM simply defined to be
(AND INTEGER (NOT FIXNUM))? I admit that it isn't an extremely useful
type specifier, but it is just as portable as FIXNUM.
barmar
∂07-Oct-88 1501 X3J13-mailer Issue HASH-TABLE-TESTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:01:13 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 14:45:57 PDT
Date: 7 Oct 88 14:45 PDT
From: masinter.pa@Xerox.COM
Subject: Issue HASH-TABLE-TESTS (Version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-144557-1115@Xerox>
!
Issue: HASH-TABLE-TESTS
References: CLtL, p382 (third paragraph), and p383
Issue EQUAL-STRUCTURE
Requires Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Category: Addition
Edit history: 26-Sep-88 Version 1 by JonL
Problem Description:
A great many users try to coalesce two equivalent defstruct instances,
or two equivalent pointer arrays, using hash tables; but they are rudely
awakened when they find out that EQUAL is not an appropriate test for
this case, and that there is no :test argument to MAKE-HASH-TABLE which
will "hash on non-tree structures".
Proposal: HASH-TABLE-TESTS:ADD-EQUALP
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will
come in four kinds, the difference being whether the keys are compared
with EQ, EQL, EQUAL, or EQUALP.
Examples:
> (defstruct foo a b c)
FOO
> (setq x (make-foo :a 1 :b 'b :c '(1 . 2))
x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
#S(FOO A 1 B B C (1 . 2))
> (setq y #(1 B (1 . 2))
y-copy (copy-seq y))
#(1 B (1 . 2))
> (setq ht-equal (make-hash-table :test 'equal)
ht-equalp (make-hash-table :test 'equalp))
#<Hash-Table BB1F7B>
> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t)
(setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
T
> (gethash x-copy ht-equal)
NIL
NIL
> (gethash x-copy ht-equalp)
T
T
> (gethash y-copy ht-equal)
NIL
NIL
> (gethash (copy-seq y) ht-equalp)
T
T
>
Rationale:
Implementing hash-tables efficiently is not an easy task; it makes more
sense for this to be standardly available (implemented by the wizards at
the Lisp vendor companies) than for individual programmers to keep trying
to re-invent this obscure part of technology.
Current Practice:
Lucid's release 3.0 implements this proposal [some 2.1-level release
supported it "provisionally"]. Symbolics implementation is reputed
to be robust enough to implement this proposal trivially.
Cost to Implementors:
Moderate. Implementors have already dealt with EQUAL; the only tricky
part will be ensuring the implication:
"If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
same collision chain in any given EQUALP hash table"
It has been suggested that merely linear searching a table is an acceptable
implementation technique for CL's hash-tables [although no serious
implementation limits itself thus] and that such tables have no "collision
chains"; but in fact, this is the degenerate case wherein all entries are
in the same collision chain, so the implication is trivially satisfied.
Some persons prefer to say that the "reprobe sequence will be the same for
the two items", rather than using the term "collision chain"; the meaning
is the same.
Cost to Users:
None. This is an entirely upwards-compatible addition.
Cost of non-adoption:
Continuing bug reports from CL vendors' customers about why "hashing
doesn't work" when said customer tries entering pointer-containing objects
other than cons cells into hash tables. Continuing delay in same
customers work until they figure out a new strategy for identifying
equivalent structures. More difficulty in debugging their alternatives.
Benefits:
Addresses one aspect of the difficult equivalence problem. Makes
hash tables usable with the major, remaining equivalence predicate
of CL. Also as a "side effect", permits case-insensitive hashing
on strings [tables of type EQUAL are case-sensitive on strings];
another "side effect" is the abililty to use the CL numeric comparison
"=" for numbers [tables of type EQUAL use EQL on numbers].
Aesthetics:
Reduces the discontinuity between basic equivalence functions and those
usable as equivalence relations in hash-tables.
Discussion:
With the rejection of all the issues related to EQUAL-STRUCTURE, there is
little or no hope that EQUAL will be "beefed up" to meet the expectations
of so many of the user community on compound structures. If one wants
a hash-table with a :test function that has fewer equivalence classes
(i.e., does more "coalescing"), then there is no alternative now except
to use the function EQUALP.
∂07-Oct-88 1501 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:01:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 14:53:48 PDT
Date: 7 Oct 88 14:53 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-145348-1132@Xerox>
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
Related-Issues: DEFPACKAGE
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Require IN-PACKAGE to signal an error if the package does not exist.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
Clarify that DEFPACKAGE is the preferred way to declare a package,
and MAKE-PACKAGE is the preferred way to construct a package at runtime.
Eliminate the compile-time processing requirement for all package-related
functions except IN-PACKAGE and DEFPACKAGE.
Test Case:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;signals an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This would greatly improve error checking and modularity, with only minimal
loss of functionality. Any call to IN-PACKAGE which really needed to
demand-create a package could be rewritten as a DEFPACKAGE followed by an
IN-PACKAGE.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In many cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Discussion:
The cleanup committee supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some members support it only if DEFPACKAGE passes; others would like
to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
However, there might be some compilation problems if IN-PACKAGE
changes and MAKE-PACKAGE signals an error if the package exists.
∂07-Oct-88 1643 X3J13-mailer Issue: NTH-VALUE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:43:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:38:01 PDT
Date: 7 Oct 88 16:38 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: NTH-VALUE (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-163801-1388@Xerox>
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
5-Oct-88, Version 3 by Masinter
(add Current Practice as per Gray)
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Test Cases/Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
The TI Explorer and LMI Lambda have this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Some will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
This is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
(The feature is rarely used in implementations that have it.)
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
There was not strong sentiment for including this feature
in Common Lisp, but no active opposition.
∂07-Oct-88 1642 X3J13-mailer Issue: LAMBDA-FORM (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:42:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:07:33 PDT
Date: 7 Oct 88 16:07 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LAMBDA-FORM (Version 3)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-160733-1324@Xerox>
!
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
02-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
None. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
Some people believe that this makes two different ways to get
essentially the same functionality, and so it clutters the language.
On the other hand, there is at least one precedent for having two
operations that do the identical thing -- NOT and NULL. Both have
been retained because they express different intents. In this case,
the intent of #'xxx might be to ``access'' a function by name (the
name of an anoymous function being its lambda expression), and the
intent of (LAMBDA ...) is to ``create'' a function. This distinction
is subtle but may be expressionally interesting to some programmers
in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks
a lot better than #'(LAMBDA ...). Certainly it takes up fewer
characters, and (LAMBDA ...) is a notable offender in code needing
to be split onto multiple lines, so every little bit probably helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions, etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item addresses this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form, but most people seemed to prefer the
simpler alternative of just making it a macro for now.
∂07-Oct-88 2151 X3J13-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:40 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 20:55:12 PDT
Date: 7 Oct 88 20:55 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-205512-1714@Xerox>
!
Issue: RANGE-OF-START-AND-END-PARAMETERS
References: COUNT (p257), COUNT-IF (p257), COUNT-IF-NOT (p257),
DELETE (p257), DELETE-DUPLICATES (p254), DELETE-IF (p254),
DELETE-IF-NOT (p254), FILL (p252), FIND (p257), FIND-IF (p257),
FIND-IF-NOT (p257), MAKE-STRING-INPUT-STREAM (p330),
MISMATCH (p257), NSTRING-CAPITALIZE (p304),
NSTRING-DOWNCASE (p304), NSTRING-UPCASE (p304), SUBSTITUTE (p255),
NSUBSTITUTE-IF (p256), NSUBSTITUTE-IF-NOT (p256),
PARSE-INTEGER (p381), PARSE-NAMESTRING (p414), POSITION (p257),
POSITION-IF (p257), POSITION-IF-NOT (p257),
READ-FROM-STRING (p381), REDUCE (p251), REMOVE (p253),
REMOVE-DUPLICATES (p254), REMOVE-IF (p253), REMOVE-IF-NOT (p253),
REPLACE (p252), SEARCH (p258), STRING-CAPITALIZE (p303),
STRING-EQUAL (p301), STRING-DOWNCASE (p303), STRING-GREATERP (p302),
STRING-LESSP (p302), STRING-NOT-EQUAL (p302),
STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
STRING-UPCASE (p303), STRING/= (p301), STRING< (p301),
STRING<= (p301), STRING= (p300), STRING> (p301), STRING>= (p301),
SUBSEQ (p248), SUBSTITUTE (p255), SUBSTITUTE-IF (p255),
SUBSTITUTE-IF-NOT (p255), WRITE-LINE (p384), WRITE-STRING (p384)
Category: CLARIFICATION
Edit history: 14-Sep-88, Version 1 by Pitman
Problem Description:
CLtL is not always clear about the possible values which the START and END
parameters of built-in Common Lisp can take.
Proposal (RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL):
Clarify that for functions permitting a parameter named START, START1,
or START2 which delimits the beginning point in a sequence to be
considered for some operation, that paremeter must be a non-negative
integer. If the argument is optional or key (as is the case for all
functions referenced above except SUBSEQ), the value will default to
0 if not supplied. It is not permissible to pass NIL as this argument.
Clarify that for functions permitting a parameter named END, END1,
or END2 which delimits the end point in a sequence to be considered
for some operation, that paremeter must be a non-negative integer
indicating a termination point or NIL indicating the last element
in the sequence. If the argument is optional or key (as is the case
for all functions referenced above), the value will default to NIL
if not supplied. Supplying NIL is, therefore, equivalent to not
supplying this argument.
Test Case:
(SEARCH "F" "FOO" :START1 NIL) is an error.
(SEARCH "F" "FOO" :START2 0) is permissible and is equivalent to
(SEARCH "F" "FOO")
(SEARCH "F" "FOO" :END2 NIL) is permissible and is equivalent to
(SEARCH "F" "FOO")
Rationale:
To keep data flow between programs from becoming excessively complicated,
it's a good idea to specify what the default values are so that they can
be passed explicitly rather than requiring an alternate calling sequence
for all possible cases where the value might need to default.
Current Practice:
Symbolics Genera implements the proposed behavior.
Cost to Implementors:
Hopefully most implementations already do this. Those that do not will
probably have to make quite a number of small changes to both the code
for these functions and to any associated compiler optimizers.
Cost to Users:
This change is upward compatible with existing user code. Any program
which did not conform to this proposal was already not portable.
Cost of Non-Adoption:
Subtle gratuitous differences in the handling of these arguments would
continue to be a possibility and a barrier to portability.
Benefits:
The language would be more regular and well-defined.
Aesthetics:
If it makes things clearer, it's an improvement.
Discussion:
Pitman supports RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.
∂07-Oct-88 2151 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 21:16:06 PDT
Date: 7 Oct 88 21:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-211606-1727@Xerox>
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from these constructs.
Current Practice:
Varies. For example, in Envos Medley, CLOSE returns T, and
set-syntax-from-char returns the "syntax class" of the new character.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Cost to users:
Small; it seems unlikely that there is much code that currently
depends on the return values of these functions; such code isn't
portable.
Aesthetics:
Specified is better than not, when it makes sense.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. There is also some
sentiment for leaving unspecified the values of the debugging/environment
features such as TRACE and UNTRACE, to allow for experimentation and
growth.
∂07-Oct-88 2150 X3J13-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 19:35:45 PDT
Date: 7 Oct 88 19:35 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: X3J13@SAIL.Stanford.EDU
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-193545-1651@Xerox>
Another proposal to extend this to other pathname components
will probably be submitted, but not in time for this meeting.
!
Issue: PATHNAME-TYPE-UNSPECIFIC
References: Pathnames (pp410-413)
Category: CHANGE
Edit history: 27-Jun-88, Version 1 by Pitman
Problem Description:
CLtL (p412) specifies that the type is ``always a string, NIL,
or :WILD.'' This description is too restrictive to be practical.
In file systems which have no first-class notion of a name/type
distinction, it is possible to make files named "foo." and "foo"
which are distinct. One of these (usually the former) can get a
type of "" but it is not clear how to represent the other. If
NIL is used, merging primitives cannot detect that the field is
filled and should not be merged against.
Proposal (PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the type field of a pathname for
operating systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
both cause the component not to appear in the string.
When merging, however, a NIL value for a component will be replaced
with the default for that component, while :UNSPECIFIC will be left
alone.
Test Case:
For file systems where :UNSPECIFIC makes sense...
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :UNSPECIFIC)) => :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (MAKE-PATHNAME :TYPE :UNSPECIFIC)
(MAKE-PATHNAME :TYPE "FOO")))
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file type of :UNSPECIFIC on Unix and
ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which use a non-standard token other than :UNSPECIFIC
to implement this functionality might want to switch to use :UNSPECIFIC so
that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible pathnames
in a rational way and at the same time to conform to the standard.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman supports PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed in the Colander draft edition of CLtL, but was
removed for the Laser edition. The following text is excerpted from
the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
∂07-Oct-88 2152 X3J13-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:51:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 21:50:05 PDT
Date: 7 Oct 88 21:50 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-215005-1749@Xerox>
!
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Version 5 by Pierson 6/28/88, simple design per Masinter
Version 6 by Pierson 7/ 5/88, clean up and split issue
Version 7 by Pierson 7/ 8/88, clean up per Pitman
Version 8 by Pierson 7/ 8/88, yet more clean up
Status: Ready for Release?
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
*TERMINAL-IO*
*STANDARD-INPUT*
*STANDARD-OUTPUT*
*ERROR-OUTPUT*
*TRACE-OUTPUT*
*QUERY-IO*
*DEBUG-IO*
The initial bindings of these variables are undefined except
that:
1. They are all initially bound to open streams.
2. The streams must support input and/or output as
indicated by the variable name.
3. None of the standard streams (including *TERMINAL-IO*)
may be directed by synonym streams to another of these
stream variables (except *TERMINAL-IO*), whether
directly or by indirection via some composite stream
such as a two way stream with one of the arms being a
synonym stream.
4. Any or all of these streams may be synonyms for the
common implementation dependent stream. For example,
in an interactive Common Lisp invocation running on a
character terminal, all of the streams mentioned here
might be synonym streams (or two-way streams to synonym
streams) to a pair of hidden terminal input/output
streams maintained by the implementation.
The intent of the above rules is to ensure that it is always
safe to bind any of the above variables to another of the
above variables without unduly restricting implementation
flexibility.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *ERROR-OUTPUT*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference if *DEBUG-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference
unless the initial value of *DEBUG-IO* had been changed to a value
that did not conform the restrictions in this proposal. While no
Common Lisp implementation should do this, a user program might.
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *TERMINAL-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output. Symbolics Genera binds *TERMINAL-IO* as appropriate for each
process, usually to a window for interactive applications or to a
stream which will conjure an interaction window on demand for
background tasks.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. All known implementations
already support the underlying streams required to implement this
proposal.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists. This proposal fails to address this.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Pierson and Pitman support STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS.
----- End Forwarded Messages -----
∂07-Oct-88 2206 X3J13-mailer STEP-ENVIRONMENT, version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 22:06:27 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 22:03:43 PDT
Date: 7 Oct 88 22:03 PDT
From: masinter.pa@Xerox.COM
Subject: STEP-ENVIRONMENT, version 3
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-220344-1757@Xerox>
!
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 10-Jun-88, Masinter (add discussion)
Version 3, 20-Jun-88, Loosemore (not a special form)
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Clarify that calls to both STEP and TIME may be compiled, but that
in the case of STEP, it is acceptable for an implementation to
interactively step through only those parts of the evaluation that are
interpreted.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. Although STEP is primarily a debugging tool, there is no reason to
prevent it from being compiled correctly.
Current practice:
Vax Lisp behaves as proposed. Symbolics Common Lisp treats STEP as a special
form and does not allow it to be compiled.
Cost to Implementors:
Minimal.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
VaxLisp expands STEP into something like:
(defmacro step (form)
`(let ((*eval-hook* #'step-command-loop))
,form))
∂07-Oct-88 2151 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:51:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 21:26:56 PDT
Date: 7 Oct 88 21:26 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <881007-212656-1734@Xerox>
This issue was distributed at the November 1987 meeting.
It was tabled to allow for discussion of function specs.
The only mail comments, which have not been incorporated,
have been:
Instead of generalizing SYMBOL-FUNCTION, add FDEFINITION and leave
SYMBOL-FUNCTION alone.
Do not modify TRACE and UNTRACE. Leave them implementation-dependent.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
∂07-Oct-88 2215 X3J13-mailer Issue: STREAM-ACCESS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 22:15:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 22:11:28 PDT
Date: 7 Oct 88 22:11 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STREAM-ACCESS (version 1)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-221128-1779@Xerox>
This issue prompted the following comment, which has not been
incorporated:
"The editorial committee should see to it that it's clear that these
types have to do with `structure' rather than `intent' of the resulting
streams. For example, if you broadcast to two string streams, you have a
stream of type BROADCAST-STREAM, not a stream of type STRING-STREAM, etc."
!
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
Proposal: (STREAM-ACCESS:PROVIDE)
Add the following types and functions to the language:
Stream Data Types and Predicates:
BROADCAST-STREAM [Type]
BROADCAST-STREAM-P object [Function]
The predicate is true if the object is of type BROADCAST-STREAM
and is false otherwise. MAKE-BROADCAST-STREAM returns a stream
of type BROADCAST-STREAM.
CONCATENATED-STREAM [Type]
CONCATENATED-STREAM-P object [Function]
The predicate is true if the object is of type CONCATENATED-STREAM
and is false otherwise. MAKE-CONCATENATED-STREAM returns a stream
of type CONCATENATED-STREAM.
ECHO-STREAM [Type]
ECHO-STREAM-P object [Function]
The predicate is true if the object is of type ECHO-STREAM
and is false otherwise. MAKE-ECHO-STREAM returns a stream
of type ECHO-STREAM.
FILE-STREAM [Type]
FILE-STREAM-P object [Function]
The predicate is true if the object is of type FILE-STREAM
and is false otherwise. OPEN returns a stream
of type FILE-STREAM.
STRING-STREAM [Type]
STRING-STREAM-P object [Function]
The predicate is true if the object is of type STRING-STREAM
and is false otherwise. MAKE-STRING-INPUT-STREAM and
MAKE-STRING-OUTPUT-STREAM return a stream of type STRING-STREAM.
SYNONYM-STREAM [Type]
SYNONYM-STREAM-P object [Function]
The predicate is true if the object is of type SYNONYM-STREAM
and is false otherwise. MAKE-SYNONYM-STREAM returns a stream
of type SYNONYM-STREAM.
TWO-WAY-STREAM [Type]
TWO-WAY-STREAM-P object [Function]
The predicate is true if the object is of type TWO-WAY-STREAM
and is false otherwise. MAKE-TWO-WAY-STREAM returns a stream
of type TWO-WAY-STREAM.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Predicate:
OPEN-STREAM-P stream
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
∂07-Oct-88 2317 X3J13-mailer Issue: SUBTYPEP-TOO-VAGUE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:16:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:15:12 PDT
Date: 7 Oct 88 23:15 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: SUBTYPEP-TOO-VAGUE (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-231512-1832@Xerox>
!
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Problem Description:
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂07-Oct-88 2334 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:34:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:33:05 PDT
Date: 7 Oct 88 23:33 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TAGBODY-CONTENTS (Version 4)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-233305-1841@Xerox>
!
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
05-Oct-88, version 4 by Pitman
(modify proposal based on comments from Peck@Sun
-- allow both (GO NIL) and unused duplicated tags)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
TAGBODY treats symbols (including NIL) and integers as tags,
and treats conses as forms.
It is an error if an expression in a TAGBODY is not a symbol,
an integer, or a cons. Implementations are forbidden from
extending this syntax.
It is an error to do a GO to a tag name for which the same
(i.e., EQL) tag appears more than once in the body of the
innermost TAGBODY containing that tag.
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Rationale:
The proposed set of tags is expressionally adequate.
Other obvious candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Duplicated tags are permitted in situations where no GO is done
to them primarily for two reasons:
- To permit NIL to occur more than once in common situations
such as:
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
- To permit the use of symbols as `dividers' between major
sections of code. eg,
(do (...)
(...)
-----
(...)
(...)
-----
(...))
It is not our intent particularly to encourage either of these
practices. Both are easy to work around. But current practice is
to permit such uses in many implementations, and there was no driving
reason to force such code to break.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
The TI Explorer permits using NIL as a GO tag, but as a special case,
does not warn about multiple appearances of NIL.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), there may be simple editing necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
Pitman supports this proposal.
----- End Forwarded Messages -----
∂07-Oct-88 2343 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:43:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:41:38 PDT
Date: 7 Oct 88 23:41 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: VARIABLE-LIST-ASYMMETRY (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881007-234138-1843@Xerox>
The only comment on this issue is that it should include
COMPILER-LET.
!
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: ADDITION
Edit history: Revision 1 by Skona Brittain 07/26/88
Revision 2 by Skona Brittain 08/04/88
Problem Description:
The syntax of items in the variable-list for various control structues
(do, let, prog and their duals) varies. This variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
I.e. change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
Rationale:
The asymmetry is unnecessary and impedes learning of CL.
Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*,
would be an incompatible change to the language.
This way just adds the flexibility found in some of the forms to all of them.
Current Practice:
KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.
Cost to Implementors:
Extremely slight. (May involve subtracting code rather than adding it).
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than asymmetry, at least to some of us.
Discussion:
Kent supports this proposal.
The issue about whether the atomic ``var'' should be allowed at all in the
variable lists for let & let* is a separate issue. (So is whether
it should mean that the var is initially bound to nil.) Since it is allowed,
this proposal merely says that the alternative syntax of an atom within a
list with no initial value, ``(var)'', should also be allowed.
∂08-Oct-88 1150 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 11:49:54 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Sat, 8 Oct 88 14:47:13 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Sat, 8 Oct 88 14:46:39 EDT
Date: Sat, 8 Oct 88 14:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881007-211606-1727@Xerox>
Message-Id: <19881008184726.3.BARMAR@OCCAM.THINK.COM>
Date: 7 Oct 88 21:16 PDT
From: masinter.pa@xerox.com
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Except for LOCALLY, I don't see the point of specifying the return
values of the above functions. Yes, the cost to implementors is small,
but why bother in the first place? I think they should be made
explicitly implementation defined, like the other functions that were
listed.
If others do prefer to specify explicit return values, I agree with the
particular choices (although for SET-SYNTAX-FROM-CHAR I don't see why it
shouldn't return one of the characters).
barmar
∂08-Oct-88 1229 X3J13-mailer REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 12:28:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:17:28 PDT
Date: 8 Oct 88 12:17 PDT
From: masinter.pa@Xerox.COM
Subject: REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu
To: Barry Margolin <barmar@Think.COM>
cc: x3j13@sail.stanford.edu
Message-ID: <881008-121728-2116@Xerox>
Barry:
I carefully typed the REPLY-TO: CL-CLEANUP@Sail.Stanford.Edu in all of the
mail to X3J13 with the idea that, if there was discussion on any of these
issues, we should handle them within cleanup. For many of the issues, there
has been a significant amount of prior discussion. We've tried for most of
the issues to at least summarize the discussion, but perhaps we've been
amiss, or have missed some points. You're welcome to participate directly
in the cleanup committee, of course.
I promise all of you that if you send comments on issues to cl-cleanup that
they will not be ignored, and that I think it is important that you are
satisfied that your concerns have at least been aired before a proposal is
voted on in the full X3J13 meeting.
Thanks,
Larry
∂08-Oct-88 1253 X3J13-mailer DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 12:53:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:48:03 PDT
Date: 8 Oct 88 12:48 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: CLOSED-STREAM-OPERATIONS (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-124803-2142@Xerox>
This issue is in discussion in the cleanup committee. The proposal is not ready for voting at X3J13. This is to inform you about the current state of discussion.
!
Status: DRAFT
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
Related Issues: STREAM-CAPABILITIES, STREAM-ACCESS, STREAM-INFO
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
"The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ..."
but the list of inquiry operations is not specified.
At least one implementation interpreted the list to include
at least OUTPUT-STREAM-P, while another has disallowed that operation
to be performed on a closed stream.
Proposal (CLOSED-STREAM-FUNCTIONS:DISALLOW-ALL)
Clarify that it is an error to perform any operation on a closed stream.
Rationale:
This clarification allows existing implementations to maintain the status
quo, while alerting users to the fact that the result of performing
an operation on a closed stream is undefined in the standard.
Also, the descriptions of OUTPUT-STREAM-P and INPUT-STREAM-P indicate
that these functions can only be performed on streams that have not
been closed.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Adoption Cost:
None.
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Closing streams is necessary for deallocation of system resources that might have been associated with their opening. Implementations and stream-types differ as to how much of the "stream information" that Lisp normally expects to be able to obtain is in the host operating system (and thus deallocated when the stream is closed) and how much is in Lisp, and presumably managed by the normal Lisp storage manager.
Closing a file stream also has the effect of allowing the file to be accessed for other operations in operating systems that implement file interlocking.
Of STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, TRUENAME, PATHNAME, which are legitimate on closed streams?
all?
What are the effects of CLOSE on composite streams (such as broadcast, two-way, and concatinated streams?)
close constituents?
What are the effects of CLOSE on a constructed stream (e.g., WITH-OUTPUT-TO-STRING)?
no effect?
∂08-Oct-88 1320 X3J13-mailer DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:19:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 13:09:12 PDT
Date: 8 Oct 88 13:09 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: COERCE-INCOMPLETE (Version 1)+
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-130912-2162@Xerox>
This issue is still under debate and the writeup below is very rough. We think that TYPE-OF-UDERSPECIFIED might help make the issue clearer.
We do not expect to discuss this issue in the full X3J13 session. This is just for your information that we're discussing the topic.
!
Status: DRAFT
Issue: COERCE-INCOMPLETE
Reference: coerce (CLtL p50)
Category: change
Edit history: version 1 by M.Ida, 26-Feb-1988
Problem Description:
--------------------
Problem 1:
Coerce is not symmetric or not generic among data types.
In CLtL, Coerce is defined in page 50 and 51 that,
1) a sequence type may be converted to any other sequence type.
2)Some strings, symbols, and integers may be converted to characters.
2-1) If object is a string of length 1,
then the sole element of the string is returned.
2-2) If object is a symbol whose print name is of length 1,
then the sole element of the print name is returned.
2-3) If object is an integer n,
then (int-char n) is returned.
3) any non-complex number can be converted to a XXX-float.
4) any number can be converted to a complex number.
The next table shows that how coerce is not symmetric among character,
string, symbol and integer.
TABLE 1. Possible Conversions among character, string,symbol, integer
type of conversion provided functions coercion under the CLtL
character -> string string X
character <- string coerce (if the string has only one char.) O
character -> symbol (intern (string @i[ch])) X
character <- symbol coerce (if pname length is 1) O
character -> integer char-code, char-int X
character <- integer code-char (zero font-, zero bits- attrib.) O
int-char (any font- and any bits-)
string -> symbol intern, make-symbol X
string <- symbol string, symbol-name X
string -> integer (char-code (coerce @i[string] 'character)) X
string <- integer (string (code-char @i[integer])) X
symbol -> integer (char-code (coerce @i[symbol] 'character)) X
symbol <- integer (intern (string (code-char @i[integer]))) X
Problem 2:
The function of coerce for character is defined to act as char-int/int-char
not as char-code/code-char.
Proposal: Coerce :replace
-------------------------
COERCE should be more generalized for string, symbol, integer, and character
data types. The observations show there are
no problem if extensions are fully written out in the details.
Here is an extension to the current coerce definition using the CLOS.
(defmethod coerce ((x character) (y (eql string))) (string x))
(defmethod coerce ((x character) (y (eql symbol))) (intern (string x)))
(defmethod coerce ((x character) (y (eql integer))) (char-code x))
(defmethod coerce ((x string) (y (eql symbol))) (intern x))
(defmethod coerce ((x symbol) (y (eql string))) (string x))
(defmethod coerce ((x string) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql string))) (string (code-char x)))
(defmethod coerce ((x symbol) (y (eql integer)))
(char-code (coerce x 'character)))
(defmethod coerce ((x integer) (y (eql symbol)))
(intern (sting (code-char x))))
(defmethod coerce ((x integer) (y (eql character)))
(code-char x)) ; redefinition. CLtL defines as int-char
The keys are
a) ignore char-bits and char-font upon the conversion of characters,
assuming font-attribute will be flushed from the language spec.
b) ignore the package name upon the conversion of symbols.
(package name has no role upon the conversion.)
c) the created symbol will be interned to the current package.
Rationale:
----------
By extending the definition as this document suggests, the functionality
of coerce is symmetric among characters, strings, symbols and integers.
Current Practice:
Cost to implementors:
Cost to users:
Benefits:
Aesthetics:
Discussion:
<<discussion from original Common Lisp design.>>
Making COERCE symmetric would probably be a bad idea, e.g., that it can coerce
from INTEGER to FLOAT and not from FLOAT to INTEGER is on purpose.
We think COERCE from integer to character is odd and non-portable and think it
perhaps should be removed from the standard.
COERCE from character to STRING is a good idea.
We are now puzzled by the inconsistency of (COERCE x 'STRING) vs (STRING x) and
want to reduce it.
We would like (COERCE x 'PATHNAME) to work like (PATHNAME x).
The reason that (COERCE symbol 'STRING) is difficult is that (COERCE 'NIL
'STRING) as a symbol could return "NIL", but (COERCE '() 'STRING) as the empty
list could return "".
FUNCTION-TYPE has extended COERCE to work for 'FUNCTION.
(COERCE "5" 'INTEGER)
should return integer.
!
Issue: COERCE-FROM-TYPE
References: COERCE (p51)
Related-Issues: COERCE-INCOMPLETE
Category: ADDITION
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, should (COERCE NIL 'STRING) return "" or "NIL".
The choice would be arbitrary unless you knew whether NIL was being
viewed as an empty list or a symbol.
Similarly, (COERCE (CHAR-CODE #\A) 'STRING) might return the same
as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in most ASCII-based
implementations -- or it might return "A", depending on whether the
result of char-code was viewed as a number or more specifically as
a character code.
Proposal (COERCE-FROM-TYPE:NEW-ARGUMENT):
Add an extra optional argument to COERCE which specifies the type
from which the coercion is to be done. The new syntax would be:
COERCE object to &optional (from (TYPE-OF object))
Constrain that FROM must be such that (TYPEP OBJECT FROM) is true.
Rationale:
This leaves room for a subsequent proposal to extend COERCE in
interesting ways. For example, extensions such as the following
might be considered:
(COERCE NIL 'STRING 'LIST) => ""
(COERCE NIL 'STRING 'SYMBOL) => "NIL"
A new type CHAR-CODE might even be introduced as
(DEFTYPE CHAR-CODE () `(INTEGER 0 (,CHAR-BITS-LIMIT)))
so that COERCE could handle cases like:
(EQUAL (COERCE (CHAR-CODE #\A) 'STRING 'NUMBER)
(FORMAT NIL "~D" (CHAR-CODE #\A))) => T
(COERCE (CHAR-CODE #\A) 'STRING 'CHAR-CODE) => "A"
Such specific proposals are deliberately not part of this proposal
in order to separate the general purpose mechanism from the more
specific details.
Current Practice:
Probably no one implements the proposed behavior at this time.
Cost to Implementors:
The more optimization a compiler does (or might do) of COERCE, the more
work might be necessary. In general, however, the changes would probably
not involve a major amount of work.
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
Various proposals to extend COERCE would probably not pass because
not everyone can agree on how to view the type of the first argument.
!
M.Ida responds
My primary points are on the relation to CLOS and the simplicity which
might be obtained as a result of the integration.
I further thought that coerce can be viewed as a generic function
(I know recent talk of the mailing list for this).
So I thought it is possible to define for the ambiguous cases
consulting type hierarchy related things in CLOS.
For the above example, since CLOS defines the class precedence list for NULL
as (null symbol list sequence t),
(coerce nil 'string) should be "NIL" first if there are no special methods.
I had thought that COERCE should grow up into a kind of universal function.
But I realized that the current role of COERCE seems to be a very low level primitive.
Possibilities:
extend coerce to handle more types?
Add an extra argument?
Make COERCE generic?
Make COERCE take classes as well as type names?
∂08-Oct-88 1329 X3J13-mailer DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 13:29:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 13:25:27 PDT
Date: 8 Oct 88 13:25 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
To: x3J13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-132527-2172@Xerox>
There have been last-minute edits to the wording (but not the intent) of this issue/proposal that cause me to write DRAFT in the issue status.
!
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers ARRAY, COMPLEX, SIMPLE-ARRAY, and VECTOR
Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes)
Version 8, 8-Oct-88, Masinter (wording, discussion)
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination". Many people are confused by
this situation. A consequence of this distinction is that a variable
declared to be of type <certain-type> and all of whose assigned objects
are created in accordance with that type, may still have none of its
values ever satisfy the TYPEP predicate with that type-specifier.
One type-specifier with this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Summary of changes:
Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". Change the meaning of the <element-type> in the
ARRAY type-specifier and its subtypes, and in the COMPLEX type-specifier,
to be the same for TYPEP and SUBTYPEP as for TYPE declarations.
Specify how SUBTYPEP behaves on these type-specifiers. Add a function
to provide access to the implementation-dependent set of array types
and another function to provide access to the implementation-dependent
set of complex number types.
Specifics:
1. Eliminate references to the distinction between types "for declaration"
and "for discrimination" in the discussion of array and complex
type-specifiers. This would include documentation patterned after CLtL:
a.) The discussion in section 4.5, pp. 45-7
b.) p. 291, the sentence begining "This set may be larger than the set
requested when the array was created; for example . . ."
Instead, (ARRAY <type>) always means all arrays that can result by specifying
<type> as the :ELEMENT-TYPE argument to the function MAKE-ARRAY, and
(COMPLEX <type>) always means all complex numbers that can result by
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation.
2. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if and
only if <x> is an array of the most specialized representation capable
of holding elements of type <type>. In other words, it is true if and
only if <x> is an array and (ARRAY-ELEMENT-TYPE <x>) is type-equivalent
to (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE <type>)).
Do the same for SIMPLE-ARRAY and VECTOR.
3. Change the meaning of (TYPEP <x> '(COMPLEX <type>)) to be true if
and only if <x> is a complex number of the most specialized
representation capable of holding parts of type <type>, or if <x> is of
any subtype of that representation. Both the real and imaginary parts
must satisy (TYPEP <real-or-imag-part> '<type>).
4. Define that for all type-specifiers <type1> and <type2>, other than *,
(ARRAY <type1>) and (ARRAY <type2>) are either equivalent or disjoint,
depending on whether they use the same specialized representation or
distinct representations. This defines the behavior of SUBTYPEP.
5. Define that for all type-specifiers <type1> and <type2>, other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>)) is T T if they use the
same specialized representation, T T if they use distinct specialized
representations but (SUBTYPEP '<type1> '<type2>) is true, and NIL T
otherwise.
6. Require that the resultant ARRAY-ELEMENT-TYPE from a call to
MAKE-ARRAY is independent of any argument to MAKE-ARRAY except for the
:ELEMENT-TYPE argument. Thus the set of specialized array
representations must be consistent between single-dimensional and
multi-dimensional, simple and non-simple, short and long arrays.
7. Add the function IMPLEMENTED-ARRAY-ELEMENT-TYPE of one argument
which returns the same result as:
(DEFUN IMPLEMENTED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
The type specifiers (ARRAY <type1>) and (ARRAY <type2>), where neither
<type1> nor <type2> is *, are equivalent if <type1> and <type2> produce
the same value from IMPLEMENTED-ARRAY-ELEMENT-TYPE, and disjoint
otherwise.
8. Add the function IMPLEMENTED-COMPLEX-PART-TYPE of one argument
which returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
Test cases:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
The small differences between the specification for ARRAY and the
specification for COMPLEX are necessary because there is no creation
function for complexes which allows one to specify the resultant type
independently of the types of the parts. Thus in the case of COMPLEX
we must refer to the type of the two parts, and to the fact that a
number can be a member of more than one type. Note that:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
is true in all implementations, but
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is only true in implementations that do not have a specialized array
representation that can hold single-floats but not other floats.
Current Practice:
Every vendor's implementation that the proposer has queried has a
finite set of specialized array representations, such that two
non-equivalent element types can be found that use the same specialized
array representation; this includes Lucid, Vaxlisp, Symbolics, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other implementations fail it.
No vendor that the proposer has queried has any specialized representation
for complexes.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of TYPEP and SUBTYPEP.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about MAKE-ARRAY
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type
(ARRAY <type>) has been very confusing to almost everyone.
Portability of applications will be increased slightly, since
the behavior of
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
will no longer be implementation-dependent.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
This issue was prompted by a lengthy discussion on the Common Lisp
mailing list. It was the subject of a lengthy discussion in the
cleanup committee, as well as a number of individual efforts.
We considered the possibility of requiring that arrays remember
the element-type given in the make-array call, e.g., require that
(equal <x> (array-element-type (make-array <n> :element-type <x>)))
for all valid type specifiers <x>. This has several problems: it
increases the storage requirement for arrays, and 'hides' a
relevant part of the underlying implementation for no apparently
good reason. In addition, there might be some problems with
equivalent but separate types (although this might be handled
by changing "equal" to "equal-type", given a more rigorous
definition of SUBTYPEP; see issue SUBTYPEP-TOO-VAGUE.)
However, it would increase portability, since it would be much
more difficult to write a program that, for example, created
an array with one element-type and then assumed an upgraded
element-type. It would be valid for an implementation to do so
-- to remember the original array element-type or its canonical
or expanded form -- and satisfy all of the constraints of this
proposal.
We considered a suggestion to restrict the set of "known" array
element types; this would gain portability at the expense of limiting
the language.
----- End Forwarded Messages -----
∂08-Oct-88 1441 X3J13-mailer DRAFT Issue: DEFPACKAGE (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 14:41:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 14:39:27 PDT
Date: 8 Oct 88 14:39 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DEFPACKAGE (version 6)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-143927-2237@Xerox>
This issue is only marked DRAFT because there were some last minute edits
to it.
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Version 5, 6-Oct-88, Moon
Version 6, 8-Oct-88, JonL (little nits)
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and frustrating to programmers.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a symbol,
only its name matters, not what package it is in.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below. Options may appear
more than once (useful mainly for :IMPORT-FROM and :SHADOWING-IMPORT-FROM).
It is an error to specify :SIZE more than once.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
The package is to "use" the other designated packages; that is,
it will inherit from them.
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined,
making them shadows, just at the function SHADOW would do.
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined, and place them on the
shadowing symbols list. In no case will
symbols be created in any package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined. In no case will
symbols be created in a package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:INTERNAL {symbol-name}*)
Find or create symbols with the specified names. This is useful
if a :IMPORT-FROM or :SHADOWING-IMPORT-FROM option in a later
DEFPACKAGE for another package expects to find these symbols,
but the symbols are not to be exported.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since intern'ing may inherit
symbols rather than creating new ones; note also an interaction
with the :INTERNAL, :IMPORT-FROM and :SHADOWING-IMPORT-FROM options,
since intern'ing will merely access an already imported symbol.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package.)
Additional options might be allowed by an implementation; all
implementations should signal an error if an option not recognized by
that implementation is present.
The collection of symbol-name arguments given to the options :SHADOW,
:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
disjoint; an error is signalled otherwise. The :EXPORT option can
be thought of as occuring after all the other options have been
executed, since it may reference names found in "used" packages,
or found in the argument lists to a :SHADOW, :INTERNAL, :IMPORT-FROM,
or :SHADOWING-IMPORT-FROM option.
DEFPACKAGE creates the package as specified, and returns it as its value.
It has no other side effects; i.e., it does not do an IN-PACKAGE.
If a package with the specified name already exists, the existing package
is modified by possibly adding to its attributes. An attempt to re-define
a package with a smaller set of attributes should signal a continuable error;
at most one such error is to be signalled per call to DEFPACKAGE, regardless
of how many attributes are being re-tracted; upon continuation, the package
is created with exactly as specified.
Examples:
;;; An example which "plays it super-safe", by using only strings as names;
;;; does not even assume that the package it is read in to "uses" LISP;
;; *never* creates any symbols whatsoever in the package that it is read
;; in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP, and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(defpackage my-package
(:nicknames mypkg :MY-PKG) ;remember CL conventions for case
(:use lisp) ; conversion on symbols
(:shadow CAR :cdr #:cons)
(:export "CONS") ;yes, this is the shadowed one.
)
Rationale:
The availability of DEFPACKAGE encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp has always had a DEFPACKAGE, and uses it in
preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time. This
proposal is incompatible with Symbolics DEFPACKAGE in some ways that
will probably not cause major problems.
Cost to Implementors:
Small; DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" mnemonic
described in CLtL p.191 could be removed, and the special compiler
handling of these functions necessary to support that could be removed
(except possibly for REQUIRE and PROCLAIM -- see the compiler Issue
PROCLAIM-ETC-IN-COMPILE-FILE). As this would be an incompatible change,
it is not part of this proposal.
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.
The macroexpansion of DEFPACKAGE can usefully canonicalize
into the strings-as-name form, so that even though the source file
showed random symbols in the DEFPACKAGE form, the compiled file might
have only strings in it.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Note that we now have three continuable errors being specified, but have
not specified the condition names. This ought to be remedied.
∂08-Oct-88 1547 X3J13-mailer DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 15:47:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 15:44:14 PDT
Date: 8 Oct 88 15:44 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DEFSTRUCT-REDEFINITION (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-154414-2285@Xerox>
This issue is a draft; we need to sort out the nature of
what happens if you redefine a DEFSTRUCT with accessors
that were previously compiled, old instances, etc.
Presumably there is no groundswell for eliminating DEFSTRUCT
in favor of DEFCLASS.
!
Issue: DEFSTRUCT-REDEFINITION
References:
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 07/26/88
Problem Description:
The case of a structure type being redefined is not discussed in CLtL.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-ITSELF):
It is an error to redefine a structure.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-IFF-OLD-USE):
Redefining a structure is ok but it is an error to access, in any way,
an instance of the structure that was created prior to the redefinition.
This applies to instances of other structures that :INCLUDEd the
redefined structure.
It is also an error to use any of the redefined structures accessors
on any instances of a structure that :INCLUDEd the previous definition.
Test Cases:
(I)
(defstruct struc1
slot1 slot2)
(setq s (make-struc1 :slot1 1 :slot2 2))
(defstruct struc1 ; this is an error according to ERROR-BY-ITSELF
slot2 slot1) ; but not according to ERROR-IFF-USE
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
(II)
(defstruct struc1
slot1 slot2)
(defstruct (struc2 (:include struc1))
slot 3)
(defstruct struc1
slot2 slot1)
(setq s (make-struc2 :slot1 1 :slot2 2))
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
Rationale:
The issue of redefinition should be addressed since there are always
consequences that affect use of the structures: at the very least,
the constructor function gets overwritten when a structure is redefined.
ERROR-BY-ITSELF is simpler, but ERROR-IFF-USED is more amenable to use.
Current Practice:
None of KCL, Lucid, & Symbolics detect a redefinition, but all of them
return 2 as the value of the last forms in each of the above test case sets.
Cost to Implementors:
ERROR-ITSELF: none if not signaled. extremely slight if signaled.
ERROR-IFF-OLD-USE: none if not signaled. much more if signaled.
Cost to Users:
ERROR-ITSELF: It can be quite inconvenient to be prevented from "correcting"
a structure definition, which would presumably happen if the error were
signaled.
ERROR-IFF-OLD-USE: None.
Cost of Non-Adoption:
Confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Larry supports ERROR-BY-ITSELF, "in that slot-accessors for structures are
presumed to be declared "inline". If users want more flexibility than that,
they should use defclass."
Various inbetween proposals are possible, such as only incompatible
redefinitions cause errors, but they're too hard to define.
My feeling is that it's a cop-out to just say it's an error to redefine
a structure but then never signal the error - users will still be confused
by the differing seemingly erratic behavior and code.
-- - - Additional Comments - - -
"Portable programs should not dynamically redefine structures.
Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they are not
portable.
I don't think it is a cop-out. I certainly don't want an error to be signalled.
I'm lacking a good terminology for describing the "is an error" situation that I
think this should be."
"Why not "is non-portable"?"
"We might want to at least reference the redefintion protocol of CLOS"
∂08-Oct-88 1605 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:05:44 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:01:29 PDT
Date: 8 Oct 88 16:01 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: DESCRIBE-INTERACTIVE (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-160129-2301@Xerox>
It seems unlikely that the cleanup committee actually has
more to say on this issue.
!
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION/CHANGE
Edit history: 12-Sep-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
Problem Description:
CLtL is not clear about whether DESCRIBE may be interactive.
While CLtL describes INSPECT as an interactive as an
interactive version of DESCRIBE, it doesn't make explicit
that DESCRIBE is non-interactive. In some implementations it is,
and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Specify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This validates current implementations.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
This proposal is the minimal proposal for compatibility with current
behavior.
It might be possible to extend DESCRIBE to have additional
keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover
additional behavior.
Some members of the cleanup committee think that this is really
a change from the intent of CLtL. However, the current sentiment
is to be less rather than more specific about the behavior of debugging
tools (25.3 of CLtL).
∂08-Oct-88 1651 X3J13-mailer DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:41 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:15:32 PDT
Date: 8 Oct 88 16:15 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: DOTTED-MACRO-FORMS (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-161532-2307@Xerox>
The cleanup committee (and individual members of the committee)
have mixed opinions about this issue.
!
Issue: DOTTED-MACRO-FORMS
References: forms (p54), lists and dotted lists (pp26-27),
DEFMACRO (p145), destructuring macro arguments (p146)
Category: CLARIFICATION
Edit history: 28-Jun-88, Version 1 by Pitman
1-Oct-88, Version 2 by Masinter
Problem Description:
CLtL is not explicit about whether macro forms may be dotted lists.
p54 says that only certain forms are "meaningful": self-evaluating
forms, symbols, and "lists".
pp26-27 defines "list" and "dotted list". It goes on to say
``Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.''
p146 states that in DEFMACRO destructuring, ``the argument
form that would match the parameter is treated as a
(possibly dotted) list, to be used as an argument forms list
for satisfying the parameters in the embedded lambda list.''
It goes on to say that ". var" is treated like "&rest var"
at any level of the defmacro lambda-list.
Proposal (DOTTED-MACRO-FORMS:DISALLOW):
Specify that it is an error for a macro form to be a dotted list.
Rationale:
Dotted lists are a possible symptom of program syntax error.
Allowing implementations to check for this error may catch enough
errors to justify the loss of program flexibility.
Test Case:
#1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
(MACW . 1) => ??
#2: (DEFMACRO MACR (&REST R) `(- ,R))
(MACR . 1) => ??
#3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
(MACX . 1)
(MACW . 1) would be an error under this proposal.
(MACR . 1) would be an error under this proposal.
Current Practice:
A. Some implementations bind W to (MACW . 1) in #1 and #3
and bind R to 1 in #1 and #2.
B. Some implementations bind W to (MACW . 1) in #3
and signal a syntax error in #1 and #2.
C. Some implementations signal a syntax error in #1, #2, and #3.
Symbolics Genera is such an implementation.
Cost to Implementors:
As written, this proposal doesn't require implementations to check for
the error condition.
Cost to Users:
Some users depend on this behavior in current implementations, although
such use is not widespread.
Benefits:
People would know what to expect.
Aesthetics:
Mixed opinion; certainly it is better to specify whether they are allowed
or an error than to be vague. Some feel that disallowing dotted macro
forms makes the language cleaner.
Discussion:
Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
This issue came up primarily in the context of program-written programs;
a macro used in the program generated code might occasionally use
a dotted tail to a list to explicitly represent special conditions.
Allowing dotted macro forms may blur the data/code distinction too much,
particularly for people who are new to Lisp.
Some people believe that there's no reason to unnecessarily restrict
&WHOLE and/or &REST since there is no computational overhead and since
the interpretation, if there is one at all, is pretty well agreed upon.
- - - - - - - - Additional Discussion - - - - - -
Allow them only with a declaration?
This is an issue of error-checking vs flexibility, we think.
There is a consistency argument: dotted arguments are definitely
disallowed in function argument lists, and almost certainly allowed
in embedded macro arguments; which should the top-level macro
argument lists be consistent with?
∂08-Oct-88 1651 X3J13-mailer Issue: EQUAL-STRUCTURE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:33:06 PDT
Date: 8 Oct 88 16:33 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-163306-2318@Xerox>
Our intent is to leave EQUAL and EQUALP alone. We are just having
difficulty saying what it does now.
We thought this deserved an "issue" even though it is status quo
because the issue arises frequently, and it was circulated for the
June 1988 X3J13 in a different form.
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
EQUAL uses EQL for numbers and characters, descends structure for CONSes
bit-vectors, strings; has special behavior for pathnames as specified
in CLtL, and uses EQ for all other types.
EQUALP is similar, except that it ignores case in strings, and it
descends arrays, structures, and instances. It uses EQ for
all other types; for example, it does not descend hash tables.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
∂08-Oct-88 1651 X3J13-mailer Issue: EXIT-EXTENT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 16:50:55 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:45:27 PDT
Date: 8 Oct 88 16:45 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-164527-2328@Xerox>
I think it is unlikely that the cleanup committee will
have much more to say on the issue.
!
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Cleanup issue UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control. (According to CLtL p.125, there is no possibility of a
normal exit from DO.)
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL.
Test Cases/Examples:
Each of the following programs is an error:
(funcall (block nil #'(lambda () (return)))) ;case 1
(block nil ;case 2
(unwind-protect (return)
(return)))
(block a ;case 3
(block b
(unwind-protect (return-from a)
(return-from b))))
(let ((a nil)) ;case 1
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
(funcall (block nil ;case 3
(tagbody a (return #'(lambda () (go a))))))
(catch nil ;case 2
(unwind-protect (throw nil t)
(throw nil t)))
(catch 'a ;case 3
(catch 'b
(unwind-protect (throw 'a t)
(throw 'b t))))
The above program is an error because the catch of b is passed over by
the first throw, hence portable programs must assume its dynamic extent
is terminated. The catch is not yet disestablished and therefore it
is the target of the second throw.
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
Rationale:
Giving exits the smallest extent consistent with CLtL maximizes freedom
for implementations; there are few applications, if any, that require a
longer extent.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Cost to Implementors:
No currently valid implementation will be made invalid by this proposal.
Some implementors may wish to add error checks if they do not already
have them.
Cost to Users:
Since this is a clarification and current implementations differ, this
issue ostensibly does not affect current portable programs.
Cost of non-adoption:
The semantics of exits will remain ambiguous.
Benefits:
Common Lisp will be more precisely defined, and the precise definition
will be consistent with current practice in a way that has no cost for
implementors nor for users.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
One aspect of this issue, namely the particular behavior of non-local
exits from unwind protect cleanup clauses, was discussed at great
length. Some of that discussion centered around the possibility of
creating "unstoppable loops" that could not be exited, by constructs
like
(tagbody retry (unwind-protect .... (go retry)))
The goal of this proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. An alternative proposal
would define the extent of an exit to end at the last moment possible
within some particular reference implementation. That alternative would
have a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal would duck the
issue by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms.
That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal.
∂08-Oct-88 1703 X3J13-mailer DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:02:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 16:58:10 PDT
Date: 8 Oct 88 16:58 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FORMAT-PRETTY-PRINT (version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-165810-2344@Xerox>
The only comment on this issue is on the binding of *PRINT-BASE*
under ~E, ~R, e.g. (LET ((*PRINT-BASE* 8)) (FORMAT NIL "~R" 8))
or (LET ((*PRINT-BASE* 8)) (FORMAT NIL "~E" 8.5))
!
Status: DRAFT
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Version 5 by Masinter 2-Oct-88
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
*PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
argument.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
<<the test is not accurate in systems where prettyprinting
might indent differently when *print-escape* is NIL.>>
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT- variables. There may be other similar interactions in
Common Lisp that need clarification.
Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.
CLtL might change as follows:
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:26:34 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:20:36 PDT
Date: 8 Oct 88 17:20 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-COMPOSITION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-172036-2376@Xerox>
The comments on this issue so far deal with the possibility
of removing :TEST-NOT, and some minor problems with the
definition of COMPOSE. (E.g., (COMPOSE) might return
#'VALUES.)
However, comment on the main issue, whether this is important
enough to add to the language, is welcome.
!
Status: DRAFT
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases, and more importantly will permit
a programming style which is currently discouraged by most
Common Lisp implementations.
It is technically possible to define this functionality portably,
the really important part of this proposal is that native compiler
support is needed to really do them justice. Portable implementations
are not likely to be efficient enough for serious use.
Placing these functions in the core language not only permits
but encourages a very useful set of compiler optimizations that
would otherwise be difficult to obtain.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added. [See issue TEST-NOT-IF-NOT.]
Current Practice:
No Common Lisp implementations provide these primitives, but they do
exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
Pitman and van Roggen support the proposal.
Jim McDonald (JLM@Lucid.COM) seemed supportive of this proposal
and even suggested adding more elaborate operators such as
PERMUTE and COMMUTE. eg, (COMMUTE #'CONS) would be like what
Maclisp called XCONS.
Masinter wavered on this issue, but currently seems to support it.
Fahlman thinks this slightly gratuitous but is not opposed to
it if others think it is a good idea.
∂08-Oct-88 1726 X3J13-mailer DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:26:25 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:10:18 PDT
Date: 8 Oct 88 17:10 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-COERCE-TIME (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-171018-2362@Xerox>
This proposal has not yet been resolved in the cleanup committee.
There are a variety of options being considered, as you can tell.
!
Status: DRAFT
Issue: FUNCTION-COERCE-TIME
References: SET-MACRO-CHARACTER (p362),
SET-DISPATCH-MACRO-CHARACTER (p364),
MAP (p249), MAPL (p129), ...
Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
Functions using a positional predicate (SORT, DELETE-IF, ...)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
(changes to presentation of all proposals per Masinter's comments)
Status: For Internal Discussion
Problem Description:
Many functions which accept arguments which are to be treated functionally
but which are not of type FUNCTION. This functionality can be very useful,
but the time at which the coercion is accomplished must be made clear.
Proposal (FUNCTION-COERCE-TIME:LAZY):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is delayed until the function is about to be called and is done anew
every time the function is to be called. That is, passing a non-function
functional argument, F, is equivalent to passing
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
Rationale:
One of the main reasons that it may be useful to pass a non-function
instead of a function is to accomplish indirection which allows later
redefinitions to take proper effect. Early binding would tend to
thwart the usefulness of such indirection and force people into
notationally more clumsy devices.
Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is done immediately. That is, all such functions treat a non-function
functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead.
Rationale:
This is easier to implement since the coercion is done up front and
no further worry about uncoerced functions is needed internally.
Also, inlining of mapped functions (without using temporary storage
to hold a cached value of the function being mapped) can be done
without needing to know whether the function being inlined will
affect the place which holds the functional argument being passed.
Proposal (FUNCTION-COERCE-TIME:HYBRID):
Specify that when a non-function (eg, a symbol) is used as a
functional argument to an operator, the coercion of that non-function
to a function must be done immediately if the functional argument is
to be used only internally to the function (eg, SORT or MAPCAR).
Otherwise, if the functional argument's use persists beyond the end
of the call to the operator (eg, SET-MACRO-CHARACTER), any coercion is
delayed until the function is about to be called and is done anew every
time the function is to be called.
That is, functions like SORT and MAPCAR are permitted to treat a
non-function functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead. However, functions like SET-MACRO-CHARACTER
would treat a non-function functional argument, F, as if
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
were passed instead.
Rationale:
Debugging is enhanced for operations such as SET-MACRO-CHARACTER
without needlessly hampering useful optimizations to things like
SORT or MAPCAR, which very rarely require this facility.
Test Cases:
(DEFVAR *SOME-FUNCTIONS*
(LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))
; Control situation A
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4)
; Control situation B
(LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
(LIST (MAPCAR FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 1 1) 4)
; Interesting Situation 1
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-1
or ((1 1 1 1) 4) ;Ambitious-1
; Interesting Situation 2
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR 'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-2
or ((1 1 1 1) 4) ;Ambitious-2
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(EXPT (READ STREAM) (OR N 1)))
(SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3 81)
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(+ (READ STREAM) (* (OR N 0) 0.01)))
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3.0 3.04) ;Lazy-3
(3 81) ;Ambitious-3
Proposal LAZY requires LAZY-1, LAZY-2, LAZY-3.
Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
Proposal HYBRID requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.
Current Practice:
Implementations are permitted to differ in when they do the coercion since
the coercion time is not clearly spelled out.
(In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
only if the original value of the function definition is not cached.)
[Some info below is based on empirical testing -- I didn't look at the
source or try to see how speed/safety affect things. -kmp]
Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
and compiled.
Both Symbolics Genera and Symbolics Cloe implement LAZY-2.
Symbolics Genera implements LAZY-3.
Symbolics Cloe implements AMBITIOUS-3.
Cost to Implementors:
[Costs may vary widely depending on current practice.
I'll leave this one open for now pending feedback from others. -kmp]
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
A very important aspect of the language would be left unspecified.
Portability would suffer.
Benefits:
HYBRID has the benefit of making things like readmacros easier to debug.
LAZY offers the additional benefit of being able to repair certain
functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
and then to proceed the error (in implementations offering that restart
option) in a way that makes the ongoing call to SORT or MAPCAR notice
the repairwork right away.
Aesthetics:
Since this is a visible aspect of the language, anything which clarified
the behavior that a programmer might expect would seem to improve the
aesthetics somewhat.
Discussion:
This issue was raised by Nick Gall and written up by Pitman.
Pitman supports FUNCTION-COERCE-TIME:HYBRID.
∂08-Oct-88 1741 X3J13-mailer DRAFTIssue: HASH-TABLE-ACCESS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:35:50 PDT
Date: 8 Oct 88 17:35 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFTIssue: HASH-TABLE-ACCESS (version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173550-2380@Xerox>
!
Status: DRAFT -- see comments at end
Issue: HASH-TABLE-ACCESS
References: hash-tables (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
Problem Description:
There are many characteristics of hash-tables which are specified upon
creation but are not accessible afterwards.
Proposal: (HASH-TABLE-ACCESS:PROVIDE)
Add the following functions to the language:
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
HASH-TABLE-TEST hash-table
Returns the test used for comparing keys in the hash table.
By default the value will be EQL.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
For example, it would allow programs to gain statistics about hash
table usage that might enable better tuning.
Discussion:
None of these are required to be SETF'able, though that might be
a reasonable implementation-dependent extension.
This first appeared in ">GLS>clarifications.text" of 12/06/85.
- - - - -
Is it reasonable for implementations to extend the set of SETF-able forms? It
would seem to lead to more subtle incompatibilities, because there would be no
simple lexical analysis that would determine the use of an extension vs the
standard. Further, I don't think that HASH-TABLE-SIZE HASH-TABLE-TEST, are
reasonably SETF-able. If you change the :TEST, would would you do about entries
that now collide?
It would make more sense to make HASH-TABLE-REHASH-SIZE
HASH-TABLE-REHASH-THRESHOLD
both SETFable if it is reasonable to expect to do so.
I wonder before we add more slots for built in data structures if
we wouldn't be doing better if we made access to these via CLOS? I won't push on
that too hard....
- - - - -
this issue is one of the very clear "Clarifications" that Guy
Steele issued on 6-Dec-1985, and which have not hitherto been turned
into format "Cleanup" proposals.
For the "Current Practice" section, you can mention that ever since the
2.0 release Lucid has provided all four accessors, as well as setf methods
for HASH-TABLE-REHASH-THRESHOLD and HASH-TABLE-REHASH-SIZE. [However,
they have not been in Lucid's documentation until the 3.0 release].
Could you be convinced to ask the for two setf "methods" too?
One other request: the return value of HASH-TABLE-TEST should
be among the values of 'EQ, 'EQL, or 'EQUAL -- not among #'EQ,
#'EQL, or #'EQUAL.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:30:01 PDT
Date: 8 Oct 88 17:30 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173001-2379@Xerox>
!
Status: DRAFT -- several issues raised not addressed here
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Edit history: #1, 7 Sept 1988, Walter van Roggen
#2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE). Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.
Thus unlike all the other type declarations, which can be used for
discrimination and have an implicit effect on representation, specialized
FUNCTION type specifiers appear to have superfluous information. By changing
the meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
For specialized FUNCTION type specifiers
(proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
(the val-type (f (the arg0-type ...) (the arg1-type ...) ...))
If the arguments to F are of the specified types, then the result will be of
the specified type. If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.
This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Cost to Implementors:
Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.
Cost to Users:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Cost of Non-Adoption:
There already exists user code on many implementations that assume the
proposed semantics. Not adopting this proposal would continue to render
such code incorrect or at least non-portable.
Benefits:
Better type checking and more compiler optimizations should be possible.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
Is it the case that this proposal makes no statement on the issue of
what happens if you do multiple proclamations for the same function?
I don't think you can completely ignore the issue because
(FUNCTION (FIXNUM FIXNUM) CONS)
is a proper global declaration for CONS if multiple declarations are
permitted, but not if only one declaration is permitted.
I think that much of the confusion about function type declarations is
because there are two aspects of the issue that have not been clearly
delimited:
1. Declarations describing the definition of a function.
2. Declarations about functions expected to be received by an argument
or variable.
The proposal FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE addresses
the first case, while the discussion in CLtL seems to have primarily the
second case in mind.
- - - - -
The function type constructor is anti-
monotonic in its first argument, unlike most other other type constructors
which are monotonic in all arguments. That is,
If X is a subtype of Y
then Z --> X is a subtype of Z --> Y
but Y --> Z is a subtype of X --> Z.
It would be good if Common Lisp's notion of "type" and "subtype" could
be made consistent with this fact.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:35 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:38:18 PDT
Date: 8 Oct 88 17:38 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-173818-2382@Xerox>
!
Issue: HASH-TABLE-PACKAGE-GENERATORS
References:
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Version 3, 7-Oct-88 JonL (mly's syntax for package iterator)
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the hash-table which is obtained
by evaluating <hash-table> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. the key item (of a <key, value> pair)
;; 3. the value item (of a <key, value> pair)
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package> [Macro]
&key external internal inherited)
&body body)
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the package which is obtained
by evaluating <package> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. a symbol (available in the indicated package)
;; 3. the availability type for that symbol; i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED, or unspecified for
;; the DO-ALL-SYMBOLS case.
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
The keyword arguments are flags indicating which kinds of symbols are
wanted; they are not "evaluated". The following combinations are
recognized:
+----------+----------+-------------+--------------------------------------
| external | internal | inherited | CLtL macro equivalent
+----------+----------+-------------+-------------------------------------
| T | T | T | DO-SYMBOLS
| T | T | NIL | DO-PRESENT-SYMBOLS [not CLtL]
| T | NIL | T | <none> [unspecified]
| T | NIL | NIL | DO-EXTERNAL-SYMBOLS
| NIL | T | T | <none> [unspecified]
| NIL | T | NIL | DO-INTERNAL-SYMBOLS [not CLtL]
| NIL | NIL | T | DO-INHERITED-SYMBOLS [not CLtL]
| NIL | NIL | NIL | DO-ALL-SYMBOLS
+----------+----------+-------------+--------------------------------------
In the default case, equivalent to DO-ALL-SYMBOLS, the value of the
<package> argument is ignored. The lines marked "[not CLtL]" mention
package iterator macros found in some implementations of Common Lisp;
their meaning should be self-explanatory. The lines marked "unspecified"
may be extended by an implementation to have the implied meaning.
In accord with common practice, the options that include "inherited"
symbols, and the DO-ALL-SYMBOLS option, are allowed to present the
same symbol multiple times. This is because a symbol may be "inherited"
from several different used packages; and a symbol may be present in
several different packages (in the DO-ALL-SYMBOLS case).
It is unspecified what happens if any of the implicit interior state
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).
Test-case:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-hash-table-iterator (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-package-iterator (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package
:internal t :external t :inherited t)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol accessibility) (generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
The following functions prints out every interned symbol:
(defun print-all-symbols ()
(with-package-iterator (next-symbol nil)
(print (next-symbol))))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh. Something like this is already being
done by the standard package macros [CLtL, p187].
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed
to do so by this proposal.
∂08-Oct-88 1751 X3J13-mailer DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:51:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 17:44:14 PDT
Date: 8 Oct 88 17:43 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: HASH-TABLE-PRINTED-PREPRESENTATION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-174414-2396@Xerox>
The issues listed under Additional Comments still have not been resolved.
!
Status: DRAFT (see Additional Comments)
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number of
such pairs, including zero. Order is not significant. It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale:
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
Benefits:
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to files.
Current practice:
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.
- - - - Additional Comments - - - - -
you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables.
One problem with the currently proposed #H notation is that it provides
no way to specify a rehash-size or rehash-threshold. This should not be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional arrays.
∂08-Oct-88 1741 X3J13-mailer DRAFT Issue: FUNCTION-DEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 17:41:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 17:25:54 PDT
Date: 8 Oct 88 17:25 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: FUNCTION-DEFINITION (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-172554-2377@Xerox>
This issue is still actively being developed, as you can see.
This is just some evidence that we're working on it.
!
Status: DRAFT
Issue: FUNCTION-DEFINITION
References: none
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
Proposal (FUNCTION-DEFINITION:OPTIONAL):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information, or to provide
primitives for flushing some or all of the information at any time.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is trivial. The following implementation is technically
legitimate, although many implementations would want to provide something
more useful:
(DEFUN FUNCTION-DEFINITION (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL NIL NIL))
Proposal (FUNCTION-DEFINITION:REQUIRED):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information in file
compilations. In-core calls to EVAL and COMPILE would be required to
retain the information, however.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (EVAL '(LAMBDA (X) X)))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (FUNCALL (EVAL '(LAMBDA () #'(LAMBDA (X) X)))))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Additionally, this would be useful to programs which need to pass
around both a function and a representation of a function because a
single object could be passed which was efficient to call without
compromising the ability to reliably retrieve its representation.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is small, but not trivial. A simple implementation
might allocate a slot in each function that could hold the definition,
or might allocate a hash table to hold the information.
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
Pitman would prefer FUNCTION-DEFINITION:REQUIRED if people would agree to it
because it is considerably more useful in practice, but would like to see at
least FUNCTION-DEFINITION:OPTIONAL.
- - - - - Additional comments - - - - - -
re: Now that we've supposedly finished with function-type,
is anybody working on a proposal to introduce a func-
tion that would retrieve the lambda-expression defini-
tion from a user-defined function object?
Lucid Common Lisp has such a function, called SOURCE-CODE. It retrieves
the lambda expression used in an interpretive definition, even after sub-
sequent compilation of the function; but it does not attempt to maintain
an "out-of-core" database like the emacs TAGS facility.
If there were to be such a function, what would be a
good name for it?
How about EXTRACT-LAMBDA-EXPRESSION ?
The T language provides such a primitive. It is called DISCLOSE
(named for symmetry with the ENCLOSE primitive which occurs in some
Scheme dialects and coerces a lambda expression into a procedure).
DISCLOSE may be overly generic-sounding for CL use, but I recommend
DISCLOSE-DEFINITION.
I assume that the proposal will allow this function to return NIL if
the original lambda expression has been compiled or optimized to the
point where it can no longer be retrieved? I wouldn't want to require
memory-tight implementations to keep around the original form in all
cases.
Since some applications for DISCLOSE have semantic impact, I don't agree
that it should be possible for an implementation to simply throw away
the information. I believe that we should spell out particular cases
in which it is or is not permissible. My personal preferences follow:
- No compiler should be required to retain the source code
when using the file compiler. That is, using COMPILE-FILE
does not make the definition available in the environment into
which the definitions are subsequently LOADed.
- I am agnostic about interactive DEFUN, etc. I am content to see
this information retained only at the discretion of the
interpreter.
- I would prefer that arguments to COMPILE be retained, and possibly
defuns done by explicit EVAL as well. The reason for this is that
programs like Macsyma which have need of this function do not just
go around peeking into arbitrary functions (in my experience). They
usually want to peek into functions that they themselves instantiated.
So primitives that allow explicit runtime instantiation of functions
on a case-by-case basis should be reliably invertible (in my opinion).
Notes:
- I would be ammenable to permitting this function to be SETF-able,
so that people could ``NIL out'' definitions they didn't want to
retain.
- I would also be ammenable to having a special argument to COMPILE
saying that the information must be retained. I don't care what
the default value was.
- If there is not any reliable situation in which a definition will
have this information retained, then all the uses I have ever had
for this except for pretty printing are nullified. Perhaps the
pretty printing argument is reason enough to have it, though.
- There is some question about whether in the case of named objects,
(DEFUN FOO (X) X)
(DISCLOSE-DEFINITION #'FOO) => (LAMBDA (X) X) or (DEFUN FOO (X) X)?
I think the latter.
Does whether FOO is still fdefined matter? I think not.
- - - - - -
After re-reading this for 30 seconds, I'd favor OPTIONAL.
(Well, maybe I actually can't tell the difference between OPTIONAL and
REQUIRED, and "OPTIONAL" sounds better to me. Maybe I'm someone who votes
for a candidate because of his accent.)
I'm a little uneasy about "-DEFINITION", because in the residential
environment biz, the "definition" is the entire DEFUN form, and not just
the lambda expression.
Is there another postfix you'd also feel comfortable with? You say Many
implementations record this information, but not all that do publish an
interface to extracting the information.
This issue should reference FUNCTION-TYPE as as part of the Problem
Statement say that this is something that people used to do with just plain
old lambda expressions, since after (DEFUN FOO (X) ...) that
(SYMBOL-FUNCTION 'FOO) would frequently return the lambda expression
directly.
Now, with KCL and HP Common Lisp, the expression you get may not match what
you put in, e.g., might have gone thru some kind of preprocessing. (I
think.)
Also, how can the "definition" be a symbol? In CommonLisp?
Didn't we go thru (SETF (SYMBOL-FUNCTION X) 'FROB) before?
∂08-Oct-88 1956 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 19:56:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 19:52:28 PDT
Date: 8 Oct 88 19:52 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-195228-2477@Xerox>
!
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
The results of redefining as a function any of the functions,
macros, or special forms defined in the LISP package are unspecified;
similarly, the result of lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package is unspecified.
Clarify that, as implied by CLtL p. 69, it is an error to rebind
any symbol in CL defined as a constant.
The results of applying TRACE to any function in the LISP package is
unspecified.
Following the proposed definition of "results are unspecified", this means that
implementations may signal an error, or other unspecified behavior may
ensue. For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is unspecified; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the results are unspecified. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂08-Oct-88 2035 X3J13-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:35:06 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:32:13 PDT
Date: 8 Oct 88 20:32 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-203213-2505@Xerox>
!
Issue: MAPPING-DESTRUCTIVE-INTERACTION
References: MAPCAR, MAPLIST, ... (p128);
DOLIST (p126); MAPHASH (p285);
DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188);
All functions using :TEST
Related-Issues: REMF-DESTRUCTION-UNSPECIFIED.
Category: CLARIFICATION
Edit history: 07-Mar-88, Version 1 by Pitman
09-Jun-88, Version 2 by Pitman
(merge Moon's comments and update current practice)
Problem Description:
The interaction of mapping functions and DOLIST with destructive
operations on the list being operated on is unclear. For example,
if you destructively modify some tail of a list being mapped down,
does that affect the mapping process?
Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE):
Clarify that it in general is an error (the effect is not defined
but in general no error will be signalled) for code executed during a
"structure traversing" operation to destructively modify the
structure in a way that might affect the ongoing traversal operation.
For list traversal operations, this means that the cdr chain of the
list may not be destructively modified.
For array traversal operations, the array may not be adjusted and
its fill-pointer, if any, may not be changed.
For hash tables, new elements may not be added or deleted EXCEPT
that the element corresponding to the current hash key may be
changed or removed.
For packages, new symbols may not be interned in or uninterned from
the package being traversed or any package that it uses EXCEPT that
the current symbol may be uninterned from the package being traversed
in a DO-SYMBOLS.
Note: This proposal is intended to clarify restrictions on user code
for use with structure manipulators which are not inherently
destructive. Other operators, such as DELETE-DUPLICATES or NREVERSE,
may have much more complicated restrictions and are intentionally not
treated by this proposal. See the issue REMF-DESTRUCTION-UNSPECIFIED
for more discussion of such issues.
Test Case:
(LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0))
(DOLIST (FOO L)
(INCF I)
(IF (EQ FOO 'B)
(SETF (CDR LL) NIL)
(POP LL)))
(LIST I L)) might return (2 (A B)) or (3 (A B)), for example.
Rationale:
This clarifies the status quo.
Also, the likelihood that the user will want to destructively alter a
structure while it is being traversed is low. The likelihood that such
code would be readable and maintainable is also low. The likelihood
that a compiler could do some interesting optimization if this point
were not pinned down is high enough to be the overriding consideration
in this case.
Current Practice:
The implementation of DOLIST in Symbolics Genera, KCL, and PopLog Common Lisp
returns (3 (A B)) for the test case.
Cost to Implementors:
None. This simply makes the status quo explicit.
Cost to Users:
Technically none. People who were mistakenly assuming that CLtL guaranteed
things which it does not might be inclined to rewrite their code in a more
portable way.
Cost of Non-Adoption:
Users would be less informed.
Benefits:
users would be more informed.
Aesthetics:
Some might say it would be clearer to define this one way or the other, but
advocates of both camps exist and their arguments are fairly symmetric.
In any case, since this is a proposal to preserve the status quo, it has no
major impact on aesthetics.
Discussion:
This idea for this proposal was suggested by the Japanese community.
Pitman drafted the formal proposal and supports the EXPLICITLY-VAGUE proposal.
Moon generally supported version 1 of this proposal, but had some specific
criticisms about weakness of the wording which this version is an attempt to fix.
∂08-Oct-88 2043 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:43:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:40:55 PDT
Date: 8 Oct 88 20:40 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 4)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-204055-2507@Xerox>
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter (response to KMP)
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
Symbols on the LISP package may have function or macro
definitions, top level value or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions or macros; BOUNDP will be false for all
those except those documented to be variables,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
(The proposal LISP-SYMBOL-REDEFINITION addresses the
converse; that is, what user programs are allowed to do.)
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
∂08-Oct-88 2055 X3J13-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:55:17 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:51:35 PDT
Date: 8 Oct 88 20:51 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-205135-2517@Xerox>
!
Issue: PEEK-CHAR-READ-CHAR-ECHO
References: READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
MAKE-ECHO-STREAM (p330), Streams (p327-328),
READ-PRESERVING-WHITESPACE (p376),
READ-DELIMITED-LIST (p377)
Category: CLARIFICATION/CHANGE
Edit history: 06-Mar-88, Version 1 by Pitman,
23-Jun-88, Version 2 by Pitman (remove interactive stuff)
8-Oct-88, Version 3 by Pitman & Masinter
Problem Description:
The interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM is not made adequately clear about how many times
a particular character may be echoed and at what time such echo
is permissible.
For example, given:
(WITH-INPUT-FROM-STRING (STRING-STREAM "A")
(LET ((*STANDARD-INPUT* (MAKE-ECHO-STREAM STRING-STREAM
*STANDARD-OUTPUT*)))
(LET ((CHAR NIL))
(PEEK-CHAR) (PRIN1 '---)
(PEEK-CHAR) (PRIN1 '---)
(SETQ CHAR (READ-CHAR)) (PRIN1 '---)
(UNREAD-CHAR CHAR) (PRIN1 '---)
(READ-CHAR))))
what is seen on the terminal? There are at least these possibilities:
[1] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
re-fetching the char by READ-CHAR doesn't echo.
A------------
[2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
Characters are not unechoed by UNREAD-CHAR.
A---A---A---A---
[3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
No `unecho' action is done by UNREAD-CHAR.
------A------A
[4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR does not `unecho'.
A---A---A------A
[5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR unechos (a magic Erase character must be
presupposed for display terminals, a file stream that can randomly
access during output and/or back up must be presupposed for files,
paper terminals just lose):
A<Erase>---A<Erase>---A---<Erase>---A
[6] PEEK-CHAR is implemented by peeking and does not echo. The first
time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
echo, re-fetching the char by READ-CHAR doesn't echo:
------A------
This list is not believed to be exhaustive. It is only to illustrate
of the variety of possible ways in which the current specification can
be implemented without technically being in conflict with the written
word of CLtL. Obviously not all of these interpretations are considered
useful by all people, but usefulness has not been determined to be
criterial in satisfying the specification.
The description of streams (p327-328) is also [probably deliberately]
fuzzy on this issue as it relates to operating systems on which echoing
is done by the operating system. That is, some systems are line-at-a-time
and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
have long since been resolved by a system call that reads and echos input
a line at a time. Other systems are character-at-a-time and these issues
hit home in a different way. It will probably be necessary to continue
leaving things slightly unspecified in order to accomodate the native
style of the variety of operating systems now trying to support Common
Lisp, but we should be more up front about the game we are playing. (For
example, code which must port between character-at-a-time and
line-at-a-time systems must be more careful about whether it does
newline-preceded or newline-terminated output than many CL programmers
might realize given the current wording.) Additionally, though, we should
be on the lookout for less ambitious goals involving only partial
compatibility to improve the situation wherever we can find a way to.
Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
are implicitly affected by any decisions made on this issue since their
descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.
Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), the character
will be echoed on the stream the first time those characters are seen.
(Characters which are not echoed by READ-CHAR are those which were
put there by UNREAD-CHAR and hence are assumed to have been echoed
already by a previous call to READ-CHAR.)
Ammend the description of UNREAD-CHAR to say that when the stream
is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
will be made to undo any echoing of the character which might already
have been done on the stream. However, characters placed on the
stream by UNREAD-CHAR will be marked in such as way as to inhibit
later re-echo by READ-CHAR.
Ammend the description of PEEK-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), characters
which are only peeked at are not echoed. Note however that in the
case that the PEEK-TYPE argument is not NIL, the characters which
are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
echoed unless they have been marked otherwise by READ-CHAR.
Ammend the description of abstract input functions
READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
that they are implicitly affected by these new echoing rules of
READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Note: This is consistent with behavior [6] in the problem description.
Clarify that the echo behavior of interactive streams such as
*TERMINAL-IO* continues to be implementation dependent.
Rationale:
Although this is not known to be in use in any particular system,
nothing prevents its use. It proposes a more rational interpretation
of the echoing behavior of UNREAD-CHAR which might make it possible
for programmers concerned about echo behavior not to have to shy
away from UNREAD-CHAR. (It would probably also improve the behavior
of READ-PRESERVING-WHITESPACE with regard to echoing, since its
description mentions using UNREAD-CHAR.)
Correct echoing behavior is important to programs which do batch
processing, parsing, etc. Allowing multiple or premature echoing
is clearly unsatisfactory.
Current Practice:
A wide variety of behaviors are in use.
Cost to Implementors:
Unknown.
The code to implement the proposed change itself is probably fairly
localized.
In some operating systems, there may be echoing constraints which
are overlooked here.
In some cases, there may be second order effects in the system
itself which would also require a somewhat less predictable amount
of work to fix.
Cost to Users:
Any change is effectively upward compatible since the previous
behavior is so ill-specified.
Most users probably naively expect (perhaps even without realizing
it explicitly) that echoing will take care of itself. That is, they
probably expect that echoing will occur at the time of the
READ-CHAR and probably do not give a lot of thought to the effect
of PEEK-CHAR. As such, FIRST-READ-CHAR probably best supports most
of their naive intuitions.
Cost of Non-Adoption:
The streams returned by MAKE-ECHO-STREAM would continue to be
significantly hard to use portably.
Benefits:
A number of applications involving of parsers, batch script
interpreters, and such would be possible to implement
straightforwardly and portably.
Aesthetics:
?
Discussion:
Pitman supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR because
he feels it is more practically coherent. However, he says he has
only mental exercises and no actual personal experience upon which
to base that belief.
Version 1 of this proposal treated interactive streams on par
with echo streams, but while people agreed that this issue is
a severe portability problem, some considered that the treatment
of interactive streams got involved in operating system issues
that were beyond the scope of the standard, so that part of the
text was removed.
∂08-Oct-88 2106 X3J13-mailer PRINT-CIRCLE-STRUCTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:06:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 21:01:23 PDT
Date: 8 Oct 88 21:01 PDT
Sender: masinter.pa@Xerox.COM
Subject: PRINT-CIRCLE-STRUCTURE (Version 3)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-210123-2526@Xerox>
!
Issue: PRINT-CIRCLE-STRUCTURE
References: pp. 370-371
Category: CLARIFICATION
Edit history: Version 3, Masinter 10/8/88 (minor cleanup)
Version 2, Chris McConnell 10/05/88
Version 1, Chris McConnell 09/20/88
Problem description:
When a lisp object is printed that points to a structure with a user
defined print-function and there is a pointer back to the containing
object, the printer will recurse infinitely even when *print-circle*
is set to T. This prevents printing circular structures that point to
objects that cannot be printed and prevents the development of new
printed representations that can be read by the reader.
Proposal PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK:
When *print-circle* is T, a user defined print-function can print
objects to the supplied stream using WRITE, PRIN1, PRINC, or FORMAT
and expect circularities to be detected and printed using #n# syntax.
If a user defined print-function prints to a stream other than the one
that was supplied, then circularity detection starts over for that
stream.
Test Cases/Examples:
;;;
;;; Define a structure that can be circular and that has a slot with a
;;; value that cannot be printed.
;;;
(defstruct (TEST (:print-function print-test))
ptr
(function #'(lambda (x)
(error "No function is defined."))))
;;;
;;; This print function generates a machine readable printed
;;; representation for a structure with a slot that cannot be printed.
;;;
(defun PRINT-TEST (structure stream depth)
(format stream "#S(TEST PTR ~S)" (test-ptr structure)))
;;;
;;; Define two structures that point to each other. If this
;;; expression successfully evaluates at the top level, then the
;;; printed result should look like:
;;; #1=#S(TEST PTR #S(TEST PTR #1#))
;;;
;;; If it does not work then it will generate an infinite printed
;;; representation.
(setf *print-circle* t
*a (make-test)
*b (make-test)
(test-ptr *a) *b
(test-ptr *b) *a)
Rationale:
Many structures are circular and point to complex data structures that
may include things like closures that cannot be printed. It should be
possible to define a way to print these data structures such that they
can be read back in. Common LISP provides two mechanisms for these
problems (*print-circle* and the :print-function option to defstruct),
but they do not currently work together in most implementations.
Current practice:
Lucid 3.0 and the Genera do work on the test case. (Previous versions
did not.) KCL, Coral and Franz do not work.
Cost to Implementors:
Lucid and Symbolics have done it, so they could give an idea of the
difficulty. Possible techniques include passing the printer state
information by dynamic binding rather than by explicit parameters or
by supplying an internal stream to the user print function.
Cost to Users: None
Cost of non-adoption:
Currently this problem causes an infinite recursion whenever a user
print-function prints a lisp object that contains the structure that
is being printed by the user print function. If nothing is done, this
error will remain and the whole effort to provide a portable printed
representation of LISP structures is of minimal usefulness. In almost
any real application, there are circular structures with non printable
objects such as closures and hash tables that need to be printed. In
addition the development of printers for new reader macros becomes
much more of an effort then it should be since it requires
reimplementing the complete circularity detection mechanism.
Benefits:
If the proposal is adopted, then it becomes easier to define new
printed representations that are compact and that still capture the
information needed to rebuild data structure instances. It allows a
printed representation to hide the actual details of how a data
structure is implemented in terms of underlying LISP data structures.
Esthetics:
This proposal increases the uniformity of the language by making
*print-circle* work in all cases including where a user has defined a
new print function.
Discussion:
At least three members of the cleanup committee read this and think
it looks good.
∂08-Oct-88 2112 X3J13-mailer DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:11:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 21:06:34 PDT
Date: 8 Oct 88 21:06 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: PROCLAIM-LEXICAL (Version 8)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-210634-2532@Xerox>
We're still working on this one.
!
Status: DRAFT
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Version 8 by Pitman 06-Oct-88 (merge recent discussion)
Status: For Internal Discussion
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which does
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that dynamic binding does DG lookup. That is, variables
declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the lexical. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect this declaration.
Test Case:
#1: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
#2: ; Warning: It is unlikely that any serious program would
; be written in so obscure a manner as this example.
; This just tests the fringe cases.
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
If the results of this example confuse you, keep in mind
that the results of code like this would be somewhat
confusing no matter what the chosen semantics because the
code itself is far from perspicuous.
An explanation of this behavior, which some people find less
than intuitive because of the bizarre choice of constructs:
X gets bound lexically to 3 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively]
proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making
lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making
dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively]
proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not
[special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding
of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically
active Y=4 in a list which becomes third list element.
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
A fair amount compiler work would probably be needed. Some compilers
may have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Moon says...
I have now thought of an efficient way to do this on Lisp machines,
using invisible pointers, and another efficient way to do it on
stock hardware, using one extra instruction on every global
reference of one or the other sort, plus a few extra instructions
in SPECIAL binding and unbinding. Given that, I no longer object
to the proposal as unimplementable.
It doesn't just require a few compiler changes, it requires some
reimplementation of the representation of global variables, with
concomitant changes to the compiler, the loader, the interpreter,
and probably the debugger. Every symbol now potentially has two
values accessible from the interpreter (the current SPECIAL and
the global LEXICAL) and you need the corresponding new data
structure to keep track of that.
Rees suggests...
In shallow-bound implementations, implementors may have to add a
small run-time routine that searches the dynamic saved-binding
stack to look for the global value in the case where the variable
has been dynamically bound. One might want a bit (or a count)
somewhere (perhaps in the symbol itself) to speed up the common
case of access to a global binding of a variable that hasn't been
dynamically bound; without some kind of optimization, you have to
search the whole saved-binding stack on every reference to a
free [lexical] variable.
While naively you might think you'd incur the cost of clearing the
valid bit on every dynamic binding (not acceptable), in actuality
the bit is a static property of programs (PROGV excepted). So the
only places you ever need to clear FOO's valid bit are in PROGV,
in the interpreter, and when FASLOADing code that contains a compiled
dynamic binding of FOO.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
Improved appeal to a certain sector of the programming community.
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
In principle, we could imaging saying that free variables should be
lexical by default, but that would only reduce error checking to no
good end. To be really useful, this proposal will need to be followed
by a proposal for primitives analogous to DEFVAR and/or DEFPARAMETER
but for lexical variables. However, since arguments over syntax are
likely to have plenty of issues of their own, we've separated this
proposal for primitive functionality from issues of syntax which
can be dealt with separately once this is passed.
Moon expressed concerns about the efficiency issues but after
thinking about it for a while convinced himself that this is
efficiently implementable both on stock and special purpose hardware.
JonL expressed concerns about the last-minute nature of this change,
which he sees as untested.
Dalton suggests that an alternative solution to the speed issue
might be possible to obtain by restricting a particular variable to
be either LEXICAL or SPECIAL but not both.
Dalton points that even if people don't like the details here, there
must be a better fallback solution than "do nothing". Pitman agrees
heartily.
----- End Forwarded Messages -----
∂08-Oct-88 2134 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:34:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:30:41 PDT
Date: 8 Oct 88 21:30 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-213041-2554@Xerox>
!
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
The instructions on CLtL pp. 189-191 on the placement of PROVIDE and
REQUIRE don't work because they ignore interactions with LOAD. If
PROVIDE is placed at the head of a file which fails to load correctly,
the module will be incorrectly recorded as loaded. If PROVIDE is
placed at the end of the file, as is the unofficial current practice
in some groups, it is not possible to REQUIRE a file that REQUIREs the
current file; thus mutually dependent modules cannot be correctly
defined.
Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):
Remove the second argument from REQUIRE. Change the description of
REQUIRE to:
The REQUIRE function tests whether a module is already present
(using a case-sensitive comparison); if the module is not present,
REQUIRE signals a correctable error of type REQUIRE-ERROR. The
error can be corrected by loading the appropriate file(s).
Note that there is no requirement that a module consist of exactly one
file.
Change the description of PROVIDE to:
"The PROVIDE function adds a new module name to the list of
modules maintained in the variable *MODULES* and possibly performs
other implementation-dependant actions to indicate that the module
in question has been loaded."
(There is no need to make a corresponding change to the definition of
REQUIRE, because it doesn't mention *MODULES*.)
Add a new second paragraph to the section on LOAD (CLtL 23.4):
"Top level PROVIDE functions in files being loaded are handled
specially. The PROVIDE is executed in a temporary environment
such that the module will appear to have been loaded during the
remainder of the load of the current file and any files loaded,
whether directly or by REQUIRE, during the loading of the current
file. If an error occurs during the loading of the current file,
all modules PROVIDEd during the load of the current file will be
forgotten. Otherwise, all these modules will be "confirmed" at
this level of nested loading. (Note that an implementation which
uses *MODULES* as the only loaded module database can support all
of this by simply rebinding *MODULES* appropriately internally
and pushing the new modules onto the old binding at the end.)"
Test Cases/Examples:
(REQUIRE 'fft)
Would still be legal.
(REQUIRE 'fft "fft")
Would no longer be Common Lisp.
Rationale:
The file loading feature of REQUIRE is non-portable. Since we can't
figure out an acceptable portable solution, the feature should be
flushed. Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.
Current practice:
All implementations that I know of currently support a second argument
to REQUIRE. Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.
Cost to Implementors:
All currently conforming implementations will have to make a small
change.
Cost to Users:
Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change. On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.
Cost of non-Adoption:
Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.
Benefits:
PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
Pierson supports this proposal.
This proposal creates an asymmetry in the handling of *MODULES* that
may bother some people.
Several people would like to simply eliminate PROVIDE and REQUIRE from
the language and either leave this language space empty or provide a
portable DEFSYSTEM standard. Others believe that PROVIDE and REQUIRE
are useful as a safety-net even in the presence of DEFSYSTEM. This
proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
safety-net and leaves the question of DEFSYSTEM to a separate
proposal (which I don't intend to write).
∂08-Oct-88 2146 X3J13-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:45:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:40:35 PDT
Date: 8 Oct 88 21:40 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-214035-2555@Xerox>
!
Issue: ROOM-DEFAULT-ARGUMENT
References: ROOM (p442)
Category: ADDITION
Edit history: 12-Sep-88, Version 1 by Pitman
Problem Description:
Passing no argument to ROOM is not equivalent to any argument which
can be passed. This makes data-flow from another function which wants
to call ROOM inconvenient. Rather than simply passing a value through,
the correct calling sequence must be selected as well. For example,
one might have to do something like
(CASE FLAG
(:DEFAULT (ROOM))
((T NIL) (ROOM FLAG)))
where (ROOM FLAG) would suffice
Proposal (ROOM-DEFAULT-ARGUMENT:NEW-VALUE):
Specify that passing an argument of :DEFAULT is equivalent to passing
no argument to ROOM.
Test Case:
(ROOM ':DEFAULT) is functionally equivalent to (ROOM).
Rationale:
Minimal change needed to get around the stated problem.
Allows ROOM to be describable without reference to supplied-p
information.
Current Practice:
Symbolics Genera defines ROOM using &REST and looks for NIL, (T), or (NIL).
[This reduces its ability to do compile-time number-of-argument checking.]
Some other implementations probably have a magic undocumented value
to avoid use of a SUPPLIED-P argument.
Cost to Implementors:
Probably it involves negligible resources to change this.
In most implementations, the resulting code would probably look better.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
The description of ROOM will look yucky in the emerging specification.
The source code for ROOM will look yucky.
[How's that for objective? -kmp]
Error checking in some implementations may be sub-optimal.
Benefits:
The description of ROOM in the now-being-written specification would
be less complicated.
Aesthetics:
This proposal would make a minor improvement in aesthetics.
Discussion:
This is obviously a low-priority issue, but would require such little
resources to fix that it seems worth doing.
Pitman supports this addition.
It's perhaps too bad that keywords like :SHORT, :MEDIUM, and :LONG
weren't chosen instead of T and NIL, since T and NIL have a bit of a
binary feel to them and it's hard to think of a good name for the
default case.
∂08-Oct-88 2129 X3J13-mailer DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:29:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:24:26 PDT
Date: 8 Oct 88 21:24 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-212426-2546@Xerox>
There were at least 20 messages after this draft was circulated
among the cleanup committee; the discussion is too long to append
and there is currently no summary of it. However, this issue
was last raised in November 1987; perhaps some resolution will
be more forthcoming.
!
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION
Edit history: 11-Feb-87, Version 1 by DLA@Stony-Brook.SCRC.Symbolics.COM,
29-Oct-87, Version 2 by Pitman (flesh out proposals)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
In MAKE-EXPLICITLY-DEFINED, BAR would hold (C D E F).
In MAKE-EXPLICITLY-VAGUE, any of these interpretations (and
others as well) would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
In MAKE-EXPLICITLY-DEFINED, they would return (B C) and NIL.
In MAKE-EXPLICITLY-VAGUE, either of these interpretations (and others
as well) would be valid.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED):
Clarify that the destructive behavior of the following operators
is restricted as indicated. Note well -- only the side-effect behavior
of these functions is discussed here; these remarks are not intended
as complete functional descriptions.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF the CADR of what
(GET-PROPERTIES place (LIST indicator)) would return.
(REMF place indicator)
is permitted to either SETF place or to SETF the CDR of the
part of the top-level list in place which points to what
(GET-PROPERTIES place (LIST indicator)) would return.
In particular, the two removed cells may not be destructively
modified.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list is permitted to setf the CDR of any
subtail of sequence to point to any other subtail of sequence,
to NIL, or to any piece of newly created list structure.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a tail whose car is object.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list is permitted to SETF the CDR of any part
of that list which points to a duplicated element that is to be
removed.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list is permitted to SETF the CAR of any part
of that list which must be replaced by NEW-OBJECT.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF the CDR of the LAST of any of its argument
lists which are non-null, except the last argument.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF the tail of its argument list whose CDR
is LAST of that argument LIST.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to setf the CDR of any subtail of either list to point
to any other subtail of either list, to NIL, or to any piece of newly
created list structure.
Rationale:
This implements what some users will consider the status quo.
In most cases, it is consistent with what naive implementations of
these functions might do.
Benefits:
By being more explicit about the side-effects which can be expected,
users can write programs which more reliably exploit these side-effects.
In some case, this may make certain programming problems easier.
Certain naive user assumptions and assumptions based on the behavior
of older lisp dialects would be supported.
Compatibility with older Lisp dialects (eg, Zetalisp, Maclisp, ...)
would generally be better.
Gratuitious porting hassles would be naturally lessened slightly.
In situations where programmers inadvertently depended upon the specific
nature of a particular operator's side-effect, chances would be much
greater that the code would be portable because there would be less room
for implementations to vary.
Non-Benefits:
Implementations may be forced to be less efficient than they could be
if the MAKE-EXPLICITLY-VAGUE proposal were adopted, since that proposal
allows implementors more room for optimization. Some existing
implementations will be forced to become less efficient to meet the
standard, degrading performance of existing applications which do not
rely on the new features with no benefit to those existing applications.
Adoption Cost:
Some implementations would have to change. For example, Symbolics Common
Lisp makes more unusual assumptions about what it can modify than some
of the above rules allow.
Conversion Cost:
Probably none. Users must currently tread lightly since they really
have no idea in many cases what kind of side-effect is really likely to
occur when they use some of the existing destructive operators.
Some implementations might be forced to change, and since some user
programs might have depended on the old behavior, programs which used
to run might be broken in the transition. However, in most cases where
an implementation guarantees any behavior, it is likely to be the one
suggested here. Systems which have other behaviors are likely to warn
users not to depend on the specifics of those behaviors. So the incidence
of problems arising in practice is likely to be very small, though
probably not nonzero.
Aesthetics:
Some of these restrictions tend to expose more detail about the
implementation of these operators, turning them from abstract operations
into more concrete utilities. This is probably an issue that can be
addressed by appropriate information hiding in a User's Manual however.
No matter how unpleasant the presence of these somewhat concrete
restrictions may seem, the porting bugs which arise in their absence are
bound to seem more unpleasant to some users.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE):
Clarify that the destructive behavior of the following operators
is restricted as indicated:
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Rationale:
This is probably the status quo from a typical implementor's point of view.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Adoption Cost:
None. This is the status quo for implementors.
Conversion Cost:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Conversation on the Common-Lisp mailing list has made it clear that
the current situation is not good because it does not make the designers'
intent clear. The list modification allowed should either be specified,
or explicitly documented as unspecified and up to the individual
implementation. If the list modification is specified, then programmers
can rely on the specification. If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.
Pitman believes that REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-VAGUE
may be better from a purist point of view, but strongly supports
REMF-DESTRUCTION-UNSPECIFIED:MAKE-EXPLICITLY-DEFINED
because of practical considerations related to reliably being able to
debug portable code, a stated priority of an ``industrial strength''
language such as Common Lisp. The more alike implementations are forced
to be, the better the chances that something that ran one place will run
another.
DLA, who raised this issue, disagrees strongly. He cites efficiency
and does not believe performance should be traded off for features
which reasonable code does not tend to use. Metering in Symbolics test
systems have shown that there are performance gains to be had by
allowing implementations flexibility in these areas. DLA believes that
if users want more predictability from these functions, they should
write private variants that implement whatever predictability they
require. Additionally, he argues that the implementation users expect
is not obviously the one chosen in MAKE-EXPLICITLY-DEFINED. For
example, many programmers have used NREVERSE for years and assumed that
it shuffled list elements rather than CDRs.
DLA points out that MAKE-EXPLICITLY-DEFINED is still lax enough that if
FOO holds (A B) and you do (SETF (GETF FOO 'A) 'C), FOO could be
(A C A B). We should be sure this doesn't get left vague if that
proposal is adopted.
----- End Forwarded Messages -----
∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:59:47 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:58:06 PDT
Date: 8 Oct 88 21:58 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215806-2579@Xerox>
!
Issue: SYMBOL-MACROLET-DECLARE
References: SYMBOL-MACROLET (88-002R page 2-81)
WITH-ACCESSORS (88-002R page 2-88)
WITH-SLOTS (88-002R page 2-92)
Category: ADDITION
Edit history: Version 1, 12-Sep-88, Moon
Problem description:
It would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet. A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.
Test Cases/Examples:
See problem description.
Rationale:
If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations. When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration. However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.
Current practice:
SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
Cost to Implementors:
Less than one man-hour.
Cost to Users:
None.
Cost of non-adoption:
Minor wart in the language.
Benefits:
More consistent language definition.
Esthetics:
More consistent language definition.
Discussion:
None.
----- End Forwarded Messages -----
∂08-Oct-88 2203 X3J13-mailer DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:03:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:00:34 PDT
Date: 8 Oct 88 22:00 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue SYMBOL-MACROLET-SEMANTICS, Version 4
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220034-2580@Xerox>
This is DRAFT because of some confusion over the handling
of SETQ of symbol-macros.
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Also, Pitman points out that, rather than extending the existing
MACROEXPAND and MACROEXPAND-1 functions, new functions could be introduced
to expand symbol macros. However, there seems to be no particular reason
to do this.
----- End Forwarded Messages -----
∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TAILP-NIL (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:11:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:07:06 PDT
Date: 8 Oct 88 22:07 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: TAILP-NIL (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220706-2582@Xerox>
!
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two common implementations of this definition are:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eq sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eq list sublist))
(if (eq sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Proposal (TAILP-NIL:NIL):
Clarify that the sublist argument to TAILP must be a list
and that (TAILP NIL X) returns NIL for all lists X.
Qualify the description in CLtL by saying that (TAILP sublist list)
is true if SUBLIST is a cons and (NTHCDR n list) is SUBLIST for
some value of N, and is false otherwise.
Rationale:
This is the status quo in a number of implementations.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
SUBLIST for some value of N, and false otherwise.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Test Cases:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns NIL under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#4: (TAILP 3 '(A B C))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
#5: (TAILP 3 '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#6: (TAILP '(X Y) '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
[Walter alleges TAILP-NIL:NIL is what all implementations already
do, but since Genera is not in conformance, KMP regards that
hypothesis as suspect. We need real data points, folks.]
Cost to Implementors:
An implementation of TAILP-NIL:NIL is given as Definition "A" in the
problem description.
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Either description makes the language more precise.
[Pitman believes that] TAILP-NIL:T is more consistent with the behavior
of TAILP and more consistent with what he thinks should be the
definition of a sublist.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
Pitman supports TAILP-NIL:T.
----- End Forwarded Messages -----
∂08-Oct-88 2211 X3J13-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:11:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 22:07:11 PDT
Date: 8 Oct 88 22:07 PDT
Sender: masinter.pa@Xerox.COM
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-220711-2583@Xerox>
!
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Issue FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Status: For Internal Discussion
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Discussion:
Moon expressed reservations about FLUSH-ALL (in Version 1, where
FLUSH-TEST-NOT was not offered) because it was such an incompatible
change.
Steele (commenting on Version 1) noted that his main reservation to
FLUSH-ALL is that he uses REMOVE-IF-NOT much more than REMOVE-IF.
Pierson, Dalton and Pitman support the combination of
TEST-NOT-IF-NOT:FLUSH-ALL (and FUNCTION-COMPOSITION:NEW-FUNCTIONS)
in spite of the incompatible change because of the aesthetic appeal.
This issue is related to FUNCTION-COMPOSITION, but is not dependent
on it.
van Roggen points out that a long time ago, he suggested dropping
-IF-NOT and :TEST-NOT, adding a function such as COMPLEMENT, and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
Richard Mlynarik suggests that even the -IF functions provide
little extra use since
(xxx-IF test sequence ...)
can be rewritten
(xxx test sequence :test #'funcall).
He says he doesn't care what we do with this issue, however, since
he will just continue to use [MIT-style] LOOP in cases where these
sequence functions would seem to be called for.
----- End Forwarded Messages -----
∂08-Oct-88 2153 X3J13-mailer Issue: SETF-SUB-METHODS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:53:35 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:50:04 PDT
Date: 8 Oct 88 21:50 PDT
Sender: masinter.pa@Xerox.COM
Subject: Issue: SETF-SUB-METHODS (Version 5)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215004-2565@Xerox>
!
Issue: SETF-SUB-METHODS
References: CLtL pp. 95-96, 99, 105-106, 166
Issue: PUSH-EVALUATION-ORDER
Category: CLARIFICATION
Edit history: Version 1: JonL White & Ken D. Olum 12-Feb-88
(based on problem originally called SETF-METHOD-FOR-SYMBOLS)
Version 2: JonL White 23-May-88 (fix references and spellings).
Version 3: JonL White 25-May-88
Version 4: JonL White & Ken D. Olum 26-May-88 (final insights!)
Version 5: Masinter (respond to comments)
Problem description:
Implementations differ in the left-to-right order
of evaluation in the following form:
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
In some implementations, the side-effect of the setq appears to happen before
the evaluation of the place form (getf r 'b) which is necessary to fetch the
list being updated. A typical result is 'r' = (B 6), 's' = (A 1 B 2 C 3)
after the operation.
There is a similar problem with SETF's over LDB, MASK-FIELD, and CHAR-BIT.
CLtL p99 is explicit about left-to-right order of evaluation.
However, the specification is less clear about computations involved
in "evaluation" of the subforms, and other computations that are implicit
in the notion of "doing an access" or "doing a store".
Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES
This proposal specifies more explicilty the behavior of SETF in the case
of access forms whose sub-forms are permitted to be generalized variable
references [and which thus need to call GET-SETF-METHOD during setf macro
expansion].
Remember, first, that GET-SETF-METHOD returns the following:
-- Some temporary variables
-- A list of value-producing forms
-- A list of store-variables (normally one).
-- A storing form.
-- An accessing form.
The code produced as the macro expansion of a SETF form that
itself admits a generalized variable as an argument must essentially
do the following major steps:
** It evaluates the value-producing sub-forms, in left-to-right order, and
binds the temporary variables to them. This will be called "binding the
temporaries."
** It "reads the value" from the generalized variable using the supplied
accessing form, to get the "old value"; this will be called "doing the
access." [Note that this is done after all the evaluations of the
preceeding step, including any side-effects they may have.]
** It binds the store-variable to a new value, and then installs this
new value into the generalized variable using the supplied "storing
form". This will be called "doing the store."
"Reading the value" of a generalized variable reference is not part of
the series of evaluations that must be done in left-to-right order.
The place-specifier forms listed at the top of CLtL p96 permit admit (other)
place-specifiers as arguments; during the SETF expansion of these forms, it
is necessary to call GET-SETF-METHOD in order to figure out how the inner,
nested generalized variable must be treated. This proposal requires GETF be
listed among these forms, since it must have a sub-recursive <place> specifier
[however, there is no Common Lisp function serving as a pseudo-update function
for it, the way DPB serves for LDB].
For each place-specifier form with a sub-recursive place specifier,
the information from GET-SETF-METHOD is used as follows.
CHAR-BIT:
In a form such as:
(SETF (CHAR-BIT <place-form> <bit-name>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to a character object itself.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <bit-name> (and bind into a temporary)
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form>, with the given bit-name of the
character fetched in step 4 changed to reflect the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different "bit" of the character --
then the change of the bit denoted by <bit-name> will be to that altered
character, because the "access" step is done after the <value-form>
evaluation. See example 1 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
LDB:
In a form such as:
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to any object of type integer.
Thus this SETF should generate code to do the following:
1. Evaluate <byte-spec> (and bind into a temporary)
2. Bind the temporaries for <place-form>
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with the given bit-field of the integer
fetched in step 4 replaced with the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different bit-field of the integer --
then the change of the bit-field denoted by <byte-spec> will be to that
altered integer, because the "access" step is done after the <value-form>
evaluation. See example 2 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
MASK-FIELD:
This case is the same as LDB in all essential aspects.
GETF:
In a form such as:
(SETF (GETF <place-form> <ind-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not necessarily to the particular list
which is the property list in question.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <ind-form> (and bind into a temporary)
3. Evaluate the <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with a possibly-new property list
obtained by combining the values from steps 2, 3, and 4.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different named property in the list,
then the change of the property denoted by <ind-form> will be to that
altered list, because the "access" step is done after the <value-form>
evaluation. See example 7 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
Note that this phrase "possibly-new property list" treats the
implementation of property lists as a "black box" -- it can mean that
the former property list is somehow destructively re-used, or it can
mean partial or full copying of it. This is like the question of REMOVE
or DELETE -- do you copy or do you destructively alter. Since the answer
could go either way, the treatment of the resultant value for the
"possibly-new property list" must proceed as if it were a different copy
needing to be stored back into the generalized variable.
The "read-modify-write" macros such as INCF, DECF, PUSH, POP,
and REMF, as well as PSETF, SHIFTF, and ROTATEF should be
specified to have the same evalauation order for the subforms of
the "place" arguments; this would generally follow from their definition
in terms of SETF.
Test Cases:
1. (setq char (make-char #\A 1)) ==> #\Control-A
(rotatef (char-bit char :control)
(char-bit char :meta))
char ==> #\Meta-A
;; It's as if you start with #\Control-A, and then first turn the
;; :control bit off, because the :meta bit was originally off; and
;; then to the resulting #\A, you add the :meta bit since the
;; :control bit was originally on.
Note, however, that if an implementation doesn't support both of these
character 'bits', then this test case would have to be re-written to
reference two independent bits actually supported. If an implementation
supports fewer than two independent character bits, then this test case
is entirely moot.
2. (setq integer #x69) ==> #x69
(rotatef (ldb (byte 4 4) integer)
(ldb (byte 4 0) integer))
integer ==> #x96
;; This very-realistic example is simply trying to swap two
;; independent bit fields in an integer. Note that the generalized
;; variable of interest here is just the (possibly local) program
;; variable 'integer'.
3a.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (prog1 l1
(setq l1 nil)))))
l1 ==> nil
l2 ==> (#x99)
;; Note that the (setq l1 nil) didn't affect the actions of the setf
;; at all, since l1 was evaluated and its value was saved away in a
;; temporary variable as part of the step "2. Bind the temporaries
;; for <place-form>", and this was done before the evaluation of the
;; <value-form> which contains the (setq l1 nil). Note also that the
;; step "4. Do the access to <place-form>" means fetching the CAR of
;; the saved (temporary) value of 'l1'; it does not mean doing a LDB
;; on anything like that.
3b.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (rplaca l1 #x17))))
l1 ==> (#x77)
l2 ==> (#x77)
;; Note that the (rplaca l1 #x17) altered the contents of what l1
;; was pointing to. Thus even though l1 was evaluated and its
;; value was saved away in a temporary variable as part of the step
;; "2. Bind the temporaries for <place-form>", and even though this
;; was done before the evaluation of the <value-form> which contains
;; the rplaca, still the side-effect changes things because it alters
;; what will be fetched during the "do the access" step.
4. (setq integer #x69)
(setf (mask-field (byte 4 4) integer) (incf integer)) => #x6A
integer ==> #x6A
5. (setq integer #x6A)
(setf (mask-field (byte 4 4) integer) (ash (incf integer) 4)) => #x6B0
integer => #xBB
6. (setq s (setq r (list 'a 1 'b 2 'c 3))) ==> (a 1 b 2 c 3)
(setf (getf r 'b)
(progn (setq r nil) 6)) ==> 6
r ==> (b 6)
s ==> (a 1 b 2 c 3)
;; Note that the generalized variable of concern here is the (degenerate?)
;; one of simply the program variable 'r'; it is not a property-list
;; slot denoted by (getf r 'b). At the time the step "4. Do the access
;; to <place-form>" is performed, the evaluation of the <value-form>
;; has already altered the generalized variable 'r', and thus a nil is
;; returned for this access; that is why a fresh property-list (B 6) is
;; created an stored back into 'r'.
7. (setq s (setq r (list (list 'a 1 'b 2 'c 3)))) ==> ((a 1 b 2 c 3))
(setf (getf (car r) 'b)
(progn (setq r nil) 6)) ==> 6
r ==> nil
s ==> ((A 1 B 6 C 3))
;; Note that the (setq r nil) does not affect the actions of the setf
;; because the value of R had already been saved in a temporary variable
;; as part of the step "1. Bind the temporaries for <place-form>". Only
;; the CAR of this value will be accessed, and subsequently modified
;; after the value computation.
Rationale:
As a principle,
(setf (foo-a x) (progn (setf (foo-b x) ...)
new-a-value))
should always set both of the "slots" of 'x', even if these slots are
implemented as bit-fields, getf-properties, and so on. Only by separating
out evaluation from "generalized variable access", and by specifying that
the access is done after all the evaluations, can this correctly be done.
Current Practice:
Lucid Common Lisp already operates pretty much according to this proposal.
Symbolics Genera 7.2 foolishly adopted an earlier proposal
(SETF-METHOD-FOR-SYMBOLS) before it was officially approved by X3J13 and
its parent standards organization. This proposal is incompatible with
that one, so Genera 7.2 does not implement the behavior described here,
and fails test cases 1, 2, 4, 5, and 6. Symbolics Genera 7.1
is probably closer to this proposal.
Performance impact:
Small. This proposal might slow down macro-expansion slightly,
might cause some current optimizations not to work as well. However,
the net effect is likely negligible.
Cost to Implementors:
In some implementations, this would require a careful revisiting of
the handling of SETF and generalized variable modifiers.
Cost to Users:
Small; although this will impose an incompatible change on
implementations that don't behave as proposed, and might have
an effect on (non-portable) code, we believe the effects
are not widespread.
Cost of non-adoption:
SETF left-to-right order of evaluation will not be well specified;
implementations will differ for no good reason.
Benefits:
Uniform semantics and portability in the face of recursive "place specifiers"
for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
uniformly no matter the nature of the <place>.
Anyone who has copied examples from p105 and p106 will continue to
be able to use them.
Esthetics:
See "Cost of non-adoption"
Discussion:
This is a difficult proposal to specify.
In the detailed descriptions for each access form, the phrase
"the place referred to by the <place-form> must always be both
accessed and updated; note that the update is to the generalized
variable specified by <place-form>"
is not intended to prevent optimizations that could occur when the
code "knows" that the new value will be EQ to the old one. The only
requirements is that the results be semantically equivalent.
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete, although permitted to destructively modify the original
list, may also return some tail of the list originally give it,
whether or not an alteration occurs.
(setq l '(a a b c d)) ==> (a a b c d)
(delete 'a l) ==> (b c d)
l ==> (a a b c d)
The unwary user thinks that because 'l' is still EQ to the original value
that "DELETE didn't do anything". The temptation to ignore the resultant
value of DELETE parallels the temptation to forget about a need to perform
a final update to <place-form> in the setf-of-getf case.
In the (degenerate?) case when a generalized variable
is in fact simply a program variable, then there are no sub-forms to be
considered "value-producing" forms; in fact, "doing the access" for such
a generalized variable (i.e. a program variable) is functionally the
same as evaluating it. This explains why the behaviour in the "Problem
Description" is at first perplexing -- the "do the access" step has the same
semantics as an evaluation step, even though it is done after all the
prescribed evaluations.
The issue PUSH-EVALUATION-ORDER is a clarification about just the point
of the evaluation order for the various subforms to a PUSH; thus there
is a similarity to this issue, but the present issue has a much deeper
problem because of the need to call GET-SETF-METHOD during setf macro
expansion.
∂08-Oct-88 2159 X3J13-mailer DRAFT Issue: STREAM-INFO (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88 21:59:37 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 21:55:17 PDT
Date: 8 Oct 88 21:55 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: STREAM-INFO (Version 5)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-215517-2573@Xerox>
This issue has some interactions with the character proposal.
There has been a recommendation (from me) that the functions
be allowed to return/accept non-complex numbers rather than
integers where possible, given the possibilities of output
streams that can do arbitrary scaling.
Perhaps this issue should have been called
PRETTY-PRINT-WIDTH-SUPPORT
!
Status: DRAFT
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to discussion)
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal (STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS):
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative integer. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns an integer representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it should
have the same line-width and width unit as the base output stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
Dick Waters submitted a request for changes along the line of the
horizontal aspects of these functions in a letter to X3J13 dated
June 14, 1988. Pitman and Waters wrote up the request formally.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum which is
required to support pretty printing into a stream which
displays output using a variable width font.
We drafted an alternate proposal, STREAM-INFO:TWO-DIMENSIONAL-FUNCTIONS,
which goes significantly beyond what is needed merely for pretty printing
and provides primitives LINE-DIMENSIONS, LINE-POSITION,
PRINTED-DIMENSIONS, and WRITE-SPACE but it is not included here.
A key point of contention which would be likely to swamp the 2d proposal
is the age old question of how to handle the issue of vertical distance
(where is the origin, which way do you count, ...). If anyone would
prefer to see larger problem 2d proposal, it could be circulated, but at
the last minute Pitman got worried that even the 1d version was going to
be controversial enough and decided to keep things focused on that.
For his own needs, Waters is strongly interested in having either
ONE-DIMENSIONAL-FUNCTIONS or TWO-DIMENSIONAL-FUNCTIONS proposal accepted,
but does not care which. Pitman concurs.
One variation of the 1d proposal might be useful to consider:
PRINTED-WIDTH could return two additional values: the number of newlines
that WRITE-STRING of the string would execute and the maximum X position
encountered (which might differ from the first value if the number of
newlines was non-zero).
This feature wasn't necessary for Waters' minimalist proposal, but Pitman
would be willing to write it in here if people thought it would be useful
enough for other purposes.
The 5th version was changed from the 4th by responding to suggestions
about better names for the functions, including a discussion of how
line-width should apply to various kinds of derivative streams, and
most importantly, by including a much more precise specification for
what the minimal capabilities of the functions should be.
----- End Forwarded Messages -----
∂08-Oct-88 2216 X3J13-mailer DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88 22:16:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473488; Sun 9-Oct-88 01:14:46 EDT
Date: Sun, 9 Oct 88 01:14 EDT
From: CL-Cleanup@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
To: X3J13@SAIL.Stanford.EDU
cc: cutting.pa@Xerox.COM
References: <880801-102621-1527@Xerox>
Message-ID: <881009011429.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This is a DRAFT still under discussion. The "Additional Comments"
at the end are still to be dealt with.
-----
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): UNREAD-CHAR may not be called
after PEEK-CHAR without an intervening call to READ-CHAR.
Test Cases/Examples:
;;; Following is an example of code which should not be valid CL.
(defun test (stream)
(let ((char (read-char stream)))
(peek-char nil stream)
(unread-char char stream)
(assert (eql char (read-char stream)))))
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another (keyboard with
line-buffering turned off) did not.
Cost to Implementors:
Zero. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
- - - - - - - - - - Additional Comments - - - - - - - - - -
- The proposal part is confusingly worded.
The wording says that in a stream "abc", if I READ-CHAR to get the #\a
into variable CH1 and then I PEEK-CHAR to see the "b", then I must call
READ-CHAR before I can (UNREAD-CHAR CH1). But if I take that literally,
I'll do (SETQ CH2 (READ-CHAR S)) (UNREAD-CHAR CH1 S) and that's not what
I want. Having done the READ-CHAR, I can only UNREAD-CHAR the char I just
did READ-CHAR to get. In effect, I can never UNREAD-CHAR CH1 once I've
peeked at or read the next char. Some streams will let me back up at this
point, but only those which would have let me back up before doing the
READ-CHAR in the first place.
It would be clearer for the proposal to just say that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not portable.
- A misreading of the proposal might lead one to believe that one could
do (SETQ CH1 (READ-CHAR STREAM))
(SETQ CH2 (PEEK-CHAR NIL STREAM))
(SETQ CH3 (READ-CHAR STREAM))
(UNREAD-CHAR CH1 STREAM)
since the unread-char is correctly separated from the PEEK-CHAR by an
intervening READ-CHAR. The problem is that the wrong char is being
unread. Some implementations support this, but it's definitely not
condoned by the description of UNREAD-CHAR on p379.
- I found the following test case to be more insightful:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
- Current practice (for my test case above) in Symbolics Genera:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
∂09-Oct-88 0230 X3J13-mailer Draft Issue: CLOS-CONDITIONS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88 02:30:05 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473546; Sun 9-Oct-88 05:28:47 EDT
Date: Sun, 9 Oct 88 05:28 EDT
From: CL-ERROR-HANDLING@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Draft Issue: CLOS-CONDITIONS (Version 3)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <881009052832.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
There's been some disagreement about a couple of details, so this may
change yet again before we ask you to vote on it, but this is the
version that is likely to be presented for comment at the meeting.
The conflict is represented in the writeup by the presence of two
variant proposals, YES-OPTION-A and YES-OPTION-B.
-----
Issue: CLOS-CONDITIONS
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Subproposal (CLOS-CONDITIONS:YES):
[These options are very similar. They agree except as otherwise noted.]
Define that condition types are CLOS classes.
Define that condition objects are CLOS instances.
Permit multiple parent-types to be named in the list of
parent types. Define that these parent types are treated the
same as the superior class list in a CLOS DEFCLASS expression.
Define that slots in condition objects are normal CLOS slots.
Note that WITH-SLOTS can be used to provide more convenient
access to the slots where slot accessors are undesirable.
Functions such as SIGNAL, which take arguments of class names,
are permitted to take class objects. Such class objects must
still be subclasses of CONDITION.
Eliminate the :CONC-NAME option to DEFINE-CONDITION.
Define that condition reporting is mediated through the
PRINT-OBJECT method for the condition type (class) in question,
with *PRINT-ESCAPE* always being NIL. Specifying
(:REPORT fn) in the definition of a condition type C is
equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
Proposal (CLOS-CONDITIONS:YES-OPTION-A):
All of subproposal YES, plus the following...
Extend the syntax for a slot in a DEFINE-CONDITION as follows...
- If a symbol is used, DEFINE-CONDITION will by special case
treat this as if (symbol :INITARG keyword :READER reader-name)
were specified instead, where KEYWORD is generated by
(INTERN (SYMBOL-NAME symbol) (FIND-PACKAGE "KEYWORD"))
and reader-name is generated by
(INTERN (FORMAT NIL "~A-~A" condition-type symbol))
for CONDITION-TYPE being the condition type being defined.
- A length 1 list, (symbol), is treated the same as providing
the symbol itself.
- If a length 2 list, (symbol value) is provided, it is treated
as (symbol :INITARG keyword :READER reader-name :INITFORM value),
with KEYWORD and READER-NAME being computed as above.
- If a list of length greater than 2 is used, it is treated
the same as a CLOS slot-specifier. In that case, the :INITARG
and :READER options must be explicitly specified if desired.
This syntax is compatible with the existing semantics of
DEFINE-CONDITION.
Rationale:
This provides maximal compatibilty with the old semantics
for DEFINE-CONDITION, which numerous vendors now distribute.
Further, and perhaps more importantly, the uses of slots in
DEFINE-CONDITION are highly constrained. They are not assigned
so an INITARG is nearly always needed. There are almost
universally accessed externally, so a :READER is usually
needed. This syntax makes what is by far the most convenient
use very syntactically simple.
Proposal (CLOS-CONDITIONS:YES-OPTION-B):
Incompatibly change the syntax of a slot in DEFINE-CONDITION
to be compatible with a DEFCLASS slot specification.
An implication of this change is that forms like
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR) ((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
Rationale: This is most compatible with CLOS.
Examples:
Slot specifiers...
Under YES-OPTION-A ...
A slot specifier of X in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X) in condition type FOO is still valid
and means the same as (X :INITARG :X :READER FOO-X).
A slot specifier of (X V) in condition type FOO is still
valid and means the same as
(X :INITARG :X :READER FOO-X :INITFORM V).
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Under YES-OPTION-B ...
A slot specifier of X is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X) is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X V) would no longer be valid.
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
would be rewritten
(DEFINE-CONDITION FOOBAR (FOO BAR)
((X :INITARG :X :READER FUBAR-X)
(Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ())
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
(ERROR 'OOPS)
>>Error: Oops! Something went wrong.
Rationale:
These changes are consistent with the intent of the recent
X3J13 endorsement of CLOS and the Common Lisp Condition System.
The shorthand notations for DEFINE-CONDITION's slots spec
are justified since the the way in which condition slots are
used is much more highly constrained than for arbitrary classes.
This means we can predict what will be the common case and make
it far more syntactically convenient than it might otherwise be.
Although flushing :CONC-NAME is an incompatible change, nothing
forbids an implementation from supporting it as an extension
during a transition period.
Current Practice:
Some implementations supporting CLOS probably already do this,
or something very similar.
Cost to Implementors:
If you really have CLOS, this is very straightforward.
Cost to Users:
Small, but tractable.
The main potential problems are:
- :CONC-NAME. There is nothing that keeps an implementation from
continuing to support :CONC-NAME for a short while until old code
has been upgraded.
- The incompatible change to slot syntax. Again, it is possible to
unambiguously recognize a 2-list as old-style syntax and an
implementation can provide interim compatibility support during
a transition period.
Even if implementations did not provide the recommended compatibility
support, users could trivially shadow DEFINE-CONDITION and provide the
support themselves, expanding into the native DEFINE-CONDITION in the
proper syntax.
Cost of Non-Adoption:
Conditions will seem harder to manipulate than other user-defined types.
People will wonder if CLOS is really something we're committed to.
Benefits:
A more regular language.
Aesthetics:
Anything that makes the language more regular improves the aesthetics.
Discussion:
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
Moon suggests that we might want to add condition types for the errors
CLOS might signal. It isn't obvious (to Pitman, at least) that this
change is as straightforward as it looks, though, so it will have to
come up under separate cover.
Richard Mlynarik suggests adding a generic function, REPORT-CONDITION,
which is used for reporting conditions. It is possible to discuss such
a generic function as a separate issue layered atop the substrate which
this proposal provides, so that issue has been deferred.
Pitman supports this change, with mild preference for YES-OPTION-A.
Gregor supports this change, with strong preference for YES-OPTION-B.
∂14-Oct-88 1427 X3J13-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Oct 88 14:26:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476697; Fri 14-Oct-88 17:26:16 EDT
Date: Fri, 14 Oct 88 17:26 EDT
From: CL-Cleanup@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
To: X3J13@SAIL.Stanford.EDU
Supersedes: <881009001850.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <881014172603.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: RANGE-OF-COUNT-KEYWORD
References: :COUNT (p247), REMOVE[-xxx] (p253), DELETE[-xxx] (p254),
[N]SUBSTITUTE[-xxx] (pp255-256)
Category: CLARIFICATION
Edit history: 21-Aug-88, Version 1 by Dave Touretzky
22-Aug-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is overly vague about legal values for the :COUNT keyword
parameters to builtin functions such as the sequence functions. It
says that the keyword ``limits the number of elements [affected]''.
Implementations have varied in their interpretation of this phrase,
however.
CLtL p247 specifies that if the :COUNT parameter to functions such
as REMOVE and DELETE ``is NIL or is not supplied, all matching items
are affected.'' Because of the placement of this requirement
outside of the description of the functions affected, some
implementations have overlooked this requirement and had to be
changed later.
CLtL doesn't say explicitly that the value of :COUNT must be an
integer, nor does it say what to do for negative values.
The fact that reasonable implementations disagree on some of the
details make this an obvious candidate for cleanup.
Proposal (RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER):
Clarify that for the functions
REMOVE REMOVE-IF REMOVE-IF-NOT
DELETE DELETE-IF DELETE-IF-NOT
SUBSTITUTE SUBSTITUTE-IF SUBSTITUTE-IF-NOT
NSUBSTITUTE NSUBSTITUTE-IF NSUBSTITUTE-IF-NOT
the following restrictions on the :COUNT keyword parameter exist:
* The value of this parameter must be NIL or an integer.
* Using a negative integer value is functionally equivalent to
using a value of zero.
Test Case:
#1: (REMOVE 'A '(A B A B) :COUNT 0) => (A B A B)
#2: (REMOVE 'A '(A B A B) :COUNT -3) => (A B A B)
#3: (REMOVE 'A '(A B A B) :COUNT NIL) => (B B)
#4: (REMOVE 'A '(A B A B) :COUNT 1.0) is an error.
#5: (REMOVE 'A '(A B A B) :COUNT 'FOO) is an error.
Rationale:
Disallowing non-integer numbers is probably the original intent and
is consistent with other functions such as NTH (p265) which accept
count-like arguments that are explicitly required to integers. This
restriction would presumably permit better optimizations in low-safety
mode on stock hardware.
Allowing NIL to be equivalent to no value allows a simplified flow
of control in some situations. For example, one can write
(DEFUN MYDEL (ITEM &OPTIONAL COUNT)
(DELETE ITEM *MYLIST* :COUNT COUNT))
where otherwise it might be necessary to write something like
(DEFUN MYDEL (ITEM &OPTIONAL (COUNT NIL COUNT-P))
(IF COUNT-P
(DELETE ITEM *MYLIST* :COUNT COUNT)
(DELETE ITEM *MYLIST*)))
Allowing negative numbers frees users from having to do an explicit
check for negative numbers when the value of :COUNT is computed by
some complicated expression. For example:
(DEFUN LEAVE-AT-MOST (N ITEM SEQUENCE &KEY (FROM-END T))
(REMOVE ITEM SEQUENCE
:COUNT (PRINT (- (COUNT ITEM SEQUENCE) N))
:FROM-END FROM-END))
(LEAVE-AT-MOST 2 #\A "BANANAS") ==> "BANANS"
(LEAVE-AT-MOST 2 #\S "BANANAS") ==> "BANANAS"
Current Practice:
[Note: Pitman didn't try these examples in KCL or CMU Common Lisp. He's
working from data in Touretzky's last draft of this proposal, so someone
from those camps might want to test the assertions made here.]
#1: All correct implementations presumably return (A B A B).
This value is consisent with this proposal.
#2: Symbolics Cloe returns (A B A B).
KCL returns (A B A B) for lists.
This value is forced by this proposal.
Symbolics Genera and CMU Common Lisp return (B B).
KCL does something bizarre for vectors (``pads with n blanks or
NILs, where -n is the value of the :count keyword parameter'',
says Touretzky.)
These implementations would have to change.
#3: All correct implementations presumably return (B B).
This value is consisent with this proposal.
Some implementations have been known to signal a wrong type
argument error in the past, but have presumably been fixed.
#4: Symbolics Genera and Symbolics Cloe return (B A B).
CMU Common Lisp returns (B B).
These behaviors are consistent with this proposal.
#5: Symbolics Cloe and Symbolics Genera signal an error.
CMU Common Lisp returns (A B A B).
These behaviors are consistent with this proposal.
Cost to Implementors:
Some implementations would have to change. These functions are typically
heavily optimized by compilers. Not only source code, but also compiler
optimizers and perhaps even microcode or hardware might have to be
modified to fully accomodate this change, so it might be quite expensive.
Cost to Users:
None for Common Lisp users. This change is an upward compatible
clarification of standard practice.
Cost of Non-Adoption:
The behavior of these functions when given degenerate keyword values would
be unintuitive. In many such cases, considerable additional user code must
be written to watch for and avoid creating such situations.
Benefits:
More compact, more intuitive, and more portable code.
Aesthetics:
This change improves language aesthetics.
Discussion:
In the past there has been some argument about what SUBSEQ should do when
given positions greater than the length of the sequence. Currently it
"is an error" to specify positions less than zero or greater than the
length of the sequence. Touretzky doesn't think the same should apply to
the :COUNT keyword. The inputs to SUBSEQ are ordinal numbers: they specify
positions, like array subscripts. The value of :COUNT is not an ordinal,
it is an upper bound on the size of the set of affected items (which is
a cardinal number).
Pitman supports this proposal. [Hopefully Touretzky supports it, too?]
van Roggen says he personally supports the stated proposal but that a
survey he did of users at DEC showed up a number of people who thought
that negative count arguments should be an error.
∂18-Oct-88 2146 CL-Cleanup-mailer DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88 21:46:16 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06569g; Tue, 18 Oct 88 21:46:10 PDT
Received: by bhopal id AA03592g; Tue, 18 Oct 88 21:44:37 PDT
Date: Tue, 18 Oct 88 21:44:37 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810190444.AA03592@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 8 Oct 88 22:07 PDT <881008-220711-2583@Xerox>
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
Several others have already expressed my sentiments towards this proposal --
that it would have been a nice idea five years ago, but is a gratuitous
incompatibility now. "Gratuitous", because lots of uses will have to
worry about whether or not their code needs to be massaged, and the
_payback_ to them will be insignificant.
It would certainly be acceptable to "deprecate" the use of any ...-IF-NOT
function, and of the :TEST-NOT keyword argument; this ought to be an
editorial discretion, rather than requireing lots of cl-cleanup time.
-- JonL --
∂25-Oct-88 0852 X3J13-mailer Proposed US Position Statement
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The following is my proposed US position statement for ISO:
*********************************************************************
The US is currently supporting two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Therefore, the US sees no need at this time
to standardize another dialect of Lisp for use within the US. It
follows that the primary activity of WG16 is not of major importance
within the US.
Nevertheless, it appears that WG16 is planning to provide a useful
standard for Europe. For this reason, WG16 is currently defining a
dialect of Lisp called ``ISLISP'' suitable for the needs of the European
community. The US is happy to aid that process.
Common Lisp and Scheme are beginning to enjoy widespread use not only
in the US but internationally. The charter for WG16 that was
determined at its first meeting in February 1988 allows for
standardization of multiple dialects of Lisp. Therefore, the US wishes
for WG16 to propose to ISO a standard for ISO Common Lisp, to be
called ``ISO Common Lisp.'' As ISLISP is aimed at satisfying certain
needs for a certain community, so ISO Common Lisp would be aimed at
satisfying the Common Lisp needs for a certain community. The US
wishes to reserve the right to request that WG16 propose to ISO a
standard for ISO Scheme.
By making this request, the US does not intend to impede or negate the
work of WG16 on ISLISP, just as we presume that the work of the
committee on ISLISP is not intended to impede or negate the work of
X3J13 on Common Lisp or of IEEE on Scheme in the US.
The community of Common Lisp users and implementors is international
in nature: Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). ANSI is not an
international standards organization, and so it is appropriate for
WG16 to propose a standard for ISO Common Lisp to ISO. Furthermore, it
is common for various US funding agencies to require projects to be
undertaken in ISO languages when they are available. Just as it would
be unfair for Common Lisp to be imposed by law in contexts where it is
not wanted, so it would be unfair for ISLISP to be imposed within the
US. For this reason, it is important for ISO to adopt Common Lisp as
an ISO standard language.
Common Lisp has been under design and specification for 8 years.
Commercial versions of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered. The key is in
implementation technology and not in language design. There are a
number of companies whose entire revenue depends on selling software
written in Common Lisp. The Defense Advanced Research Projects Agency
allows software to be written in Common Lisp (as well as Ada).
The US feels that the most interesting task for WG16 is towards a next
generation dialect of Lisp, combining the best aspects of Common Lisp,
Scheme, the Common Lisp Object System (now officially part of Common
Lisp), and other interesting (possibly parallel) dialects of Lisp.
The US believes that this task can begin once the needs of current
Lisp programmers and implementors is satisfied with ISO ISLISP and ISO
Common Lisp.
∂25-Oct-88 1405 X3J13-mailer Comments on Cleanup issues due within two weeks
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Oct 88 14:05:19 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 OCT 88 13:50:39 PDT
Date: 25 Oct 88 13:50 PDT
From: masinter.pa@Xerox.COM
Subject: Comments on Cleanup issues due within two weeks
To: X3J13@Sail.stanford.edu
reply-to: CL-Cleanup@sail.stanford.edu
Message-ID: <881025-135039-11718@Xerox>
As was discussed in the October X3J13 meeting, there will be a letter
ballot on the outstanding previously distributed cleanup issues. In order
for us to respond to your comments, we need to receive any comments on any
of the issues that were mailed electronically and distributed in hardcopy
within the next two weeks. If you feel that the cleanup proposals as
written adequately consider all of the possible alternatives, properly
address the costs and benefits of the proposal, we don't need to hear from
you. However, if there are considerations you believe are not reflected in
the writeup, please speak up. So far, we have heard from very few people.
I expect at the January meeting that there will be discussion of those
issues that we were unable to prepare for the October meeting, and there
will be some opportunity to discuss the items and the results of the letter
ballot, but I hope you will take the time, now, to consider the issues
already distributed.
You will do those of us who try to track cleanup mail a favor if you will
use a separate message for each Issue, with Subject: Issue: ISSUE-NAME
(Version number), addressed To: CL-Cleanup@sail.stanford.edu. Will will try
to ensure that all contributors are cc'd in subsequent discussion.
Thanks,
Larry Masinter
∂26-Oct-88 1925 X3J13-mailer Proposed US Position Statement
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88 19:25:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482712; Wed 26-Oct-88 22:25:20 EDT
Date: Wed, 26 Oct 88 22:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed US Position Statement
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: x3j13@SAIL.Stanford.EDU
In-Reply-To: <$7Wc0@SAIL.Stanford.EDU>
Message-ID: <19881027022508.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is fine with me, except for the part at the end suggesting that
the best place to do Lisp language research is in an ISO standards
committee. That seems like the worst place to me.
∂28-Oct-88 0347 X3J13-mailer mailing list update
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Oct 88 03:47:26 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22930; Fri, 28 Oct 88 03:47:05 PDT
Message-Id: <8810281047.AA22930@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Oct 88 06:44
To: x3j13@sail.stanford.edu
Subject: mailing list update
Please remove Ron Ohlander from x3j13.
∂01-Nov-88 1237 X3J13-mailer March meeting
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 88 12:35:25 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00995g; Tue, 1 Nov 88 12:34:40 PST
Received: by challenger id AA01605g; Tue, 1 Nov 88 12:30:50 PST
Date: Tue, 1 Nov 88 12:30:50 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8811012030.AA01605@challenger>
To: x3j13@sail.stanford.edu
Subject: March meeting
Bob Mathis will be hosting the March X3J13 and ISO meetings in the new Contel
facilities. Thank you Bob!
Please mark your calendars.
3/27 - 3/29 X3J13, Washington, D.C. area
3/30 - 3/31 ISO, Washington, D.C. area
---jan---
∂01-Nov-88 1245 X3J13-mailer March meeting
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 1 Nov 88 12:45:25 PST
Return-Path: <hadden@src.honeywell.com>
Received: from ella.SRC.Honeywell.COM
by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88)
id AA21106; Tue, 1 Nov 88 14:45:20 CST
Posted-Date: Tue, 1 Nov 88 14:43:47 CST
Received: by ella.src.honeywell.com (3.2/SMI-3.2)
id AA22306; Tue, 1 Nov 88 14:43:47 CST
Date: Tue, 1 Nov 88 14:43:47 CST
From: hadden@src.honeywell.com (George D. Hadden)
Message-Id: <8811012043.AA22306@ella.src.honeywell.com>
To: jlz@lucid.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Tue, 1 Nov 88 12:30:50 PST <8811012030.AA01605@challenger>
Subject: March meeting
oops, never mind about the dates.
-geo
∂02-Nov-88 0930 X3J13-mailer Hawaii hotel reservations reminder
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Nov 88 09:30:11 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00503g; Wed, 2 Nov 88 09:29:23 PST
Received: by challenger id AA03055g; Wed, 2 Nov 88 09:25:32 PST
Date: Wed, 2 Nov 88 09:25:32 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8811021725.AA03055@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii hotel reservations reminder
Please ask for Lizann when calling the Sheraton Coconut Grove 8:00 - 5:00
Monday - Friday. She is the one who can give you the special rate of
$80/night.
808/822-3455
---jan---
∂02-Nov-88 1612 X3J13-mailer Re: Proposed US Position Statement
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Nov 88 16:12:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 NOV 88 16:05:27 PST
Date: Wed, 2 Nov 88 16:05 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Proposed US Position Statement
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: x3j13@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <$7Wc0@SAIL.Stanford.EDU>
Message-ID: <19881103000503.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
We would like to comment on your proposed US position statement for ISO
WG16. We agree with much of what you say in your statement. Critically,
we agree that the U.S. must seek a change in the current ISO direction.
But we feel that your statement does not make sufficiently clear those
responsibilities which lead the X3J13 committee to this position. X3J13
is the committee we are most familiar with. We believe that the IEEE
group working standardization of Scheme may have similar concerns, but
we do not presume to speak for them.
The X3J13 effort is quite mature. We have almost finished the standard
we are chartered to develop. Most technical decisions have been made,
and the ones that remain to be made have already received significant
discussion and study. Editorial work to produce the standards document
is already well underway.
A number of individuals and companies have devoted significant time and
resources to creating the X3J13 Common Lisp standard. An even larger
number of individuals and companies have devoted resources to preparing
themselves to use this standard. The X3J13 committee has a significant
commitment to these individuals and companies; we must finish the
language we set out to create, and must follow through on our commitment
to making it an ANSI standard.
An important part of this commitment is that we cannot at this point
take any action which would diminish the value the standard we have
worked so hard to create. This responsibility constrains our options in
working with the ISO standardization effort. These constraints can be
complex and difficult to understand. This accounts in part for the time
it has taken the U.S. delegation to develop this position statement.
But one such constraint is now clear: The X3J13 committee cannot
endorse the development of an ISO standard which is as similar to Common
Lisp as ISLisp is currently. An ISO standard which is targeted that
close to the Common Lisp language being developed by X3J13, should be
exactly the same that being developed by X3J13.
The existence of a similar but separate ISO standard would significantly
weaken the ANSI Common Lisp standard. Problems would be caused by
policies that mandate the use of ISO standards over ANSI standards;
perhaps these problems could be resolved, but it would take time. It is
precisely to avoid those kinds of problems that our "constituency" has
chartered us to develop ANSI Common Lisp.
In addition, there would be widespread confusion among educators,
authors, application vendors and others about which Common Lisp was the
standard one. The technical leaders of the X3J13 effort would be
rightly criticized for not being committed to the language they created.
The United States is, however, part of the ISO Lisp standardization
process. As part of that process we must decide how to resolve the
obligations we are under to our X3J13 constituency with the obligations
that other delegations have to their constituencies. We would like to
try and do so in the most generous and equitable way possible. At this
point, it appears that the idea of multiple ISO standards is the best
solution.
One of these ISO standards would be the language currently being
specified by the X3J13 committee. This could be called ISO Common Lisp.
We would of course actively encourage additional cleanup proposals to
ensure that the language is in fact suitable for use as an international
standard. An important part of this is the commitment to working out
the character set proposal.
Other ISO standards could be developed for other specific purposes.
Those standards would have to be sufficiently different from ISO Common
Lisp that they would not diminish that standard. It might be possible
to develop a strict subset of ISO Common Lisp, but we do not believe it
is possible do so in a short timeframe.
We understand, and we believe the entire X3J13 committee understands,
that this position may be perceived as inflexible by certain other
members of the ISO committee. We would ask those members to consider
the commitment we have to the individuals and companies which have
plans to use X3J13 Common Lisp. We simply cannot take an action which
would compromise that commitment.
Daniel G. Bobrow
Scott Fahlman
Gregor Kiczales
Larry Masinter
-------
∂07-Nov-88 0639 X3J13-mailer Re: Proposed US Position Statement
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 7 Nov 88 06:38:55 PST
Date: 7 Nov 1988 09:37-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: Proposed US Position Statement
From: ROSENKING@A.ISI.EDU
To: Gregor.pa@XEROX.COM
Cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Nov-88 09:37:07.ROSENKING>
In-Reply-To: <19881103000503.4.GREGOR@PORTNOY.parc.xerox.com>
I wish to extend my support to the comments made by Bobrow et al, in
reference to Dick Gabriel's Proposed US Position Statement. I have
volunteered my time, effort and company's support to assist in
developing a Common Lisp standard. Each individuals participation in
X3J13 constitutes a major investment in Common Lisp. I agree that we
should protect our investment and thereby support this proposal.
Jeff Rosenking
∂07-Nov-88 1517 X3J13-mailer US Position Statement (Version 2)
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'd like to thank the following people for providing helpful comments
about my proposed US Position Statement:
Danny Bobrow, Kathy Chapman, Will Clinger, Linda DeMichiel, Patrick
Dussud, Scott Fahlman, Chris Haynes, Jim Kempf, Gregor Kiczales, Thom
Linden, Larry Masinter, Dave Moon, Kent Pitman, Guy Steele, and JonL
White.
As I've mentioned before, I am your representative, and my job is to
represent your position at the ISO meetings. The following the is current
(and I presume the final) position statement:
**************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although IsLisp will not
be of major importance within the US, the US supports the IsLisp
standardization effort as long as it does not negatively affect
standards for other dialects of Lisp. In particular, the US feels
that it is important not to have two standardized dialects of Lisp
that are nearly identical unless one is a strict subset of the other.
Having two such similar but different dialects weakens the position of
users who have come to depend on one of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies
thus depends on having a Common Lisp standard. Furthermore, it is
common for various US funding agencies to require projects to be
undertaken in ISO languages when they are available. Just as it would
be unfair for Common Lisp to be imposed by law in contexts where it is
not wanted, so it would be unfair for IsLisp to be imposed within the
US.
For these reasons, the US proposes that WG16 produce a draft standard
for ISO Common Lisp. As IsLisp is aimed at satisfying certain needs
for a specific community, so ISO Common Lisp would be aimed at
satisfying the Common Lisp needs for the international Common Lisp
community. The US wishes to reserve the right to request that WG16
produce a draft standard for ISO Scheme.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered: The key to
small applications lies more in implementation technology and the
environment than in language design. The near term standardization of
ISO Common Lisp would have substantial positive impact on the
acceptance of existing commercial Lisp implementations and of all
future Lisp dialects as vehicles for emerging applications.
The US believes that WG16 is the appropriate working group to
standardize Common Lisp. As determined at its first meeting, the
charter of WG16 endorses the standardization of multiple dialects of
Lisp. Therefore, WG16 can choose to produce draft standards for both
Common Lisp and IsLisp. It is not sufficient that there be only an
ANSI standard for Common Lisp because ANSI is not an international
standards organization.
The US feels that a draft standard for ISO Common Lisp could be
prepared by December 1989 with the assistance of X3J13. The US
proposes that WG16 request X3J13 to prepare the ISO draft standard for
Common Lisp. The ISO Common Lisp draft and the ANSI Common Lisp draft
should be identical.
Looking beyond Common Lisp, IsLisp, and Scheme, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons learned
from existing dialects of Lisp.
∂09-Nov-88 1137 X3J13-mailer Official US Position
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The following is the official US position statement, which was
hammered out by myself and the following people:
Danny Bobrow, Kathy Chapman, Will Clinger, Linda DeMichiel, Patrick
Dussud, Scott Fahlman, Chris Haynes, Jim Kempf, Gregor Kiczales, Thom
Linden, Larry Masinter, Dave Moon, Kent Pitman, Guy Steele, and JonL
White.
I'd like to especially thank Thom Linden and Gregor Kiczales with
whom I exchanged about 75 drafts over the last 24 hours.
*********************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. It
has been shown that small memory Common Lisp implementations are
possible and that small applications can be delivered: The key to
small applications lies more in implementation technology and the
environment than in language design. The near term standardization of
ISO Common Lisp would have substantial positive impact on the
acceptance of existing commercial Lisp implementations and on the
viability of future Lisp dialects as vehicles for emerging
applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
∂14-Nov-88 0804 X3J13-mailer Re: Hawaii hotel reservations reminder
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 14 Nov 88 08:03:52 PST
Full-Name: Jim Antonisse
Message-Id: <8811141546.AA14091@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: Jan Zubkoff <jlz@lucid.com>
Cc: x3j13@sail.stanford.edu, jima@mitre.arpa
Subject: Re: Hawaii hotel reservations reminder
In-Reply-To: Your message of Wed, 02 Nov 88 09:25:32 -0800.
<8811021725.AA03055@challenger>
Date: Mon, 14 Nov 88 10:46:00 EST
From: jima@mitre.arpa
Jan,
What is the registration fee for Hawaii, and to whom should
I make out the check. (Apologies if you've sent this info out
before, I recently - rather rashly, I guess - flushed my mail
log.)
The agenda hasn't taken shape already, has it?
Jim A.
∂14-Nov-88 1130 X3J13-mailer Ignore that message
Received: from mitre.arpa by SAIL.Stanford.EDU with TCP; 14 Nov 88 11:30:41 PST
Full-Name: Jim Antonisse
Message-Id: <8811141928.AA16983@mitre.arpa>
Organization: The MITRE Corp., Washington, D.C.
To: x3j13@sail.stanford.edu
Subject: Ignore that message
Date: Mon, 14 Nov 88 14:28:40 EST
From: jima@mitre.arpa
Well, "repl" was a just a bit more zealous than I expected
it to be. Sorry to {x3j13 - Jan} for the dose of mistargeted
mail - Jim A.
∂20-Nov-88 0359 X3J13-mailer Phase 1 standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Nov 88 03:59:10 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA25899; Sun, 20 Nov 88 03:58:33 PST
Message-Id: <8811201158.AA25899@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Nov 88 06:49
To: x3j13@sail.stanford.edu
Subject: Phase 1 standard
The source files for the phase 1 standard (complete as far as we know now)
are located on hudson.dec.com. The account name is FTP_USER and the password
is FTPPLEASEWORK.
Please let me know your specific needs if you intend to review this document.
The .dvi files will be available by Dec. 2. If you intend to use those, the
file names are chapter1.dvi...chapter6.dvi, and chapter6-1.dvi. The chapter 6
files are quite large.
If you want to build the document from the source files, you will need
TEX and TEX amfonts on your machine. To build the document, you invoke
TEX 7 times, each time with the file name chapterx, where
x=1,2,3,4,5,6,6-1.
Please let me know if you have any problems.
kathy chapman
∂29-Nov-88 1235 X3J13-mailer ISO Meeting Report
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Fellow Colleagues:
The following is my report on the November ISO meeting. I am sending
this now for several reasons. First, because it is fresh in my mind.
Second, because the events are a little more dramatic than usual.
Third, because one outcome was the cancellation of the January ISO
meeting in Hawaii.
The US Delegation consisted of Bob Mathis, Thom Linden, Patrick
Dussud, Gregor Kiczales, and myself. The meeting was held at the
Building of the European Community in Brussels, Belgium. It was held
Monday and Tuesday, November 21 and 22.
Attending were France, The Netherlands, Germany, Japan, the UK, and
the US.
The US presented its position statement, which is as follows:
************************************************************************
The US is currently undertaking two standardization efforts in Lisp:
X3J13 is standardizing Common Lisp for ANSI, and IEEE is standardizing
Scheme. The US believes that these two efforts cover a wide range of
concerns and uses for Lisp: Scheme is small, elegant, and
mathematically well-founded, and Common Lisp is full-featured, mature,
and commercially viable. Within the United States, there is no demand
for another Lisp standard at this time.
The current activity of WG16 is to develop a standard for a dialect of
Lisp directed at a community of users who are served neither by Common
Lisp nor by Scheme---that dialect is IsLisp. Although is is unlikely
that IsLisp will have major near term commercial significance within
the US, the US supports the IsLisp standardization effort as long as
it does not negatively affect standards for other dialects of Lisp.
In particular, the US feels that it is important not to have two
standardized dialects of Lisp that are nearly identical unless one is
a strict subset of the other. Having two such similar but different
dialects weakens the position of users who have come to depend on one
of the dialects.
The US believes that the primary focus of standardization is to codify
existing practice to support the creation and delivery of portable
software. Thus, the major focus of the US standardization efforts is
to provide stability to the community of Common Lisp and Scheme users.
Of secondary importance are the invention of new Lisp dialects and the
standardization of Lisp dialects or features not in common usage. The
US therefore agrees with the ISO goal of a near term standard in the
1990 time frame along with longer range consideration of future
dialects and features.
Common Lisp is in wide use in Europe, Japan, and Australia.
Implementations of Common Lisp are under way in the UK, Germany,
Italy, and Japan (and possibly other countries). In each of these
countries there are companies whose customers depend on portable
software written in Common Lisp. The future of these companies thus
depends on having a Common Lisp standard.
The US believes that Common Lisp is a valid candidate for
international standardization both because it is used internationally
and also because it is a mature and stable dialect. Common Lisp has
been under design and specification for 8 years. Commercial quality
implementations of Common Lisp have been available for 4 years. The
near term standardization of ISO Common Lisp would have substantial
positive impact on the acceptance of existing commercial Lisp
implementations and on the viability of future Lisp dialects as
vehicles for emerging applications.
For these reasons, the US proposes the development of an ISO standard
for Common Lisp. Furthermore, the US proposes that WG16 request X3J13
to prepare the ISO draft standard for Common Lisp. The ISO Common
Lisp draft and the ANSI Common Lisp draft should be identical. The US
believes such a draft standard could be developed by December 1989.
The US also believes the development of an ISO standard for Common
Lisp is within the charter of WG16, which endorses the standardization
of multiple dialects of Lisp. At some point in the future, it may be
appropriate to develop an ISO standard for Scheme.
Looking beyond near term standardization, the US feels that an
important task for WG16 is working towards a next generation dialect
of Lisp, and this can be accomplished by drawing on the lessons
learned from existing dialects of Lisp.
************************************************************************
In addition, we proposed the following resolution:
************************************************************************
The U.S. proposes the following ISO WG16 resolution:
It is important to affirm and strengthen the position of the
international community of users who depend on Common Lisp. It is
also imperative that an international standard for Common Lisp must be
subject to international review and revision.
ISO WG16 resolves to proceed with an ISO Common Lisp standardization
process in the following manner:
* WG16 requests X3J13 to produce an ISO draft standard for Common
Lisp in accordance with SC22 synchronization principles for national
body development.
* The X3J13 drafting procedure will accommodate international public
review as well as U.S. public review. X3J13 will establish a schedule
to allow processing of all public comments.
* The timetable for forwarding a draft for circulation by WG16 is
December 1989. The U.S. should make every effort to meet this
schedule.
* X3J13 will inform WG16 of its schedules and progress.
************************************************************************
The German Delegation also had a written position statement. It is as
follows:
************************************************************************
The Position of DIN concerning LISP standardization
Herbert Stoyan
University of Konstanz
November 18, 1988
1. Our Goals
When the LISP-standardization process started we were optimistic to reach a
quick result. Now we have to change our feeling. It will take longer than we
have imagined. To speed up the process we want to change some of our position
statements made in Paris.
First, we voted for CommonLISP as a starting point for standardization. We
want to change this commitment into an open one. We join the US that one of
Scheme or CommonLISP (but not both) should be used.
Second, we made a vote for desirable characteristics of the standard. We
regret that not all points went as we desired. But the issues seem to be
mixed: There are language issues and report issues.
Before all the points, we should all agree that standardization is only
partially a language definition activity. We should standardize an existing
language. Therefore we don't like anymore the list of default values for
language components. If we still intend to follow this direction we get
everything but a language which is usable. We don't feel that this was a good
idea. DIN will accept any proposal for a LISP standard and check every part
of it - not only functional objects etc.
Obviously, the goal of standardization is portability. Therefore this issue
deserves most attention. We got here the right mark. The next issue of
standardization seems to be processor conformity. We would like to change our
figure `6' into a `2'. We believe the conformity must be provable: Without a
proof procedure for conformity our work is not complete. Especially, there
has to be a test suite.
The standard report must be technical clear. Therefore a clear semantics is
important. It is the way to achieve portability. We ranked this topic with
`3' and support this vote again. The standard report has to be
understandable. An important means to achieve this is a simple semantics. We
miss understandability as characteristics and again want to stress our figure
`4' here.
A standard report has to be usable. That means, it should be well organized,
it should not be too voluminous, it should be use not too many references to
other parts. Maybe this was meant by `Ease of learning'. We believe that
this characteristic is only an indicator for this quality of the standard.
Therefore we want to change our figure of `12' into a `5'.
Now, concerning the language. A language to be standardized must be
interesting. That must be already - we cannot change it. May be this is what
was meant as `Power'. We want to rank this point at first place in the
language goals we have. Power does not mean to provide everything. A
language which is too large and complex has no power and will not be
appealing. History of programming languages proves that baroque languages
will not last for long. Therefore we want to vote for `Compactness' - but it
is not in the list of characteristics.
If a language is big only because of many concepts which enable variations of
expressions for one and the same thing then the language is defined badly. If
the language contains elements which cannot be combined it should be regarded
as a family of languages. Both dimensions are called orthogonality. We want
to vote for `Orthogonality' - but cannot find it.
There are characteristics of implementations. Issues like efficiency,
consistency interpreter/compiler, stability etc. come in mind. They are goals
for implementors. Good implementors will achieve them - bad implementors wil
fail. These are not goals of standardization.
Ease of implementation is a goal which is always fulfilled with LISP. The art
is to find a way to quality.
2. The Situation
Our original proposal was to standardize a kernel of LISP with parts everybody
will accept readily. This work could be done in 18 month. But there are not
many countries to support this approach.
Richard Gabriel made the point that three languages should not be
standardized. We adopt this position. We have to ask who moved us in the
position where this danger is to be faced. Obviously, it is the pair of
US-activities. It was clear to ANSI that CommonLISP is not ready for
standardization. A de-facto standard ist not a true standard. We want not
decide without studying the latest draft of CommonLISP if it achieved enough
quality. Furthermore, we have the feeling that the activity for standardizing
Scheme was started to contravene the European desire for a clean LISP kernel.
3. Our Proposal
ISO is not an organisation for creating new languages. The maximal thing we
should plan is to change a presented language somewhat. The French have
exposed the three level approach. There seems nobody (with exception of DIN)
who likes the idea.
Therefore: We propose to take the draft reports of CommonLISP and Scheme
and check them for quality of being standardized. If they both have the
quality, we should standardize both of them with ISO. If only one has
the quality we should take this one. If none of the has the quality we
should generate a list of required changes and wait for better drafts. In the
meantime other member bodies are invited to define LISPs which deserve
standardization.
************************************************************************
In summary, they commented that the current ISO process does not seem
to be converging on a standard quickly enough, and that a short-term
standard can produced only by working with an existing dialect and
draft. They proposed that drafts for X3J13 Common Lisp and IEEE Scheme
be considered and measured against several criteria. These are that
the draft be clear and unambiguous, not unacceptably long (< 300 pages
was suggested), and precisely stated. The languages ought to be as
crisp and orthogonal as possible (that is, minimal redundant
features). The German Delegation proper consisted of Klaus Daessler
(Siemens), Dieter Kolb (Siemens), and Herbert Stoyan (University of
Konstanz). Kolb favors Common Lisp and the other two favor Scheme, but
the German position allowed for both to be selected and standardized
by ISO.
No other delegation had a written position statement. The Japanese
Delegation consisted of Professor Ito and Mr Kurokawa. Professor Ito
is primarily concerned about CLOS, but after private discussions I
learned that because of lack of study he did not understand it, and
the expert group that advises him consists of object-oriented
programming researchers who press their own ideas on him.
The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
They responded by remarking that the US position represented a
``preposterous'' change in position by the US and directly
contradicted the agreed-upon work item. This work item was the AFNOR
(French) position which was to standardize a Common-Lisp-like dialect
with no packages, simple lambda-lists, simple arrays, generic
functions without classes, a different multiple value system, and a
different syntax for specials. The US argued that this plan was never
voted on because the convener would not allow it: He exaplined that
because it was a technical proposal, it was subject to discussion as
are all other technical points.
The US further remarked that the US position allowed for multiple
standardized dialects, but the convener denied this was possible under
the current work item and suggested we could try introducing a second
work item.
The French delegation contended that the US plan was to block the ISO
process. They were right in the limited sense that I threatened to
block the standardization of any dialect of Common Lisp that was
neither a superset nor a subset of Common Lisp.
I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant. Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''
As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
be available in the first half of 1989 (Beta available in December).
He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting).
The convener declared that discussion on this topic was deadlocked
until AFNOR could meet to decide their response to the US and German
position statements, which would not be until after the Hawaii
meeting. However, the convener told Mathis in private that he did not
want to go to Hawaii and was trying to find a way to cancel the
meeting. The convener also threatened to report failure to SC22 based
on his opinion that a consensus is not possible.
The US delegation agreed to ask X3J13 and the IEEE Scheme groups
whether they were willing to submit drafts under the German proposal.
While so agreeing, we pointed out that the convener was acting as if
the German position would be accepted. I pointed out that the US had
not withdrawn its proposed resolution.
The US delegation repeatedly commented that the US position was
intended to support Common Lisp users and was not intended to prevent
other distinct standards from being established to serve other
communities.
I expect that the word from AFNOR to the European community will be
that the US deliberately tried to block the ISO process, though I'm
not sure what reason he will provide for the US actions.
The second day of the meeting was devoted to three presentations:
Gabriel presented a report on the progress that US Common Lisp vendors
had made in the area of delivery of applications written in Common
Lisp. Mr Kurokawa presented a report on Japanese activity on
provisions within Common Lisp for international character sets. Thom
Linden presented the latest X3J13 work on the same topic. In
addition, the U.S. was asked to present the current WG16 status on
character handling at the next SC22 meeting.
The next ISO meeting is in March in Fairfax, Virginia.
-rpg-
∂02-Dec-88 2351 X3J13-mailer re: ISO meeting report
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 2 Dec 88 23:50:31 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA29272; Sat, 3 Dec 88 01:32:29 EST
Received: by mcvax.cwi.nl via EUnet; Sat, 3 Dec 88 07:05:56 +0100 (MET)
Received: by inria.inria.fr via Fnet-EUnet; Sat, 3 Dec 88 00:19:19 +0100 (MET)
Date: Sat, 3 Dec 88 00:19:19 +0100
From: mcvax!inria.inria.fr!chaillou@uunet.UU.NET (Jerome Chailloux)
Message-Id: <8812022319.AA10635@inria.inria.fr>
To: x3j13@sail.stanford.edu
Subject: re: ISO meeting report
Dear X3J13 members,
as an X3J13 Observer, I have several remarks on the Richard Gabriel's report
on the last WG16 meeting, held in Brussels the 21st and 22nd of November 88.
This report contains mistakes and doesn't reflect the many discussions
actually held during the meeting following the new ANSI position and the
DIN proposal. Please ask ANSI to distribute the official report of the
third meeting of WG16 to the members of X3J13.
But in addition of the incompleteness, there are some large mistakes in the
Mr Gabriel's report that I have to correct immediately:
1) the name of the standard
"I should point out that the French have formally asked SC22 (the
parent group of WG16) whether naming the resulting dialect ``IsLisp''
was allowed because the original work item stated that a standard for
``Lisp'' was being produced. The French commented that the US voted
``yes'' on the work item and that our comment about the name was
irrelevant."
False! This issue has been discussed at the first meeting at Paris. One
can read in the "Draft report of the 1st meeting of ISO/IEC JTC1/SC22/WG16
LISP," page 7 which is the official document WG16 Lisp N 12, which has been
approved at the second meeting at Snowbird:
"...
After several rounds of straw votes ISLISP was accepted.
The Secretariat was asked to let ISO Central Secretariat
in Geneva know such a change compared to the initial title
of the New Work Item.
..."
The AFNOR delegation has only asked if ISO in Geneva had given an answer.
2) ESPRIT
"Jerome Chailloux's company, ILOG, has a contract from
ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
we saw stated that the draft had been produced by ILOG in 1987 and was
available on request. However, to our knowledge, there is no ESPRIT
draft document of ``ISO Lisp''. All documents produced by AFNOR and
ILOG refer to ``ISO Lisp.''"
Wrong! and not discussed at all at the Brussels meeting which was obviously
not the right place to discuss that! ILOG has no Esprit contract to
produce a draft of ISO Lisp! If Mr Gabriel refers to the "Technical
Interest Group: Lisp" funded by the Esprit Program, please let him quote
the exact and complete description of this TIG (from the 1987 annual report
ISBN 92-825-8999-4). If you want to hear a fair explanation I would say:
Since 1986 the Esprit Program has funded a TIG, called "EuLisp", to
prepare the standardization of Lisp and to produce a draft to be proposed at
what is called now WG16. This TIG is funded on a per-person basis and has
nothing to do with companies (the majority of the participants are in fact
academic).
3) ESPRIT (again)
"As an aside, Chailloux pointed out that he oversees a lot of the
ESPRIT work on AI and that he would not allow any contractor to
use Common Lisp, only ISO Lisp."
Ridiculous! I am not in position to decide such policy. Please Mr Gabriel,
give the exact wording of the introductory speech of Mr Omnes (from the
EEC). He said that 30% of the Esprit II Program will use Lisp and that a
standard (preferably an ISO Standard) is warmly desired and that the
promotion of standards is in the charter of the Esprit Program.
4) ILOG Advertising
"ILOG advertizes that ISO Lisp will be available in the first
half of 1989 (Beta available in December)."
Can Mr Gabriel, give us the reference of the ILOG advertisement that he
refers to?
5) Next EuLisp Meeting
"He told Dussud that he would ``have the Germans back in line by
December 15'' (which is the next EuLisp meeting)."
Again, this is wrong! At the next EuLisp meeting in December, the different
representatives of the european national organisation of standardisation
will try to have a common position in regard with the work done at WG16
because, despite the fact than some members of ANSI claim the contrary, it
seems to many that the new ANSI position will give a significant change of
direction of the work of WG16. This "radical" change has to be
discussed at different member bodies and then at the EuLisp meeting,
which seems reasonable at an International Working Group.
Jerome Chailloux
AFNOR representative at ISO WG16.
∂05-Dec-88 1209 X3J13-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:06:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 11:45:41 PST
Date: 5 Dec 88 11:45 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
from: CL-Cleanup@Sail.Stanford.edu
REPLY-TO: cl-cleanup@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <881205-114541-3846@Xerox>
This is the first of a number of issues for which we have prepared
new versions since the October meeting. There will be a hardcopy
mailing of issues and a ballot; details in a separate message later.
Ballot issues will also be available for anonymous FTP from host
arisia.xerox.com in the directory clcleanup/pending.
As usual, if you have any comments, questions, please respond
to CL-CLEANUP@Sail.stanford.edu rather than to the entire
X3J13 list.
!
Forum: Cleanup
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
Functions: TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers:
ARRAY, SIMPLE-ARRAY, VECTOR, SIMPLE-VECTOR
COMPLEX
Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes)
Version 8, 8-Oct-88, Masinter (wording, discussion)
Version 9, 31-Oct-88, JonL (major re-wording to accommodate
recent discussion; esp. re-introduce and clarify "upgrading")
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination"; see CLtL, section 4.5 "Type
Specifiers That Specialize" (p.45 and following) The phrase
"for declaration" encompasses type-specifiers passed in as the
:element-type argument to MAKE-ARRAY, passed in as the <result-type>
argument to COERCE, and used in THE and DECLARE type declarations. The
phrase "for discrimination" refers to the type-specifiers passed in as
the <type> argument(s) to TYPEP and SUBTYPEP.
One consequence of this distinction is that a variable declared to be of
type <certain-type>, and all of whose assigned objects are created in
accordance with that type, may still have none of its values ever satisfy
the TYPEP predicate with that type-specifier. One type-specifier with
this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
This is entirely permissible within the scope of standardization on
MAKE-ARRAY, where an implementation is required only to construct up the
result out of "the most specialized [element] type that can nevertheless
accommodate elements of the given type [the :element-type argument]"
(see CLtL, p287). That is, an implementation may in fact only provide a
very small number of equivalence classes of element-types for storing
arrays, corresponding to its repertoire of specialized storage techniques;
and it is explicitly permitted to "upgrade" any element-type request into
one of its built-in repertoire (see also CLtL, p45, second and third
paragraphs under Section 4.5.)
As a practical matter, almost every existing implementation does some
serious upgrading of the :element-type argument given to MAKE-ARRAY.
Yet the difference between "for declaration" and "for discrimination"
has been very confusing to many people. Similarly, portability is
hindered when users do not know just how a given implementation does
upgrading.
The type specifier (COMPLEX <part-type>) also falls in the domain of CLtL
Section 4.5. Currently, only one implementation actually provides any kind
of specialized storage for complex parts; and in this case, the practical
matter is less urgent, since the kind of upgrading happening is so obvious
as to cause little or no confusion.
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Short Summary:
** Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". In short, change the meaning of array and
complex type specifiers in favor of the "for declaration" meaning.
** Change the meaning of TYPEP to be in accord with "for declaration"
meaning of type-specifiers.
** Add an implementation-dependent function that reveals how a given
type-specifier for array element-types is upgraded. Add another such
function that reveals how a given type-specifier for complex parts is
upgraded.
** Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice; i.e., if <type> upgrades to <Type>, then
<Type> must be a super-type of <type>.
** Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
etc.
** Clarify how SUBTYPEP thus behaves on array type-specifiers.
** Define how SUBTYPEP behaves on complex type-specifiers.
Note that despite this issue's name, the detailed specifications herein
apply to the type system -- not to the behavior of MAKE-ARRAY, nor to how
arrays are actually implemented.
Details:
First, some definitions: Two type-specifiers <type1> and <type2> are said
to be "type-equivalent" if and only if each one specifies a subtype of the
other one. For example, (UNSIGNED-BYTE 5) and (MOD 32) are two different
type- specifiers that always refer to the same sets of things; hence they
are type-equivalent. But (UNSIGNED-BYTE 5) and (SIGNED-BYTE 8) are not
type- equivalent since the former refers to a proper subset of the latter.
Two type-specifiers <type1> and <type2> are said to be "type-disjoint"
if their specified intersection is null. For example, INTEGER and FLOAT
are type disjoint by definition (see CLtL p.33), and (INTEGER 3 5) and
(INTEGER 7 10) are type-disjoint because the specified ranges have no
elements in common.
*. Eliminate the distinction between types "for declaration" and "for
discrimination". In particular, elminate any such reference in the
discussion of array and complex type-specifiers; this would include
documentation patterned after the discussion in section 4.5, pp. 45-7,
especially the example on p.46 that says "See ARRAY-ELEMENT-TYPE".
Change the meaning of (ARRAY <element-type>), as well as any of the
subtypes of ARRAY (such as SIMPLE-ARRAY, VECTOR, etc.) in favor of the
"for declaration" meaning. Make the similar simplification for the
<part-type> specifiers in the COMPLEX type-specifier.
*. Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result
of giving <type> as the :element-type argument to MAKE-ARRAY. While
(ARRAY *) refers to all arrays regardless of element type, (ARRAY <type>)
refers only to those arrays that can result from giving <type> as the
:element-type argument to the function MAKE-ARRAY. Change the meanings
for (SIMPLE-ARRAY <type>) and (VECTOR <type>) in the same way.
Change the meaning of (TYPEP <x> '(COMPLEX <type>)) similarly. Thus,
(COMPLEX <type>) refers to all complex numbers that can result from
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation. Remember that
both the real and the imaginary parts of any such complex number must
satisfy:
(TYPEP <real-or-imag-part> '<type>).
*. Add the function UPGRADED-ARRAY-ELEMENT-TYPE of one argument, which
returns the element type of the most specialized array representation
capable of holding items of the given argument type. Note that except
for storage allocation consequences, it could be defined as:
(DEFUN UPGRADED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
Since element-type upgrading is a fundamental operation implicit in
almost every existing implementation of MAKE-ARRAY, the purpose of this
added function is primarily to reveal how an implementation does its
upgrading.
Add the function UPGRADED-COMPLEX-PART-TYPE of one argument that
returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
*. Clarify that "upgrading" implies a movement upwards in the type-
hierarchy lattice. Specifically, the type-specifier <type> must be
a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE '<type>). Furthermore, if
<type1> is a subtype of <type2>, then:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)
must also be a subtype of:
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>).
Note however, that two type-disjoint types can in fact be upgraded into
the same thing.
Clarify that ARRAY-ELEMENT-TYPE returns the upgraded element type
for the array; in particular, any documentation patterned after
the sentence on p. 291 begining "This set may be larger than the
set requested when the array was created; for example . . ." should
be embellished with this clarification.
Similarly, the type-specifier <type> must be a subtype of
(UPGRADED-COMPLEX-PART-TYPE <type>).
*. Clarify that upgrading an array element-type is independent of any
other property of arrays, such as rank, adjustability, fill-pointers,
displacement etc. For all such properties other than rank this should
be obvious (since they are not expressible in the language of
type-specifiers); but note that unless it is also independent of rank,
it would not be consistently possible to displace arrays to those of
differing rank.
*. Clarify that SUBTYPEP on ARRAY type-specifiers is as follows:
For all type-specifiers <type1> and <type2> other than *, require
(ARRAY <type1>) and (ARRAY <type2>) to be type-equivalent if and only
if they refer to arrays of exactly the same specialized representation;
and require them to be type-disjoint if and only if they refer to arrays
of different, distinct specialized representations. This definition
follows that implicitly prescribed in CLtL.
As a consequence of the preceding change to TYPEP and of the definition
of UPGRADED-ARRAY-ELEMENT-TYPE, the two type specifiers
(ARRAY <type1>) and
(ARRAY <type2>)
are type-equivalent if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent. This is another way of saying that `(ARRAY <type>)
and `(ARRAY ,(UPGRADED-ARRAY-ELEMENT-TYPE '<type>)) refer to the same
set of specialized array representations.
This defines the behavior of SUBTYPEP on array type-specifiers; namely:
(SUBTYPEP '(ARRAY <type1>) '(ARRAY <type2>))
is true if and only if
(UPGRADED-ARRAY-ELEMENT-TYPE '<type1>) and
(UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
are type-equivalent.
*. Define SUBTYPEP on COMPLEX type-specifiers as follows:
For all type-specifiers <type1> and <type2> other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>))
is T T if:
1. <type1> is a subtype of <type2>, or
2. (UPGRADED-COMPLEX-PART-TYPE '<type1>) is type-equivalent
to (UPGRADED-COMPLEX-PART-TYPE '<type2>); in this case,
(COMPLEX <type1>) and (COMPLEX <type2>) both refer to the
same specialized representation.
The result is NIL T otherwise.
The small differences between the SUBTYPEP specification for ARRAY and
for COMPLEX are necessary because there is no creation function for
complexes which allows one to specify the resultant part type independently
of the actual types of the parts. Thus in the case of COMPLEX, we must
refer to the actual type of the parts, although a number can be a member
of more than one type; e.g., 17 is of type (MOD 18) as well as of type
(MOD 256); and 2.3f5 is of type SINGLE-FLOAT was well as FLOAT.
The form:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
must be true in all implementations; but:
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is true only in implementations that do not have a specialized array
representation for single-floats distinct from that for other floats.
Examples:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
Current Practice:
Every vendor's implementation that the proposer has queried has a finite
set of specialized array representations, such that two non-equivalent
element types can be found that use the same specialized array
representation; this includes Lucid, Vaxlisp, Symbolics, TI, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other implementations fail it.
The Explorer returns NIL for all six tests in [A], [B], and [C].
Allegedly, the PCLS implementation does no "upgrading"; each array
"remembers" exactly the type-specifier handed to the MAKE-ARRAY call
that created it. Thus the test cases are not applicable to PCLS,
since the precondition cannot be met (i.e., find two non-type-equivalent
type-specifiers that are non-trivially upgraded by make-array).
The TI Explorer offers specialized representation for complexes;
part types of SINGLE-FLOAT and DOUBLE-FLOAT are specialized.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of TYPEP and SUBTYPEP.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about MAKE-ARRAY
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type
(ARRAY <type>) has been very confusing to almost everyone.
Portability of applications will be increased slightly, since
the behavior of
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
will no longer be implementation-dependent.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
This issue was prompted by a lengthy discussion on the Common Lisp
mailing list. See for example a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". See also the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"
Although the types STRING, BIT-VECTOR, SIMPLE-STRING, and
SIMPLE-BIT-VECTOR are subtypes of the ARRAY type, they are not
specifically discussed in this proposal. The reason is that
they are not type-specifiers "that specialize", but are merely
abbreviations as follows:
STRING == (VECTOR STRING-CHAR)
SIMPLE-STRING == (SIMPLE-ARRAY STRING-CHAR (*))
BIT-VECTOR == (VECTOR BIT)
SIMPLE-BIT-VECTOR == (SIMPLE-ARRAY BIT (*))
Thus their semantics could be affected only in an implementation that
doesn't support a specific "specialized storage" type for arrays of
bits and vectors of string-chars. But in fact, every CL implementation
must appear to support "specialized storage" for bit-arrays and strings,
even if it means nothing more than remembering the fact that such an
array was created with that element-type. This is required in order
for strings, bit-vectors, and bit-arrays to be disjoint datatypes
(see CLtL p.34; see also the definitions of BIT-ARRAY and STRING found
in CLtL p.293, Section 17.4, and in CLtL p.299.)
We considered the possibility of flushing the permission to "upgrade";
for example, it could be made a requirement that:
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY <n> :ELEMENT-TYPE <type>))
always be equal to <type> (or, at least type-equivalent to <type>)
for all valid type specifiers <type>. This has several problems: it
increases the storage requirement for many kinds of arrays, and hides
a relevant part of the underlying implementation for no apparently
good reason. However, it would increase portability, since it would be
much more difficult, for example, to write a program that created an
array with one element-type, say, (UNSIGNED-BYTE 5), but operated on it
assuming a non-trivial upgraded element-type, say, (UNSIGNED-BYTE 8).
Under this proposal, it is valid for an implementation of MAKE-ARRAY
to have arrays "remember" the type-equivalence class of the original
:element-type argument; such an implementation would satisfy all of
the constraints listed above.
We considered a suggestion to restrict the set of "known" array element
types; this would gain portability at the expense of limiting the
language.
We considered leaving out of the proposal the addition of the two
functions UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE.
But it was noted that every implementation of CL supports exactly
that functionality somewhere in its implementation of MAKE-ARRAY; and
exposing this to the user would be a good thing. Furthermore, the
existence of at least UPGRADED-ARRAY-ELEMENT-TYPE makes the clarifications
on "upgrading" and SUBTYPEP implications easier. Finally, there would
be no other way at all to pinpoint just how complex parts are upgraded,
since there is no type information available except for the actual
types of the parts.
Since this proposal contains the implication:
(ARRAY <type1>) is-type-equivalent-to (ARRAY <type2>)
==>
<type1> is-type-equivalent-to <type2>
then the question naturally arises "Does the reverse implication hold?"
That is, should two non-EQ but type-equivalent type-specifiers <type1>
and <type2> always give rise to the same array types? For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (see CLtL section 2.1.3). One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently. Say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words; but for either kind of packing, the result of
AREF is an ordinary "single-float". The whole point of the type-specifier
to make-array is merely to specify a packing technique for "packed float"
arrays. This "krinkle", however, will not be addressed by the proposal
herein; it should simply be remembered that the implication above goes
only one way, and is not an "if-and-only-if" link.
∂05-Dec-88 1238 X3J13-mailer Another Report on ISO/WG16
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:37:53 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA18474; Mon, 5 Dec 88 15:36:53 EST
Received: by mcvax.cwi.nl via EUnet; Mon, 5 Dec 88 18:44:17 +0100 (MET)
Received: by inria.inria.fr via Fnet-EUnet; Mon, 5 Dec 88 14:39:02 +0100 (MET)
Date: Mon, 5 Dec 88 12:03:36 -0100
From: mcvax!poly!queinnec@uunet.UU.NET (Queinnec Christian)
Message-Id: <8812051103.AA26857@poly.poly.fr>
To: rpg@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
Subject: Another Report on ISO/WG16
I just received your *personal* report on the last ISO meeting,
you sent to x3j13, and want to make some remarks to it. First, you
have the right to write anything you want, but the incriminated people
have also the right to try to present their own perception. You mix up
official stuff with personal or private thoughts aiming, in my own
point of view, to confusion. I will then try to fix, as the convenor
of the WG16, some of the points you made.
> The French Delegation consisted of Jerome Chailloux and Greg Nuyens.
> They responded by remarking that the US position represented a
> ``preposterous'' change in position by the US and directly
> contradicted the agreed-upon work item. This work item was the AFNOR...
No! The New Work Item was the result of an international agreement
which still remains unaltered.
> ... (French) position which was to standardize a Common-Lisp-like dialect
> with no packages, simple lambda-lists, simple arrays, generic
> functions without classes, a different multiple value system, and a
> different syntax for specials.
This list of technical points was decided in Paris Meeting as a way to
proceed to standardize IsLisp on the basis of CLtL as already improved
by X3J13. As every technical point in the agenda, it can be discussed
at length or even reassessed (as in Snowbird).
> The US argued that this plan was never
> voted on because the convener would not allow it: He exaplined that
> because it was a technical proposal, it was subject to discussion as
> are all other technical points.
See above.
> The US further remarked that the US position allowed for multiple
> standardized dialects, but the convener denied this was possible under
> the current work item and suggested we could try introducing a second
> work item.
I continue to interpret the NWI as a chart to standardize only one
element of the Lisp family.
> The French delegation contended that the US plan was to block the ISO
> process. They were right in the limited sense that I threatened to
> block the standardization of any dialect of Common Lisp that was
> neither a superset nor a subset of Common Lisp.
> I should point out that the French have formally asked SC22 (the
> parent group of WG16) whether naming the resulting dialect ``IsLisp''
> was allowed because the original work item stated that a standard for
> ``Lisp'' was being produced. The French commented that the US voted
> ``yes'' on the work item and that our comment about the name was
> irrelevant.
The US comment (like any other comment) is not irrelevant. But since it
would be the first time that a language would be standardized under a
precise name and not its proper name, this proposal as well as the
name voted in the WG were submitted, not to SC22, but to ISO in Geneva.
> Jerome Chailloux's company, ILOG, has a contract from
> ESPRIT to produce a draft of ``ISO Lisp.'' In fact, an ESPRIT catalog
> we saw stated that the draft had been produced by ILOG in 1987 and was
> available on request. However, to our knowledge, there is no ESPRIT
> draft document of ``ISO Lisp''. All documents produced by AFNOR and
> ILOG refer to ``ISO Lisp.''
In the AFNOR documents as well as in the BSI documents, the `Lisp'
to be standardized in the WG is nicknamed 'ISO Lisp'. Until a formal
agreement by ISO of the name IsLisp, this one is sufficiently clear
as were ISO Pascal, ANSI C...
> As an aside, Chailloux pointed out that he oversees a lot of the
> ESPRIT work on AI and that he would not allow any contractor to
> use Common Lisp, only ISO Lisp. ILOG advertizes that ISO Lisp will
> be available in the first half of 1989 (Beta available in December).
> He told Dussud that he would ``have the Germans back in line by
> December 15'' (which is the next EuLisp meeting).
Is this a personal thought of Mr Richard P. Gabriel about Mr Jerome Chailloux ?
> The convener declared that discussion on this topic was deadlocked
> until AFNOR...
and BSI and Netherlands and other countries not present. I recall that
the precise topic debated here is related to the answer of the WG to
the proposed US resolution.
>... could meet to decide their response to the US and German
> position statements, which would not be until after the Hawaii
> meeting. However, the convener told Mathis in private that he did not
> want to go to Hawaii and was trying to find a way to cancel the
> meeting.
It probably would have been the case that I cannot attend the Hawaii
meeting (due to lack of funds) but this is not a reason to cancel
it: first, the secretary would have been there and second, I can
mandate someone to represent me at this precise meeting as currently
done in other WGs.
> The convener also threatened to report failure to SC22 based
> on his opinion that a consensus is not possible.
I was mandated by SC22 to lead the standardization work. In case of
failure i.e, if I fail to reach a consensus, I naturally have to
report it to SC22.
> The US delegation agreed to ask X3J13 and the IEEE Scheme groups
> whether they were willing to submit drafts under the German proposal.
> While so agreeing, we pointed out that the convener was acting as if
> the German position would be accepted. I pointed out that the US had
> not withdrawn its proposed resolution.
It is true that everybody acts as if the German point of view was the
main topic to be discussed. I guess it is a consensus ...
C.Queinnec
Convenor of the WG16.
∂05-Dec-88 1249 X3J13-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 12:48:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 DEC 88 12:25:45 PST
Date: 5 Dec 88 12:25 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 4)
To: X3J13@sail.stanford.edu
From: CL-CLEANUP@Sail.Stanford.Edu
Reply-to: CL-CLEANUP@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Line-fold: NO
Message-ID: <881205-122545-3938@Xerox>
Some parts of the original issue were separated out as we have
not yet arrived at a recommendation.
!
Forum: Cleanup
Issue: CLOSED-STREAM-OPERATIONS
References: CLOSE (CLtL p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
8-Oct-88, Version 2 by Masinter
13-Oct-88, Version 3 by van Roggen
1-Dec-88, Version 4 by Pitman
5-Dec-88, Version 5 by Masinter (separate other issues)
Related Issues: STREAM-ACCESS, STREAM-INFO, INPUT-STREAM-P-CLOSED,
CLOSE-CONSTRUCTED-STREAMS, PATHNAME-STREAM
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
``The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ...''
but the list of inquiry operations is not specified.
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
Clarify the behavior of the following functions on closed streams:
* STREAMP is unaffected by whether its stream argument is open or closed.
* If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed without error but the return value is not specified.
* PATHNAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it would in principle be possible for PATHNAME in
some implementations to return more specific information after the
stream is closed. For consistency, however, PATHNAME is prohibited
from doing this. PATHNAME must return the same pathname after a
file is closed as it did before. (The passed proposal in issue
PATHNAME-STREAM still stands.)
* TRUENAME is valid on either an open or closed stream. Since some
implementations cannot provide the truename of a file until the
file is closed, it is permissible TRUENAME to return more specific
information after the stream is closed.
* MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING,
FILE-NAMESTRING, DIRECTORY-NAMESTRING, HOST-NAMESTRING,
ENOUGH-NAMESTRING, and OPEN are valid on either open or closed streams.
For any of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
* PROBE-FILE and DIRECTORY are valid on either open or closed streams.
For either of these operations, using a stream, S, as an argument
where appropriate is equivalent to using (PATHNAME s). See the
description of PATHNAME above to understand the consequences of this.
In this case of these operators however, closed stream may well be the
most reliable arguments in some cases, since treatment of open streams
to the file system may vary considerably between implementations.
For example, in some operating systems, open files are written under
temporary names and not renamed until close and/or are held invisible
until a close is performed. In general, any code with an intent to be
highly portable should tread lightly when using PROBE-FILE or
DIRECTORY.
Rationale:
One can consider many characteristics of a stream to be independent of
the ability to do I/O. Being able to determine a stream's direction and
its name is often useful for debugging. A number of the descriptions in
CLtL imply (weakly) the ability to work on closed streams. Functions
such as OPEN and DIRECTORY don't really depend on the stream, but on
the name of the stream.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Cost to Implementors:
Unknown, but likely to be small in most implementations.
A nontrivial amount of work may be necessary if the pathname information
is held externally and is normally deleted when the stream is closed.
The implementation will have to copy the information at some time for later
inquiries.
Cost to Users:
Likely to be small; users of an implementation forced to change
by this proposal might have to make some modifications to make their
programs portable.
Benefits:
These clarifications will assist users in writing portable code.
Aesthetics:
Most people will probably see these clarifications as an improvement
in aesthetics.
Discussion:
There are some separate, but related, issues regarding what CLOSE
should do on composite streams or constructed streams such as
created by MAKE-BROADCAST-STREAM. These issues will be addressed
in a separate issue (CLOSE-CONSTRUCTED-STREAMS).
There was some discussion on whether INPUT-STREAM-P and OUTPUT-STREAM-P
should return "false" on a stream that had been closed. The issue
STREAM-ACCESS contains a proposal to add a function OPEN-STREAM-P
which might be useful for the same purpose. This issue was separated
out into a separate issue (INPUT-STREAM-P-CLOSED).
The other functions in proposal STREAM-ACCESS:PROVIDE should
work on closed streams.
The functions in STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS should
not be requred to work on closed streams.
∂05-Dec-88 1531 X3J13-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 15:30:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 15:25:23 PST
Date: 5 Dec 88 15:25 PST
Sender: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
From: CL-CLEANUP@Sail.stanford.edu
REPLY-TO: CL-CLEANUP@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
cc: masinter.pa@Xerox.COM
Message-ID: <881205-152523-4432@Xerox>
!
Forum: Cleanup
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Issue FUNCTION-TYPE (passed X3J13/June 1988)
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
#3, 30-Sep-88, Masinter
#4, 5-Dec-88, Masinter (append Oct x3j13 comments)
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
Using the same declaration for two completely different purposes can lead
to confusion among people writing or reading such code.
It is now more useful to declare that variables have a value which
is of type FUNCTION, since the type FUNCTION has a more well-specified
meaning.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
Many current implementations treat FUNCTION declarations
only as abbreviations for FTYPE declarations, primarily because
the proposal FUNCTION-TYPE has not been widely implemented.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods.
Since all cases can be disambiguated after all, compatibility considerations
might deem this proposal to be unnecessary. However, making declarations
simpler and less confusing is possibly more important than compatibility.
There is no consensus on the cleanup committee.
Comments from October 1988 X3J13 meeting:
... opposed but not vehemently--the incompatible change is gratuitous
... prefer to document the
issue rather than change it."
... a number of implementations accidentally implement
this incorrectly. They first check the type table and then handle
the elaborate function declaration style. But, as it happens,
they never reach the code for the second case because function is
in the type table!
... Having both styles is worse than having either one or the other.
∂05-Dec-88 1641 X3J13-mailer Issue: DEFPACKAGE (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Dec 88 16:41:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 16:39:43 PST
Date: 5 Dec 88 16:39 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFPACKAGE (Version 7)
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <881205-163943-4628@Xerox>
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Issue: MAKE-PACKAGE-USE-DEFAULT
Issue: PACKAGE-DELETION
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Version 5, 6-Oct-88, Moon
Version 6, 6-Oct-88, JonL (little nits)
Version 7, 2-Nov-88, JonL
(incorporate further discussion; simplify handling of
syntactic errors; specify ordering constraints).
Problem description:
Many users incorrectly think that package operations can be performed
in any order. CLtL (p.192) contributes to this misconception.
Programmers need direction on the ordering constraint, especially for
creating packages, since doing things out of order can lead to
confusing or even intractable problems.
If the definition of a package is scattered throughout a program as a
number of individual forms, it is very easy to read a symbol before the
package setup needed to read that symbol correctly has been accomplished.
Three examples: an inherited symbol that should have been shadowed might
be accessed; a single-colon prefix might be used for a symbol that hasn't
yet been exported; an internal symbol might be created afresh where a
symbol that will later be imported or inherited was intended. These
problems can be difficult to understand or even to recognize; in some
cases it is difficult or impossible to correct the situation in the
same Lisp image.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a
symbol, only its name matters, not what package it is in.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below. Except for :SIZE,
options may appear more than once (this is useful primarily for
:IMPORT-FROM and :SHADOWING-IMPORT-FROM).
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
The package is to "use" the other designated packages; that is,
it will inherit from them. The default value for this option
should be the same as it is for MAKE-PACKAGE (also see the issue
MAKE-PACKAGE-USE-DEFAULT).
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined,
making them shadows, just as the function SHADOW would do.
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package, import
them into the package being defined, and place them on the
shadowing symbols list. In no case will symbols be created in
any package other than the one being defined; a continuable error
is signaled if no symbol is accessible in the package named
package-name for one of the symbol-names.
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined. In no case will symbols be
created in a package other than the one being defined; a continuable
error is signaled if no symbol is accessible in the package named
package-name for one of the symbol-names.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since inherited symbols
can be used rather than new ones created; note also an interaction
with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since
imported symbols can be used rather than new ones created.
(:INTERN {symbol-name}*)
Find or create symbols with the specified names. Note an
interaction with the :USE option, since inherited symbols
can be used rather than new ones created. This option is useful if
an :IMPORT-FROM or a :SHADOWING-IMPORT-FROM option in a subsequent
call to DEFPACKAGE (for some other package) expects to find these
symbols accessible but not necessarily external.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package).
The order in which the options occur in a DEFPACKAGE form is irrelevant;
but since the effects of the entry-making options are context-sensitive,
the order in which they will be executed is as follows:
(1) :SHADOW and :SHADOWING-IMPORT-FROM
(2) :USE
(3) :IMPORT-FROM and :INTERN
(4) :EXPORT
Shadows are established first, since they may be necessary to block
spurious name conflicts when the use link is established. Use links are
established next so that :intern and :export may refer to normally
inherited symbols. The :export is done last so that it may refer to
symbols created by any of the other options; in particular, shadows and
imported symbols can be made external. Note also the prescription on CLtL
p.178 to cover the case of calling EXPORT on an inherited symbol.
DEFPACKAGE creates the package as specified and returns it as its value.
It has no other side effects; e.g., it does not alter the value of *PACKAGE*.
The function COMPILE-FILE should treat top-level DEFPACKAGE forms the
same way it treats the other package-effecting functions (see CLtL p.182).
If the specified name already refers to an existing package, then the
name-to-package mapping for that name is not changed. At most, the
existing package will be modified to reflect the new definition; it is
undefined what happens if the new definition is at variance with the
current state of that package. If one of the specified nicknames already
refers to an existing package, then an error is signaled just the same
as MAKE-PACKAGE would. See the issue PACKAGE-DELETION for undoing the
name-to-package mapping.
Some DEFPACKAGE errors are, however, purely syntactic.
(1) An error should be signaled if :SIZE appears than once.
(2) Since extended options might be allowed by other implementations,
an error should be signaled if an option is present that is not
actually supported in this implementation.
(3) The collection of symbol-name arguments given to the options
:SHADOW, :INTERN, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must
all be disjoint; additionally, the symbol-name arguments given to
:EXPORT and :INTERN must be disjoint. If either condition is
violated, an error should be signaled.
Name conflict errors will, of course, be handled by the underlying calls to
USE-PACKAGE, IMPORT, and EXPORT.
Examples:
;;; An example that "plays it super-safe" by using only strings as names;
;;; does not even assume that the package it is read in to "uses" LISP;
;; *never* creates any symbols whatsoever in the package that it is read
;; in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(defpackage my-package
(:nicknames mypkg :MY-PKG) ;remember CL conventions for case
(:use lisp) ; conversion on symbols
(:shadow CAR :cdr #:cons)
(:export "CONS") ;yes, this is the shadowed one.
)
Rationale:
The availability of DEFPACKAGE encourages putting the entire package
definition in a single place. It also encourages putting all the package
definitions of a program in a single file, which can be loaded before
loading or compiling anything else that depends on those packages; such a
file can be read in the USER package, avoiding any initial state issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp (SCL) has always had a DEFPACKAGE, and users
prefer it to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of
them appears to be necessary to propose for Common Lisp at this time.
This proposal is incompatible with Symbolics DEFPACKAGE in some ways
that will probably not cause major problems.
Cost to Implementors:
Small--DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
It has been suggested that the "Put IN Seven EXtremely Random USEr
Interface COmmands" mnemonic described in CLtL p.191 could be removed;
and with possibly a few exceptions, the special handling of them by
COMPILE-FILE could be removed. As this would be an incompatible change,
it is not part of this proposal. However, a new mnemonic can be offered,
to help remember the ordering constraints mentioned above:
I REmember Six USEr Interface Expressions
Each word in the sentence corresponds to one operation listed below:
I IN-PACKAGE ;"foot" to stand on
REmember REQUIRE ;ensure pre-requisite packages
Six SHADOW ;block multiple-inheritances
USEr USE-PACKAGE ;go for it!
Interface IMPORT ;bring in "foreign" symbols
EXpressions EXPORT ;a "face" to show to others.
It is noted that DEFPACKAGE cannot be used to create two "mutually
recursive" packages, such as:
(defpackage my-package
(:use lisp your-package) ;requires 'your-package' to exist first
(:export "MY-FUN"))
(defpackage your-package
(:use lisp)
(:import-from my-package "MY-FUN") ;requires 'my-package' to exist first
(:export "MY-FUN"))
However, nothing prevents one from using the package-effecting functions
such as USE-PACKAGE, IMPORT, and EXPORT to establish such links (which
ought to be very rare) after a more standard use of DEFPACKAGE.
The macroexpansion of DEFPACKAGE could usefully canonicalize the names
into strings, so that even if a source file has random symbols in the
DEFPACKAGE form, the compiled file would only contain strings.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Definition forms in Common Lisp usually just establish a name-to-object
mapping; there is little precedent for them to modify other global-context
state. For this reason, we didn't want DEFPACKAGE also to "go" into the
new package. If it did so, like IN-PACKAGE, then the following reasonable
file would become confused, because it wouldn't all be in one package:
(in-package "USER")
(defpackage "WATER" (:use "LISP") (:export "FISH"))
(defpackage "ALCHEMY" (:use "LISP" "PHLOGISTON) (:export gold))
Should the token 'gold' be read while in the USER package, or in the
the WATER package?
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.
∂06-Dec-88 0810 X3J13-mailer Re: ISO meeting report
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Dec 88 08:10:08 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA08575; Tue, 6 Dec 88 08:12:45 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA01763; Tue, 6 Dec 88 08:09:24 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA08992; Tue, 6 Dec 88 08:09:57 PST
Message-Id: <8812061609.AA08992@suntana.sun.com>
To: rpg@sail.stanford.edu,
mcvax!inria.inria.fr!chaillou@uunet.UU.NET (Jerome Chailloux)
Cc: x3j13@sail.stanford.edu
Subject: Re: ISO meeting report
In-Reply-To: Your message of Sat, 03 Dec 88 00:19:19 +0100.
<8812022319.AA10635@inria.inria.fr>
Date: Tue, 06 Dec 88 08:09:54 PST
From: kempf@Sun.COM
We are disappointed by the apparent disarray in relations between
ISO and ANSI and that there will not be a joint meeting
in January.
We believe that it is important to continue research into Lisp language
semantics which differ from those of Common Lisp, especially in areas
where Common Lisp is weak. The results of such research, once they become
accepted practice, can often be fed back into the standardization process,
strengthening the technical base of the standard. But standardization efforts
are not the place for research.
The position in the US statement reflects pretty much
the state of industry with regard to the commercialization of Lisp.
There is not really any demand for a commercial Lisp other than Common
Lisp in the US at the moment. Since Sun, as is the case for other Lisp vendors,
operates in the international marketplace, an international standard for
Common Lisp is highly desirable, since it reduces the investment Sun needs
to make in developing and supporting Lisp and Lisp based tools. Nobody
here believes that Common Lisp is technically the "right" solution, but
the technical challenges facing commercial Lisp today are less in terms
of semantics and more in terms of implementation technology. We expect
to monitor developments in Scheme and ISO activity.
We hope that the ANSI/ISO split can be resolved as quickly as possible, so
that the enormous amount of work put into the Common Lisp standard by
X3J13 over the last 3 years can benefit the international Lisp community
as well, and that the technical expertese of the international Lisp
community can be brought to bear on the final stages of checking the
draft standard for correctness.
James Kempf, Sun Microsystems
Cris Perdue, Sun Microsystems
∂07-Dec-88 1425 X3J13-mailer January agenda items please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Dec 88 14:25:09 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00440g; Wed, 7 Dec 88 14:22:42 PST
Received: by challenger id AA04360g; Wed, 7 Dec 88 14:18:52 PST
Date: Wed, 7 Dec 88 14:18:52 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812072218.AA04360@challenger>
To: x3j13@sail.stanford.edu
Subject: January agenda items please
Please let me know if you have something to add to the agenda and how much
time you need.
Please remember the 2 week rule for voting. Things should be mailed by 12/14
to insure receiving 2 weeks before the meeting.
---jan---
∂07-Dec-88 1659 X3J13-mailer Issue: DESCRIBE-INTERACTIVE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 16:59:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 15:52:50 PST
Date: 7 Dec 88 15:52 PST
Sender: masinter.pa@Xerox.COM
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
From: CL-cleanup@Sail.Stanford.edu
Subject: Issue: DESCRIBE-INTERACTIVE (Version 4)
reply-to: CL-CLEANUP@Sail.stanford.edu
line-fold: NO
Message-ID: <881207-155250-1594@Xerox>
This issue has two proposals, EXPLICITLY-VAGUE and NO.
Notes from Fairfax meeting...
"...thinks it's stupid to waste time on issues like this....others disagreed."
!
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION (EXPLICITLY-VAGUE) / CHANGE (NO)
Edit history: 12-Sep-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
19-Oct-88, Version 3 by Pierson, invert
15-Nov-88, Version 4 by Pierson, two-proposal version
Problem Description:
CLtL is not clear about whether DESCRIBE may be interactive.
While CLtL describes INSPECT as an interactive as an
interactive version of DESCRIBE, it doesn't make explicit
that DESCRIBE is non-interactive. In some implementations it is,
and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Specify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This validates current implementations.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Proposal (DESCRIBE-INTERACTIVE:NO):
Specify that DESCRIBE is forbidden to prompt for or require
user input. Permit implementations to extend describe via keyword
arguments to prompt for or require user input as long as the default
action if no keyword arguments are supplied does not prompt for or
require user input.
This is an incompatible change for some implementations.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE* :INTERACTIVE T)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
DESCRIBE is the only hook a portable program has for providing
information about objects to the user. The potential interactive
functions of DESCRIBE are also likely to be available via INSPECT.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
Symbolics Genera and other non-conforming implementations will have
to change.
Cost to Users:
User code which depends on DESCRIBE running with user interaction
will have to be modified. Such code is not currently portable,
however.
Cost of Non-Adoption:
Users would not have any portable way to have progams inform the
user about object they are dealing with. This might be important in
traces and logs of portable progams or in portable debugging tools.
Benefits:
It will be easier to provide some types of portable functionality.
Aesthetics:
This simplifies the language slightly.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
EXPLICITY-VAGUE proposal is the minimal proposal for compatibility
with current behavior.
Some members of the cleanup committee think that EXPLICITLY-VAGUE is
really a change from the intent of CLtL. However, the current
sentiment is to be less rather than more specific about the behavior
of debugging tools (25.3 of CLtL).
It might be possible to extend DESCRIBE to have additional
keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover
additional behavior.
Pierson supports NO because he thinks it's important for there to be
some way for portable programs to present this sort of information
to the user. While the exact data and format presented is
implementation dependent and thus outside of the bounds of
standardization, the existance of such data is neither.
Moon opposes NO because "it creates extra work for implementors and
users of at least one implementation, for no compelling reason."
Moon suggested as a compromise only allowing DESCRIBE to require
user input from "interactive streams". Several other members of the
committee like this in principle but question whether it's feasible
since we have neither defined "interactive streams" nor provided any
portable way to tell if a stream is interactive.
∂07-Dec-88 1803 X3J13-mailer Issue: DOTTED-MACRO-FORMS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 18:03:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 17:12:10 PST
Date: 7 Dec 88 17:11 PST
Sender: masinter.pa@Xerox.COM
to: x3j13@sail.stanford.edu
Subject: Issue: DOTTED-MACRO-FORMS (Version 3)
from: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881207-171210-2206@Xerox>
At the cleanup committee meeting prior in Fairfax, we decided to propose this version.
!
Issue: DOTTED-MACRO-FORMS
References: forms (p54), lists and dotted lists (pp26-27),
DEFMACRO (p145), destructuring macro arguments (p146)
Category: CLARIFICATION/CHANGE
Edit history: 28-Jun-88, Version 1 by Pitman (explicitly-vague vs allow)
01-Oct-88, Version 2 by Masinter (disallow)
15-Nov-88, Version 3 by Pitman (revive allow, flush disallow)
Problem Description:
CLtL is not explicit about whether macro forms may be dotted
lists.
p54 says that only certain forms are "meaningful": self-evaluating
forms, symbols, and "lists".
pp26-27 defines "list" and "dotted list". It goes on to say
``Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.''
p146 states that in DEFMACRO destructuring, ``the argument
form that would match the parameter is treated as a
(possibly dotted) list, to be used as an argument forms list
for satisfying the parameters in the embedded lambda list.''
It goes on to say that ". var" is treated like "&rest var"
at any level of the defmacro lambda-list.
Proposal (DOTTED-MACRO-FORMS:ALLOW):
Define that it is permissible for a macro form (or subform)
to be a dotted list when "&REST var" or ". var" is used to match
it. It is the responsibility of the macro to recognize and deal
with such situations.
Rationale:
Some implementations permit dotted lists in macro forms at toplevel.
Most or all implementations permit dotted lists in macro forms at
embedded levels. This proposal makes the language internally
consistent without requiring changes to existing code.
Also, there's no reason to unnecessarily restrict &REST since there
is no computational overhead and since there's no dispute about how
to interpret programmer intent in this gray area.
Test Case:
#1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
(MACW . 1) => ??
#2: (DEFMACRO MACR (&REST R) `(- ,R))
(MACR . 1) => ??
#3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
(MACX . 1)
(MACW . 1) => -1 under this proposal.
(MACR . 1) => -1 under this proposal.
(MACX . 1) is an error under CLtL semantics and is not
changed by this proposal. The reason it is an
error is that the argument pattern does not
match. The pattern is dictated by the arguments
-other than- the &WHOLE argument, so the pattern
is () and MACX cannot be called with any arguments.
Current Practice:
A. Some implementations bind W to (MACW . 1) in #1 and #3
and bind R to 1 in #1 and #2.
B. Some implementations bind W to (MACW . 1) in #3
and signal a syntax error in #1 and #2.
C. Some implementations signal a syntax error in #1, #2, and #3.
Symbolics Genera is such an implementation.
Cost to Implementors:
Some implementations would have to eliminate an error check.
Some implementations which try to use APPLY of a normal lambda
to accomplish part of the destructuring (in the non-recursive case)
would have to be slightly more careful.
Cost to Users:
None. This change is upward compatible.
Benefits:
People would know what to expect.
Aesthetics:
Mixed opinion: certainly it is better to specify whether they are
allowed or an error than to be vague.
Some feel that disallowing dotted macro forms helps catch syntax errors.
Some feel that allowing dotted macro forms makes the language more regular.
Discussion:
Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
This issue came up primarily in the context of program-written programs;
a macro used in the program generated code might occasionally use
a dotted tail to a list to explicitly represent special conditions.
Allowing dotted macro forms may blur the data/code distinction too much,
particularly for people who are new to Lisp. On the other hand, some people
argue that the point of macros is to help blur that distinction. Macro
forms are data which must be translated to program, and only once the
program claims to be macroexpanded ought syntax restrictions be imposed.
This proposal was rewritten from `DISALLOW' to `ALLOW' after Steele pointed
out in a recent meeting that dotted lists are allowed in subforms and
that permitting them at toplevel would be the most internally consistent
interpretation.
Pitman supports DOTTED-MACRO-FORMS:ALLOW.
∂07-Dec-88 2058 X3J13-mailer Issue: EXPT-RATIO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 20:58:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 20:51:44 PST
Date: 7 Dec 88 20:51 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: EXPT-RATIO (Version 2)
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
from: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881207-205144-2665@Xerox>
!
Forum: Cleanup
Issue: EXPT-RATIO
References: CLtL pages 204 and 211
Category: CLARIFICATION
Edit history: Version 1, 4-Oct-88, by Aspinall and Moon
Version 2, 6-Oct-88, Masinter (very minor discussion)
Version 3, 31-Oct-88, Masinter (fix typo)
Problem description:
The comment (page 204, 2nd para) that "... an implementation [of expt]
might choose to compute (expt x 3/2) as if it had been written
(sqrt (expt x 3))" disagrees with the principal value definition on
page 211. See the example below for a case where the two disagree. We
believe the principal value definitions are consistent and reasonable,
therefore the implementation comment is wrong.
Proposal (EXPT-RATIO:P.211):
Clarify that (sqrt (expt x 3)) is not equivalent to (expt x 3/2)
and that page 211 rules.
Examples:
(defvar x (exp (/ (* 2 pi #c(0 1)) 3))) ;exp(2.pi.i/3)
(expt x 3) => 1 (except for round-off error)
(sqrt (expt x 3)) => 1 (except for round-off error)
(expt x 3/2) => -1 (except for round-off error)
There can be no question that
(expt x 3) ==> 1
because expt is single-valued with an integer second argument, and
(sqrt 1) ==> 1
definitely follows the principal branch of the square root function.
But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
(log x) ==> 2.pi.i/3
according to the definition of the logarithm's branch cuts on page 211
(which really comes down to the branch cuts of phase - page 210), so
(* (log x) 3/2) ==> pi.i
and
exp(pi.i) is -1.
Rationale:
We believe the principal value definitions are consistent and
reasonable, therefore the implementation comment is wrong.
Current practice:
Symbolics Genera 7.3 currently returns the wrong answer, following page
204 rather than page 211. Lucid Common Lisp, and
Envos Medley implement the proposal.
Cost to Implementors:
The obvious code changes in complex expt.
Cost to Users:
None.
Cost of non-adoption:
Self-contradictory language specification.
Benefits:
Users can better predict the branch cuts in expt.
Discussion:
Mathematical Explanation: When the expt function returns a complex result
in CL (Cartesian) form, the phase of the complex number is effectively
canonicalized. Information is lost, and that information is necessary to
specify upon which branch of the sqrt function the final result should lie.
Another way to put it would be that although
sqrt(expt(x,3)) = expt(x,3/2)
where expt and sqrt are the mathematical multi-valued functions, it is not
true that:
pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
where pvexpt and pvsqrt denote the principal value versions of those functions.
∂07-Dec-88 2143 X3J13-mailer Issue: FORMAT-PRETTY-PRINT (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Dec 88 21:43:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 21:33:31 PST
Date: 7 Dec 88 21:33 PST
Sender: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Subject: Issue: FORMAT-PRETTY-PRINT (Version 7)
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881207-213331-2723@Xerox>
!
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Version 5 by Masinter 2-Oct-88
Version 6 by Pierson 11/10/88 final nits
Version 7 by Pierson 11/15/88 "does" => "does not"
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
*PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
argument.
Iff no aruments are specified, binds *PRINT-BASE* to 10.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying implementations which will
have to change whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT- variables. There may be other similar interactions in
Common Lisp that need clarification.
Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.
CLtL might change as follows:
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
There was some discussion on whether *PRINT-BASE* should be bound for
~F, ~G, ~E, and ~$. This is not necessary because page 341 of CLtL
states that floating point numbers are always printed in base 10.
∂08-Dec-88 0613 X3J13-mailer Re: January agenda items please
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 8 Dec 88 06:13:03 PST
Date: 8 Dec 1988 09:10-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: January agenda items please
From: ROSENKING@A.ISI.EDU
To: jlz@LUCID.COM
Cc: mathis@A.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 8-Dec-88 09:10:30.ROSENKING>
In-Reply-To: <8812072218.AA04360@challenger>
What is the official status of the ISO meeting, is it on or off ?
It appears, from monitoring the mail since the last ISO meeting,
that there are several issues which need to be worked out. Do our
ISO reps and chairman believe that we should abandon the meeting
or perhaps try to take the initiative to bring the ISO reps all
together to try to solve some of the problems. Members such as
myself who are outside of this loop can not appreciate the true
status of the situation.
∂08-Dec-88 1056 X3J13-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 10:56:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 10:39:12 PST
Date: 8 Dec 88 10:38 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-103912-3821@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Version 4, 2-Oct-88 Masinter (update references,
discussion)
Version 5, 14-Nov-88 Masinter (add to discussion)
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
REST-LIST-ALLOCATION
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only
examples found so far are in a text book on Common Lisp, which follows the
proposed syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do
so. Probably only a small amount of code would have to be written/changed
in implementations that currently think that the &REST argument should be
LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code. However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors normal lambda-list syntax, it would be
cleaner and less confusing to provide the type of the lambda variable
rather than the type of the actual arguments. However, considering the
types specified in the FUNCTION specifier to be the types of the actual
arguments rather than the types of the parameters as seen on the receiving
end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee and at
X3J13.
Many people objected to this proposal, and would prefer the alternative
that the type given after a &REST in a function declaration apply to the
value of the formal parameter rather than the actual arguments. This would
be even more useful if complex LIST type specifiers were part of Common
Lisp (as the proposal in issue LIST-TYPE-SPECIFIER might add) or if it were
possible to declare, for example, &REST {keyword integer}*.
Some additional arguments against this proposal are the apparent mismatch
between the external declarations of type and the internal ones. It might
be that this proposals presumes that rest lists are always lists, and the
following is illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
which is not otherwise explicitly forbidden, but for which there is no
legitimate declaration.
∂08-Dec-88 1129 X3J13-mailer Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 11:29:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 11:10:31 PST
Date: 8 Dec 88 11:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-111031-3954@Xerox>
!
Issue: GET-MACRO-CHARACTER-READTABLE
References: CLtL p.361: COPY-READTABLE, SET-SYNTAX-FROM-CHAR, and
GET-MACRO-CHARACTER
CLtL p.364: GET-DISPATCH-MACRO-CHARACTER,
CLtL p.378: Example in middle of page
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 16-Nov-88, by JonL
Version 2, 8-Dec-88, by Masinter (fix typo)
Problem description:
The 'readtable' argument to GET-DISPATCH-MACRO-CHARACTER and to
GET-MACRO-CHARACTER must be of type READTABLE, without mention of
what happens when NIL is supplied. This may have been simply
an oversight, since it makes more sense for it to refer to values from
the standard readtable. Both COPY-READTABLE and SET-SYNTAX-FROM-CHAR
explicitly say that a NIL in the 'from-readtable' argument refers to the
standard readtable. Also, an example in the middle of the page, CLtL
p.378, supplies a NIL to GET-MACRO-CHARACTER, and is clearly intending
to access the standard readtable values.
Proposal (GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD)
Specify that a NIL readtable argument to GET-DISPATCH-MACRO-CHARACTER
and to GET-MACRO-CHARACTER mean the same thing it does for COPY-READTABLE,
and SET-SYNTAX-FROM-CHAR; namely a reference to the standard readtable.
Thus (GET-MACRO-CHARACTER <char> NIL) would be equivalent to
(GET-MACRO-CHARACTER <char> (COPY-READTABLE)), but without consing.
Test Cases:
(let ((standard-rt (copy-readtable))
(chars '(#\* #\= #\| #\A #\ #\( #\# #\1)))
;; Test Case 1
(dolist (char chars)
(assert (eq (get-macro-character char nil)
(get-macro-character char standard-rt))
() "Lose on character ~C" char))
;; Test Case 2
(dolist (char chars)
(assert (eq (get-dispatch-macro-character #\# char nil)
(get-dispatch-macro-character #\# char standard-rt))
() "Lose on #\# dispatch character ~C" char))
;; Test Case 3
(assert (eq (get-dispatch-macro-character #\# #\A nil)
(get-dispatch-macro-character #\# #\a nil))
() "Lose on #\# dispatch character ~C" char)
)
Rationale:
Probably was the original intent; somebody wants it; also see "Esthetics".
Current practice:
Symbolics and Xerox have already implemented the proposal; Lucid, VAXLISP,
and KCL stuck to the more rigid interpretation.
Cost to Implementors:
Trivial.
Cost to Users:
None.
Cost of non-adoption:
Minor worry about porting between implementations that support the
generalization and those that don't; minor worry about consing when
calling (COPY-READTABLE) to get at standard readtable semantics.
Performance impact:
See "Cost of non-adoption".
Benefits:
See "Cost of non-adoption".
Esthetics:
Increases parallel design among similar readtable functions.
Discussion:
This question was raised in the Common Lisp mailing last summer:
Date: 19 Jul 88 13:35
Subject: Question about readtable null arguments
From: quiroz%cs.rochester:EDU:Xerox
To: common-lisp%sail.stanford:EDU:Xerox
∂08-Dec-88 1147 X3J13-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 11:45:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 88 11:32:56 PST
Date: 8 Dec 88 11:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-113256-4026@Xerox>
!
Forum: Cleanup
Issue: HASH-TABLE-PACKAGE-GENERATORS
References: Issue: DO-SYMBOLS-DUPLICATES
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Version 3, 7-Oct-88 JonL (mly's syntax for package iterator)
Version 4, 8-Nov-88 JonL (fix example; clarify some nits)
Version 5, 22-Nov-88 Moon (improve syntax for package iterator,
add examples, fix typos)
Version 6, 6-Oct-88 JonL (final nits)
Version 7, 8-Dec-88, Masinter (add comment to discussion)
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses. In particular,
these primitives are fully packaged and do not allow control over the
individual operations of starting the iteration, stopping the iteration,
and advancing to the next step of the iteration.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the hash-table which is obtained
by evaluating <hash-table> only once.
An invocation (<next-fn>) returns three values as follows:
1. a boolean indicating whether an entry is returned (T says yes)
2. the key item (of a <key, value> pair)
3. the value item (of a <key, value> pair)
After all entries have been returned [by successive invocations of
(<next-fn>)], then only one value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package-list> [Macro]
&rest <symbol-types>)
&body body)
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return symbols, one by one, from the packages that are elements
of the list which is obtained by evaluating <package-list> only once.
Each element of <package-list> can be a package or the name of a
package.
The order of symbols returned does not necessarily reflect the order
of packages in <package-list>. When <package-list> has more than
one element, it is unspecified whether duplicate symbols are
returned once or more than once. Even when <package-list> has only
one element, it is unspecified whether symbols inherited from
multiple packages are returned more than once. See the proposal
DO-SYMBOLS-DUPLICATES:ALLOWED.
As a convenience, the value of <package-list> can be a package or
the name of a package; this is equivalent to a list of one element.
An argument of NIL is treated as an empty list of packages.
The <symbol-types> subform consists of one or more symbols from the
set {:INTERNAL, :EXTERNAL, :INHERITED}. Their order does not
matter. The <symbol-types> subform is not evaluated. This controls
which symbols accessible in a package are returned:
:INTERNAL means the symbols that are present in the package,
but which are not exported;
:EXTERNAL means the symbols that are present and exported;
:INHERITED means the symbols that are exported by used packages
and that are not shadowed.
When more than one argument is supplied for <symbol-types>, then a
symbol is returned if its accessibility matches any one of the
<symbol-types> specified. WITH-PACKAGE-ITERATOR signals an error if
no <symbol-types> are specified or if a <symbol-type> not recognized
by the implementation is specified. Implementations are permitted to
extend this syntax by recognizing additional symbol accessibility types.
An invocation (<next-fn>) returns four values as follows:
1. a boolean indicating whether a symbol is returned (T says yes)
2. a symbol (accessible in one the indicated packages)
3. the accessibility type for that symbol; i.e. one of
:INTERNAL, :EXTERNAL, or :INHERITED
4. the package from which the symbol has been accessed.
After all symbols have been returned [by successive invocations of
(<next-fn>)], then only one value is returned, namely NIL.
The fourth return value is one of the packages present or named in the
<package-list> argument. The meaning of the second, third, and fourth
values is that the returned symbol is accessible in the returned package
in the way indicated by the second return value:
:INTERNAL ==> present, and not exported,
:EXTERNAL ==> present, and exported,
:INHERITED ==> not present (thus not shadowed) but inherited
from some used package.
It is unspecified what happens if any of the implicit interior state
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).
Any number of invocations of with-hash-table-iterator and
with-package-iterator can be nested, and the body of the innermost one
can invoke all of the MACROLET'ed macros, provided all those macros
have distinct names.
Examples:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-hash-table-iterator (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-package-iterator (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package
:internal :external :inherited)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol pkg accessibility)
(generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
The following function prints out every interned symbol (possibly
more than once):
(defun print-all-symbols ()
(with-package-iterator (next-symbol (list-all-packages)
:internal :external)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol) (next-symbol)
(if more?
(print symbol)
(return))))))
The following could be an acceptable definition of the function
MAPHASH, implemented by WITH-HASH-TABLE-ITERATOR"
(defun maphash (function hash-table)
(with-hash-table-iterator (next-entry hash-table)
(loop (multiple-value-bind (more key value) (next-entry)
(unless more (return nil))
(funcall function key value)))))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh. Something like this is already being
done by the standard package macros [CLtL, p187].
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed
to do so by this proposal.
The following macro definitions show how Common Lisp's DO-mumble-SYMBOLS
macros could have been defined in terms of WITH-PACKAGE-ITERATOR. They
are intended as illustrative examples, not as new specifications of those
built-in Common Lisp facilities. [PARSE-BODY is as defined in Guy Steele's
"Clarifications" of 6-Dec-85.]
(defmacro do-symbols ((var &optional (package `*package*) result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list ,package)
:internal :external :inherited)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
(defmacro do-external-symbols ((var &optional (package `*package*) result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list ,package)
:external)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
(defmacro do-all-symbols ((var &optional result-form)
&body body
&environment env)
(multiple-value-bind (body decls docstring) (parse-body body env)
`(with-package-iterator (next-symbol (list-all-packages)
:internal :external)
(let (more? ,var)
,@decls
(loop
(unless (multiple-value-setq (more? ,var) (next-symbol))
(setq ,var nil)
(return ,result-form))
,@body)))))
-------
"Why not define <next-fn> as a local function as if defined by
FLET rather than a macro as if defined by MACROLET? "
"A macro gave more scope to the implememtation to optimize
without losing anything essential in these circumstances."
∂08-Dec-88 1524 X3J13-mailer Issue: HASH-TABLE-TESTS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 15:24:30 PST
Received: from Salvador.ms by ArpaGateway.ms ; 08 DEC 88 15:11:34 PST
Date: 8 Dec 88 15:06 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-TESTS (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-151134-4673@Xerox>
!
Issue: HASH-TABLE-TESTS
References: CLtL, p382 (third paragraph), and p383
Issue EQUAL-STRUCTURE
Requires Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Category: Addition
Edit history: 26-Sep-88 Version 1 by JonL
8-Dec-88 Version 2 by Masinter
(as per cl-cleanup)
Problem Description:
A great many users try to coalesce two equivalent DEFSTRUCT instances,
or two equivalent pointer arrays, using hash tables; but they are rudely
awakened when they find out that EQUAL is not an appropriate test for
this case, and that there is no :test argument to MAKE-HASH-TABLE which
will "hash on non-tree structures".
Proposal: HASH-TABLE-TESTS:ADD-EQUALP
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will
come in four kinds, the difference being whether the keys are compared
with EQ, EQL, EQUAL, or EQUALP.
Examples:
> (defstruct foo a b c)
FOO
> (setq x (make-foo :a 1 :b 'b :c '(1 . 2))
x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
#S(FOO A 1 B B C (1 . 2))
> (setq y #(1 B (1 . 2))
y-copy (copy-seq y))
#(1 B (1 . 2))
> (setq ht-equal (make-hash-table :test 'equal)
ht-equalp (make-hash-table :test 'equalp))
#<Hash-Table BB1F7B>
> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t)
(setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
T
> (gethash x-copy ht-equal)
NIL
NIL
> (gethash x-copy ht-equalp)
T
T
> (gethash y-copy ht-equal)
NIL
NIL
> (gethash (copy-seq y) ht-equalp)
T
T
>
Rationale:
Implementing hash-tables efficiently is not an easy task; it makes more
sense for this to be standardly available than for individual programmers
to keep trying to re-invent this obscure part of technology.
Current Practice:
Lucid's release 3.0 implements this proposal [some 2.1-level release
supported it "provisionally"]. Symbolics implementation is reputed
to be robust enough to implement this proposal trivially.
Cost to Implementors:
Moderate. Implementors have already dealt with EQUAL; the only tricky
part will be ensuring the implication:
"If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
same collision chain in any given EQUALP hash table"
It has been suggested that merely linear searching a table is an acceptable
implementation technique for CL's hash-tables [although no serious
implementation limits itself thus] and that such tables have no "collision
chains"; but in fact, this is the degenerate case wherein all entries are
in the same collision chain, so the implication is trivially satisfied.
Some persons prefer to say that the "reprobe sequence will be the same for
the two items", rather than using the term "collision chain"; the meaning
is the same.
Cost to Users:
None. This is an entirely upwards-compatible addition.
Cost of non-adoption:
Continuing bug reports from users about why "hashing
doesn't work" when said user tries entering pointer-containing objects
other than cons cells into hash tables. Continuing delay in same
user's work until they figure out a new strategy for identifying
equivalent structures. More difficulty in debugging their alternatives.
Benefits:
Addresses one aspect of the difficult equivalence problem. Makes
hash tables more useful. Permits case-insensitive hashing
on strings [tables of type EQUAL are case-sensitive on strings];
another use is to allow = comparison for numbers
[tables of type EQUAL use EQL on numbers].
Aesthetics:
Reduces the discontinuity between basic equivalence functions and those
usable as equivalence relations in hash-tables.
Discussion:
With the rejection of all the issues related to EQUAL-STRUCTURE, there is
little or no hope that EQUAL will be "beefed up" to meet the expectations
of so many of the user community on compound structures. If one wants
a hash-table with a :test function that has fewer equivalence classes
(i.e., does more "coalescing"), then there is no alternative now except
to use the function EQUALP.
It would also be possible to extend hash tables to allow = or
STRING=, but those are not being proposed at this time.
∂08-Dec-88 1644 X3J13-mailer Issue: LCM-NO-ARGUMENTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 16:43:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:29:52 PST
Date: 8 Dec 88 15:45 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LCM-NO-ARGUMENTS (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-162952-4859@Xerox>
!
Forum: Cleanup
Issue: LCM-NO-ARGUMENTS
References: CLtL p. 202
Category: ADDITION
Edit history: Version 1, Guy Steele 10/17/88
Problem description:
CLtL incorrectly states that (lcm) should return infinity, and
therefore specifies that giving lcm no arguments is an error.
In point of mathematical fact, 1 is the identity for the lcm operation.
Proposal (LCM-NO-ARGUMENTS:1):
Define (lcm) to return the integer 1.
Examples:
(lcm) => 1
Currently the behavior in this case is implementation-dependent.
Rationale:
Doing what is mathematically right.
Current practice:
KCL signals an error.
Lucid Lisp returns 1.
Symbolics Common Lisp returns 1.
Cost to Implementors:
Pretty small (one-line fix).
Cost to Users:
None.
Cost of non-adoption:
Continued embarassment for Steele.
Performance impact:
Negligible.
Benefits:
Correct handling of a seldom-used boundary case.
Esthetics:
Mild improvement.
Discussion:
Mentioned in Steele's December 1985 "clarifications".
∂08-Dec-88 1643 X3J13-mailer Issue: LAMBDA-FORM (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 16:43:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:29:39 PST
Date: 8 Dec 88 15:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LAMBDA-FORM (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-162939-4858@Xerox>
!
Forum: CLeanup
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Related Issues: LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
02-Oct-88, Version 3 by Pitman
22-Nov-88, Version 4 by Masinter
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Many other Common Lisp implementations do not offer such a macro.
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
No conversion cost. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
In Scheme, the operator of a function invocation form has the same
evaluation semantics as the operands. In CL, however, the operator is
not evaluated in the same way that the operands are. This definition
of LAMBDA as a macro would obscure this difference. A novice Lisp
programmer might have a hard time understanding why the #' is
optional in
(MAP [#'](LAMBDA (POINT) (+ (POINT-X POINT) (POINT-Y POINT)))
POINT-LIST)
but is required in
(MAP #'SUM-OF-COORDS POINT-LIST)
This proposal "clutters" the language because it makes the syntax
more complex. LAMBDA is then used not only as a "flag" for
introducing lambda-expressions, but also is a macro which generates
functions. There is at least one precedent for having two
operations that do the identical thing -- NOT and NULL. Both have
been retained because they express different intents. In this case,
the intent of #'xxx might be to ``access'' a function by name (the
name of an anoymous function being its lambda expression), and the
intent of (LAMBDA ...) is to ``create'' a function. This distinction
is subtle but may be expressionally interesting to some programmers
in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks
a lot better than #'(LAMBDA ...). Certainly it takes up fewer
characters, and (LAMBDA ...) is a notable offender in code needing
to be split onto multiple lines, so every little bit probably helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions, etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item (LISP-SYMBOL-REDEFINITION) addresses
this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form. Many people prefered that alternative.
However, there were also strong objections to requiring a new special form;
since the FUNCTION special form is still necessary (for #'symbol),
it was deemed better to have LAMBDA a macro which is defined
in terms of FUNCTION than to have both LAMBDA and FUNCTION
as special forms.
∂08-Dec-88 1716 X3J13-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 17:16:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 16:58:45 PST
Date: 8 Dec 88 16:42 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-165845-4914@Xerox>
!
Forum: Cleanup
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
Masinter, Version 5, 22-Nov-88, add more cases
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
This proposal uses the phrase "the consequences are undefined" in the
sense that implementations may signal an error, or other undefined behavior
may ensue, and attempts to specify that user programs generally cannot
portably modify the behavior of the symbols in the LISP package.
For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Specify that the consequences of performing any of the following
operations are undefined:
* redefining as a function or macro any of the functions,
macros, or special forms defined in the LISP package;
* lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package;
* attempting to rebind any symbol in CL defined as a constant;
this covers binding as with LET or LAMBDA, assignment
as with SETQ or SETF, or using MAKUNBOUND;
(implied by CLtL p. 69)
* defining type-specifiers as with DEFTYPE, DEFSTRUCT, or
DEFCLASS, any of the built in type specifiers, classes;
* defining or redefining SETF macros or functions of any
of the functions, macros or special forms that have specified
SETF behavior, using either DEFSETF or DEFINE-SETF-METHOD
(or with DEFUN if the proposal under SETF-FUNCTION-VS-MACRO
is adopted);
* applying TRACE to any function in the LISP package.
No other restrictions are placed on users attaching definitions
on symbols in the LISP package; for example, a user program
may
(DEFVAR CAR 3)
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂08-Dec-88 1739 X3J13-mailer Issue: NTH-VALUE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 17:39:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 17:20:41 PST
Date: 8 Dec 88 17:15 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: NTH-VALUE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-172041-4997@Xerox>
!
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
5-Oct-88, Version 3 by Masinter
(add Current Practice as per Gray)
8-Dec-88, Version 4 by Masinter
(add comments to discussion)
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
The TI Explorer and LMI Lambda have this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Some will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
This is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
(The feature is rarely used in implementations that have it.)
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
There was not strong sentiment for including this feature
in Common Lisp, but no active opposition.
Comments at the October 1988 X3J13 meeting:
"Trivial, gratuitous."
"Not trivial -- allows index computation. Hard to do this
in a portable, efficient way."
"Says he has an NTH-VALUE macro for a portable system that he
uses (which exploits the computed index feature) and that it's
a gross kludge in one implementation to make it efficient."
∂08-Dec-88 2041 X3J13-mailer Issue: PACKAGE-DELETION (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 20:41:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 20:40:59 PST
Date: 8 Dec 88 20:40 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PACKAGE-DELETION (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881208-204059-5304@Xerox>
!
Forum: Cleanup
Issue: PACKAGE-DELETION
References: Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
01-Oct-88, Version 2 by Pitman
04-Oct-88, Version 3 by Pitman
(provide for correctable errors in some cases)
07-Oct-88, Version 4 by JonL
21-Nov-88, Version 5 by Masinter
Problem Description:
There is no way to get rid of a package in Common Lisp.
This absence makes interactive development work tricky in some
implementations. If a package is accidentally built incorrectly, the
user must either rename the package to another package or start over
by reloading his program in a fresh lisp image.
Some programs need to create and destroy packages at runtime.
Without such a facility, some clumsy combination of RENAME-PACKAGE,
UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
easy for a casual programmer to forget to undo some of the
bookkeeping, leading to unwanted effects.
Proposal (PACKAGE-DELETION:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE is a package name (i.e., not type PACKAGE) which does not
currently name a package, a correctable error is signalled. If
continued, no deletion action is attempted. Instead, DELETE-PACKAGE
immediately returns NIL.
If PACKAGE is a package object (i.e., an object of type PACKAGE)
which has already been deleted, no error is signalled and no further
deletion action is attempted. Instead, DELETE-PACKAGE immediately
returns NIL.
If the designated package is used by other packages, a correctable
error is signalled. If continued, the effect of UNUSE-PACKAGE is
done to remove any dependencies, causing its external symbols to stop
being accessible to those packages. Once this is done, DELETE-PACKAGE
goes on to delete the package just as it would had there been no
packages that used it.
After this operation completes, the contents of the symbol-package
slot of any symbol homed in the deleted package is unspecified; for
those symbols not homed in that package, the contents remain unchanged.
Except for this, symbols in the deleted package are not modified in
any other way.
The effect of DELETE-PACKAGE is that the name and
nicknames of the designated package cease to be recognized package
names. The package object is still a package -- PACKAGEP is true
of it -- but PACKAGE-NAME will return NIL. The effect of any other
package operation on PACKAGE once it has been deleted is undefined.
In particular, FIND-SYMBOL, INTERN and other functions that
look for a symbol name in a package will have unspecified results if
called with *PACKAGE* bound to the deleted package or with the
deleted package as an argument.
DELETE-PACKAGE returns T if the deletion attempt was successful
and NIL otherwise.
Examples:
(SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
(SETQ *FOO-SYMBOL* (INTERN "FOO" *FOO-PACKAGE*))
(EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
(SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
(SETQ *BAR-SYMBOL* (INTERN "BAR" *BAR-PACKAGE*))
(EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
(EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
(SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) => #<Package "BAR">
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) => "BAR:BAR"
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) => FOO:FOO, :EXTERNAL
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => FOO:FOO, :INHERITED
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => BAR:BAR, :INHERITED
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => "BAR"
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) => (#<Package FOO>)
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
(DELETE-PACKAGE *BAR-PACKAGE*)
Error: Package BAZ uses package BAR.
If continued, BAZ will be made to unuse-package BAR,
and then BAR will be deleted.
Type :CONTINUE to continue.
Debug> :CONTINUE
=> T
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) is unspecified
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) is unspecified
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) is undefined
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => NIL, NIL
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => NIL, NIL
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => NIL
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
Rationale:
This facility corrects the deficiency described in the problem description.
Current Practice:
Symbolics has a function PKG-KILL which satisfies the proposed behavior
except that an error is not signalled if the package is used.
When a package is killed by PKG-KILL, the home package of all symbols
in that package are left undisturbed (i.e., local symbols pointing to
the killed package); this aspect is compatible with the stated proposal.
Procyon Common Lisp has a function called DELETE-PACKAGE already. It
returns the name of the package so deleted (as a string). [Perhaps it also
differs in the correctability of the errors it signals?]
Lucid Common Lisp implements DELETE-PACKAGE, except that the continuation
option for a name that doesn't name a package is different.
Cost to Implementors:
The cost of providing this facility is probably small.
Cost to Users:
Very slight to none. This change is essentially compatible.
Some code which cached packages in variables might have to be slightly
more cautious, but experience in the Symbolics implementation suggests
that it's really the responsibility of the person doing the DELETE-PACKAGE
to take care of worrying about the effects of having deleted the package:
normal programs need not bother testing a package for validity (using
PACKAGE-NAME) before using it.
Cost of Non-Adoption:
Getting rid of a package would continue to be difficult to do portably.
Benefits:
Better control of storage usage would be available portably.
Aesthetics:
No significant effect.
Discussion:
This was discussed as part of a larger bulk issue of how to undo all
sorts of definitions. Since that proposal has not gone anywhere
(perhaps bogged down under its own weight), this subtopic has been
broken off for separate discussion.
Note that if a symbol's package component is modified as a result
of being "unintern'd" from a delete packaged, then it is unspecified
as to how it will be printed.
∂09-Dec-88 0039 X3J13-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:39:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:38:45 PST
Date: 9 Dec 88 00:38 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-003845-5561@Xerox>
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Related issues: REQUIRE-PATHNAME-DEFAULTS
CLOSED-STREAM-OPERATIONS
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter
26-Nov-88, Version 5 by Masinter
9-Dec-88, Version 6 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- T
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
(NB: the issue CLOSED-STREAM-OPERATIONS proposes modifying
the return value of CLOSE on closed streams. The issue
REQUIRE-PATHNAME-DEFAULTS proposes removing
REQUIRE and PROVIDE. Those proposals would take
priority over this one.)
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from these constructs.
Current Practice:
Varies; the choices made here are consistent with many but
not all implementations.
Cost to Implementors:
Small.
Benefits:
This clarification will assist users in writing portable code.
Cost to users:
Small; it seems unlikely that there is much code that currently
depends on the return values of these functions; such code isn't
portable.
Aesthetics:
Specified is better than not, when it makes sense.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. Another proposal would
eliminate them from the language, and then their return value would definitely
be moot!
There is some sentiment for leaving unspecified the values of the
debugging/environment features such as TRACE and UNTRACE,
for the same reasons that so much else of their behavior is unspecified.
Notes from Oct 88 X3J13:
Except for LOCALLY, why bother?
That just causes portability problems. Don't want to leave it
unspecified -unless- someone can cite a reason to do so.
"If many weren't defined, maybe we should leave 'em, but
since nearly all -are- defined, let's just go ahead and
round out the set."
Most text books she's seen show CLOSE returning NIL.
One text book shows it returning T.
Since some people like to think of T as success and NIL
as failure, maybe it should always return T.
(See Issue: CLOSED-STREAM-OPERATIONS.)
∂09-Dec-88 0057 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:57:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:56:50 PST
Date: 9 Dec 88 00:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
reply-to: CL-CLEANUP@Sail.Stanford.EDU
Message-ID: <881209-005650-5575@Xerox>
This is a very difficult issue.
This writeup was distributed at the November 1987 meeting,
and at the October 1988 meeting.
There is another writeup, labelled Issue: SETF-PLACES which
will follow.
The following comments have not been incorporated into
this poposal:
Instead of generalizing SYMBOL-FUNCTION, add FDEFINITION and leave
SYMBOL-FUNCTION alone.
Do not modify TRACE and UNTRACE. Leave them implementation-dependent.
!
Issue: SETF-FUNCTION-VS-MACRO
References: SETF rules for what -place- can be (pp.94-7)
COMPILE function (p.438)
DEFUN macro (p.57)
DISASSEMBLE function (p.439)
DOCUMENTATION function (p.440)
FBOUNDP function (p.90)
FLET special form (p.113)
FMAKUNBOUND function (p.92)
FTYPE declaration (p.158)
FUNCTION special form (p.87)
FUNCTION declaration (p.159)
INLINE declaration (p.159)
NOTINLINE declaration (p.159)
LABELS special form (p.113)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
TRACE macro (p.440)
UNTRACE macro (p.440)
Category: ADDITION
Edit history: Version 1, 13-Oct-87 Moon
(based on discussion among the CLOS working group)
Version 2, 26-Oct-87 Masinter, minor mods
Version 3, 4-Nov-87 Moon, small clarifications at KMP's urging
PROBLEM DESCRIPTION:
The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand. It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.
PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS):
Add to Common Lisp the concept of "setf functions". Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf. Terminology:
- a "setf macro" is something that produces code (or other
specifications, as in define-setf-method) which, when evaluated,
will perform the effect of an invocation of setf.
- a "setf function" is something that is called to perform
directly the effect of an invocation of setf.
The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function. The name of this setf function
is a list (setf -name-), where -name- is a symbol. The body of this
function is surrounded by an implicit block named -name-.
The functions, macros, special forms, and declarations defined in CLtL
and listed in the References section above need to be enhanced to accept
such lists in addition to symbols as function names, so that setf
functions can be defined and manipulated.
A setf function receives the new value to be stored as its first
argument. Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.
A setf function must return its first argument, since setf is defined
to return the new value.
A definition of a setf function can be lexically local, like a
definition of a reading function. The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules. These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT. Only
rule 4 is new with this proposal.
Rules for the macroexpansion of (setf (foo x) y):
(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.
(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.
(3) If the function-name foo is defined as a special form in the current
scope, signal an error.
(4) Expand into the equivalent of
(let ((#:temp-1 x) ;force correct order of evaluation
(#:temp-2 y))
(funcall #'(setf foo) #:temp-2 #:temp-1))
Note that rule 4 is independent of the scope of the function name
(setf foo). It does not matter if that scope is different from the
scope of the function name foo. This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.
The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.
Normally one does not define both a setf function and a setf macro
for the same reading function.
Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.
In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function. This means that the setf function
only needs to be defined at run time, not compile time.
What CLtL says about (documentation foo 'setf) will not change.
Specifically, the setf documentation type applies just to defsetf (and
define-setf-method, that's an omission in CLtL). The documentation for
a setf function, as for any function, is retrieved by
(documentation '(setf foo) 'function).
Examples:
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars (cdr form) (list new-value)
`(funcall #'(setf ,(car form))
,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
RATIONALE:
By making the names and arguments of setting functions explicit, CLOS is
considerably simplified. In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.
Current code that resembles
(defsetf foo |setf FOO|)
(defun foo (x) ..)
(defun |setf FOO| (x new) ..)
or
(defsetf foo internal-foo-setter)
(defun foo (x) ..)
(defun internal-foo-setter (x new) ..)
can be, but is not required to be, replaced with the following code
(defun foo (x) ..)
(defun (setf foo) (new x) ..)
An advantage of this is that several disparate styles of using
DEFSETF can be replaced with a single common style of using
setf functions, making programs more standardized and readable.
CURRENT PRACTICE:
A few Common Lisp implementations already have a similar feature,
in that they allow setting functions named (SETF reader). We don't
know of any implementation that has precisely the proposed feature.
ADOPTION COST:
The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols. Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.
The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.
This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.
COST OF NON-ADOPTION:
Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System. Some major rethinking of CLOS would be
required.
BENEFITS:
Allow CLOS to be defined without out-of-hand complexity.
Improve usability of SETF.
CONVERSION COST:
None, this is an upward-compatible change.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new
feature, but otherwise they will still work.
ESTHETICS:
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
DISCUSSION:
Note that in Common Lisp, setf macro expansion is an operation on
function names, not on functions. It differs from some dialects of
Scheme, such as T, in this respect. This proposal does not attempt to
change that.
There was some concern about introducing the notion that the name of the
setf-function associated with FOO should be a list, (SETF FOO). This is
a considerable extension to the idea of a "function name", at least for
standard Common Lisp implementations that do not implement Lisp machine
style function-specs.
However, the CLOS unsuccessfully tried a number of alternatives.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it. Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF. Another reason for making the name explicit is to
allow one to use FLET for the setf function -- something which would be
difficult if there is not a name-like entity that can be bound.
This proposal is not incompatible with other extensions to function
specifications present in some implementations.
The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:
a) Lexically local setf macros, that is, a cross between DEFSETF and
MACROLET. This does not appear to be logically necessary. Would all
three ways of defining lexically global setf macros need local
counterparts?
b) Define the meaning of defmacro or macrolet of (setf foo)?
This would be a fourth way to define a setf macro.
c) Enhance the definition of global setf macros, for example to
say that (MACRO-FUNCTION '(SETF FOO)) returns an expander function
that takes two arguments and returns five values.
d) Introduce a new name for SYMBOL-FUNCTION, since it accepts
non-symbols now.
e) Should one allow these extended function names in the car-position
of an expression to be evaluated? The extra complexity didn't seem
justified, instead, an explicit FUNCALL is required.
----- End Forwarded Messages -----
∂09-Dec-88 0119 X3J13-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:19:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:13:30 PST
Date: 9 Dec 88 01:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
In-reply-to: masinter.pa's message of 9 Dec 88 00:56 PST
To: x3J13@Sail.Stanford.EDU
Message-ID: <881209-011330-5598@Xerox>
At the last meeting, our notes are that an amendment was offered and accepted:
" Remove SYMBOL-FUNCTION, TRACE and UNTRACE from the list of affected
functions.
Add a new function:
FDEFINITION <spec> [Function]
The current global function definition named by <spec> is returned.
It is an error if the <spec> has no function definition.
<spec> must be either a symbol or a list of the form (SETF <symbol>).
FDEFINITION may be used with SETF to alter the global function
definition.
"
This amendment was not been incorporated into Version 3.
∂09-Dec-88 0059 X3J13-mailer Issue: SETF-PLACES (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 00:59:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 00:58:47 PST
Date: 9 Dec 88 00:58 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SETF-PLACES (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-005847-5576@Xerox>
The following is the emmendation of SETF-FUNCTION-VS-MACRO that was
discussed at the Fairfax meeting; it incorporates the suggestions
made there by Gregor, Bob Kerns, and myself. Eric Benson and Patrick
Dussud here at Lucid have also reviewed it.
I've started it out under a different issue name, since it is such
a drastic change; but I wouldn't object at all if someone wants it
to be just another version of SETF-FUNCTION-VS-MACRO.
-- JonL --
!
Issue: SETF-PLACES
References: SETF rules for what a place-specifier can be; CLtL pp.94-7
X3J13 88-002R:
Accessing Slots, Ch. 1 p.11
DEFGENERIC Ch. 2 pp.26-9
DEFMETHOD Ch. 2 pp.39-41
(SETF DOCUMENTATION) Ch. 2 pp.43-5
ENSURE-GENERIC-FUNCTION Ch. 2 pp.46-7
GENERIC-FLET Ch. 2 p.52
GENERIC-LABELS Ch. 2 p.55-6
WITH-ADDED-METHODS Ch. 2 pp.90-1
Related issues: SETF-FUNCTION-VS-MACRO
Category: ADDITION
Edit history: Version 1, 11-Nov-88, by JonL
Problem description:
Common Lisp explicitly refrains from giving names to accessor update
functions. The intent is that the macro SETF should shield the user
from ever having to know such names; the correlation between an accessor
name and its corresponding updator name, or updating code sequence, is
to be established by DEFSETF and DEFINE-SETF-METHOD. Update function
names like SET and RPLACA are retained primarily for backwards
compatibility. See CLtL p.93-4.
However, this is extremely inconvenient for CLOS programing. The rub
is that the functionality of an updator function must be specifiable
"in pieces", by incremental uses of DEFMETHOD distributed throughout
perhaps dozens of files. A single definition using either DEFSETF or
DEFINE-SETF-METHOD is not an acceptable constraint for this style.
A named, generic function is the CLOS interface for doing distributed
code specification.
Furthermore, it is not at all clear where a DEFSETF call for a generic
function should go. Should it be before the first DEFMETHOD on the
update function? should it be bundled into every such DEFMETHOD?
should it be bundled into ENSURE-GENERIC-FUNCTION? Clearly, the first
two options would violate the modularity CLOS has strived so hard to
achieve; and the third violates the optionality of ENSURE-GENERIC-FUNCTION.
The best choice would be to elide the DEFSETF call completely. Some
way is needed to designate an update function, without necessarily
doing a DEFSETF or DEFINE-SETF-METHOD first.
Additionally the simpler form of DEFSETF, which could be used for
almost all generic needs (e.g., slot updating), requires the new-
value argument to be the last argument to the update function.
But in order to be able to discriminate upon the class of the
new-value argument, it cannot be described simply as "last" --
it must come before any &optional and &key arguments. Thus there
is need for some other avenue whereby the new-value argument would
come, say, first in the argument list of the update function.
Finally, the CLOS specification X3J13 88-002R seems to imply
that the CLOS exterior syntax for function specifiers must be
implemented down in the innards of every conforming Lisp
implementation. There is a very large amount of resistance
in the X3J13 group, at present, to any proposal which requires
any non-symbols as ordinary function names; not only do people
object to code like (SYMBOL-FUNCTION '(SOME LIST)), but there
is great reluctance to carry out system-wide modifications to
all places that deal with function names (most of which now
presume that "name" means SYMBOL). Yet is the current opinion
of most of the CLOS subcommittee that the exterior CLOS interface
can be kept intact without requiring the underlying Lisp
implementation to support non-symbols as function names.
Proposal (SETF-PLACES:ADD-SETF-FUNCTIONS)
-- Specify that certain function names are reserved to be "SETF functions",
or "updator functions", for use by SETF expansions. The very existence
of such an updator function is implicitly similar to having done a
DEFSETF [or rather, a modified form of the simple DEFSETF, as explained
next below]. Every accessor function name is uniquely paired with such
an updator name, regardless of whether the updator name ever has a
functional definition. However, these functions do not replace any
previously defined SETF methods, nor override the place specifications
of CLtL section 7.2; they simply provide a default expansion for SETF,
as described below.
-- Specify that such a a SETF function must take one more argument than
its corresponding access function. Let <access-fn> and <update-fn>
be such a correlated pair; then when SETF is given a "place" that is
a call on <access-fn>, it expands into a call on <update-fn> that is
given all the arguments to <access-fn> and also, as its very first
argument, the new-value (which must be returned by <update-fn> as
its value). For example, suppose that ASET is the updator function
name corresponding to AREF. Then
(SETF (AREF a i1 i2 ... in) value)
could expand into
(ASET value a i1 i2 ... in)
-- Extend the set of valid "place specifiers" as defined on CLtL p.94-7
by adding the following clause after all the existing ones:
For any other place specifier, the form
(SETF (<access-fn> A1 A2 ... AN) NEW-VALUE)
will expand into a call to the uniquely-named updator function
corresponding to <access-fn>, that is to the function named by
(UNDERLYING-NAME '(SETF <access-fn>)).
Note that SETF will no longer signal any "unknown place specifier"
errors during macroexpansion, because the default behavior is to
simply construct a call to the setf function [except, however, when
"access-fn" isn't legal as the name of a function; for example,
(setf ((spaz) i1 i2) value) is still syntaticly illegal]. But if
at run time, the "setf function" still hasn't been defined as a
function [such as by DEFUN, DEFMETHOD, setf of SYMBOL-FUNCTION etc.],
then a run-time "undefined function" error may occur.
Note also that not every SETF method for an accessor function can be
defined using an updator function. For example, LDB cannot be handled
this way, even if its corresponding update name is a defined function;
LDB must be handled by DEFINE-SETF-METHOD, and as such the prior rules
of CLtL p.94-7 would apply.
-- Be reminded that the rules for interpreting SETF place specifiers
are actually embodied in the functions GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than in the SETF macro
itself. Thus these two functions must be altered to reflect the new
"place specifier" called for just above. Since the rules on p.94-7
of CLtL are to be applied in order, then SETF functions will only be
used when no SETF "method" has been defined for the name, such as by
calling DEFINE-SETF-METHOD or DEFSETF; also, a macro definition for
the access name will block the use of the SETF function, since the
macro call must be expanded first. Remember also that such a updator
name may have a lexically local definition, as well as (or in addition
to) a global one.
-- Add a new function, UNDERLYING-NAME of one argument; and also add an
inverse for this function, UNDERLYING-NAME-TO-SPEC of one argument.
UNDERLYING-NAME is defined as:
(i) on any list like (SETF <name>), it returns a unique,
implementation-dependent name suitable for actual use as
a function name in that implementaion.
(ii) on symbols, it is the identity function; and
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
UNDERLYING-NAME-TO-SPEC is defined as:
(i) on any argument which specifically is the output of part (i)
above [i.e., an "underlying" name], it returns (SETF <name>);
thus the argument is the unique name which is EQUAL to
(UNDERLYING-NAME '(SETF <name>)).
(ii) on any symbol or list not covered by part (i) just above, it
returns it's argument.
(iii) on any other data, it is undefined; however, other lists
like (<spec-kind> ...) should be reserved for extensions
which the x3J13 committee may be considering.
The reason EQUAL is the determiner of "uniqueness" above is that it
is EQ for symbols; and for implementations which have "function specs"
it permits non-EQ copies of (SETF <name>) to be used interchangably.
The result of UNDERLYING-NAME should be constant across "incarnations"
of the same release of an implementation, and should be of a data type
that can be printed out and read back in reliably.
Thus in one implementation, which uses only symbols to name functions,
it might be that:
(UNDERLYING-NAME '(SETF FOO)) ==> SETF:4.USER.FOO
(UNDERLYING-NAME-TO-SPEC 'SETF:4.USER.FOO) ==> (SETF FOO)
whereas in another implementation, which has LispMachine style
"function specs", it would be that:
(UNDERLYING-NAME '(SETF FOO)) ==> (SETF FOO)
(UNDERLYING-NAME-TO-SPEC '(SETF FOO)) ==> (SETF FOO)
-- Alter all the above-referenced documentation in the CLOS specification
so as not to imply that lists are suitable as function names. In
particular,
(a) phrases like "... if <function-specifier> names a function" should
be changed to a phrase like "... if <function-specifier> refers to
a defined function", or possibly even something like
"... if (UNDERLYING-NAME <function-specifier>) names a function"
(b) phrases like "(FBOUNDP <function-specifier>)" should be changed
into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
else other terminology should express the intent of what is to
be said. For example, instead of saying: "When (FBOUNDP <f-s>)
is true ..." one could just as well say "When <f-s> refers to
a defined function ..." The choice of which of these two formats
to use is an editorial one.
(c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
or else other terminology should express the intent of what is to
be said. For example, one might say "... the function referred
to by <f-s>". The choice of which of these two formats to use is
an editorial one.
Since the concept of a standard expansion for DEFMETHOD has been
accepted, then it is clear that a form like
(DEFMETHOD (SETF FOO) ...)
will expand exactly the same as
(DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
The underlying call to ADD-METHOD will see the real function name used
for the updator function. The user-level interface of CLOS can still
present the list format as acceptable; it is only the implementation of
DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
"real" name.
One expected use of UNDERLYING-NAME-TO-SPEC is in Lisp-level debuggers,
which could try to print out something more user-comprehensible than
the very internal names that an implementation might use in place of
function specs.
Examples:
;;; If CLtL did not already prescribe a SETF expansion for SUBSEQ calls,
;;; it could be defined like this:
(setf (symbol-function (underlying-name '(setf subseq)))
#'(lambda (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value i)))))
or, for implementations that have "function specs", this could be writen:
(defun (setf subseq) (new-value sequence start &optional end)
. . .)
;;; Here's an example using a local function. First, define
;;; MIDDLE-REF to be an accessor function as follows. [Assume
;;; also that MIDDLE-REF's home package is BAR.]
(defun middle-ref (vec i)
(check-type i fixnum)
(aref vec (ceiling i 2)))
;;; Now let SETF:3.BAR.MIDDLE-REF be the (implementation-dependent)
;;; updator function name corresponding to MIDDLE-REF; a normal
;;; definition of an update function for MIDDLE-REF could be:
(defun setf:3.bar.middle-ref (new-element vec i)
(check-type i fixnum)
(setf (aref vec (ceiling i 2)) new-element))
;;; But the SETF below will call FILL, because of the local definition
;;; of SETF:3.BAR.MIDDLE-REF; and nowhere have we have made any
;;; explicit call to DEFSETF or DEFINE-SETF-METHOD for MIDDLE-REF.
(flet ((setf:3.bar.middle-ref (new-element vec i)
;;"wide-body" version of set-middle-ref
(declare (ignore i))
(fill vec new-element :end (ceiling i 2))))
(setf (middle-ref "abc" 1) #\z))
;;; The following function could be called by GET-SETF-METHOD, to
;;; implement SETF functions, when none of the other rules of CLtL
;;; p.94-7 apply.
(defun get-setf-method-for-setf-functions (form)
(let* ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v)))
((access-fn (car form)))
((update-fn (underlying-name `(SETF ,access-fn)))))
(values temp-vars
(cdr form)
(list new-value)
`(,update-fn ,new-value ,@temp-vars)
`(,access-fn ,@temp-vars))))
;;; For those implementations using "function specs", the form:
;;; `(,update-fn ,new-value ,@temp-vars)
;;; would probably have to be replaced by:
;;; `(FUNCALL #',update-fn ,new-value ,@temp-vars)
Rationale:
The paragraphs of the "Problem description:", except for the first,
describe four major problems with the status quo -- three concerning
the unsuitability of current SETF methods for supporting the CLOS
generic style, and one for an unintended presumption that every
implementation of CL will have "function specs". This proposal
corrects these problems, without adding any significant new ones.
Current practice:
Some implementations have "function specs", so that forms like
(SETF FOO) are permitted to name functions; but none have extended
the setf place specifiers as proposed herein.
Cost to Implementors:
Basically, none. Implementations which already have Lisp Machine
style "function specs" can just define UNDERLYING-NAME and
UNDERLYING-NAME-TO-SPEC as the identity function. For those without
such capabilities, there is a portable implementation listed in the
discussion section.
Extending GET-SETF-METHOD etc. to handle SETF functions should be a
very modest task at most.
Cost to Users:
This is basically an upward-compatible addition, so there should be
no cost to users [at least not for correct programs -- incorrect
SETF expansions will no longer be signalled at macroexpand time,
but may simply result in a runtime error for undefined function.]
Cost of non-adoption:
Non-adoption of this proposal would be a significant setback for the
Common Lisp Object System. There seems to be no agreeable alternative
for implementing generic setf methods.
Performance impact:
N.A.
Benefits:
See "Cost of non-adoption".
Esthetics:
This proposal increases the size of the definition of SETF; but
it greatly simplifies the "default" case, namely just defining
an updator function to correspond to an accessor.
Discussion:
The following code can be used by an implementation which doesn't
have "function specs" to implement the new functions:
;;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: SYSTEM; Base: 10 -*-
;;;
;;; Author: JonL White, 15-Nov-88
;;;
(in-package "SYSTEM") ;or, your development package
(eval-when (eval compile load)
;;; The SETF package should be reserved for this purpose
;;;
(or (find-package "SETF")
(make-package "SETF" :use nil))
(defparameter *setf-package* (find-package "SETF"))
(unless (and (null (package-use-list *setf-package*))
(null (package-used-by-list *setf-package*)))
(error "SETF package has connections?"))
;;; "Internal Markers", to be used for uninterned symbols.
;;;
(export (intern "SETF-SPEC" *setf-package*) *setf-package*)
(export (intern "SETF-NAME" *setf-package*) *setf-package*)
)
(eval-when (eval compile)
(defmacro setf-spec-p (x)
(let ((spec (gensym)))
`(LET ((,spec ,x))
(AND (CONSP ,spec)
(EQ (CAR ,spec) 'SETF)
(CONSP (CDR ,spec))
(NULL (CDDR ,spec))
(SYMBOLP (SECOND ,spec))))))
)
(defun UNDERLYING-NAME (spec)
(cond
((symbolp spec)
spec)
((setf-spec-p spec)
(let* ((accessor (second spec))
(accessor-name (symbol-name accessor))
(home-package (symbol-package accessor)))
(if home-package
(let* ((package-name (package-name home-package))
;; 'spec-name' is a form like "~D.~A.~A", but FORMAT has a
;; problem with global print parameters like *print-radix*
(spec-name (concatenate 'string
(write-to-string (length package-name)
:radix nil :base 10 :length nil :level nil)
"."
package-name
"."
accessor-name))
(updator (or (find-symbol spec-name *setf-package*)
(let ((sym (intern spec-name *setf-package*)))
(export sym *setf-package*)
sym))))
;; A possible optimization, which trades off space for time, is
;; as follows; see definition of UNDERLYING-NAME-TO-SPEC below
;;(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)
(or (get accessor 'setf:setf-name)
(let* ((uname (concatenate 'string "SET-" accessor-name))
(updator (make-symbol uname)))
(setf (get accessor 'setf:setf-name) updator)
(setf (get updator 'setf:setf-spec) (copy-list spec))
updator)))))
(t
(error "~S is an invalid arg for ~S" spec 'UNDERLYING-NAME))))
(defun UNDERLYING-NAME-TO-SPEC (x)
(cond
((not (symbolp x))
(if (setf-spec-p x)
x
(error "~S is an invalid arg for ~S"
x 'UNDERLYING-NAME-TO-SPEC)))
((get x 'setf:setf-spec))
(t
(let ((home-package (symbol-package x)))
(if (not (eq home-package *setf-package*))
x
(let ((name (symbol-name x))
accessor package-name)
;; Unpack the name, which is a form like "~D.~A.~A"
(multiple-value-bind (nchars starti)
(parse-integer name :radix 10 :junk-allowed t)
(incf starti)
(setq package-name (subseq name starti (incf starti nchars)))
(incf starti)
(setq accessor (find-symbol (subseq name starti)
(find-package package-name)))
(unless accessor
(error "~S failed to parse in ~S"
x 'UNDERLYING-NAME-TO-SPEC))
`(SETF ,accessor))))))))
----- End Forwarded Messages -----
∂09-Dec-88 0119 X3J13-mailer Issue: FUNCTION-DEFINITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:19:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:11:17 PST
Date: 9 Dec 88 01:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-DEFINITION (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-011117-5596@Xerox>
!
Issue: FUNCTION-DEFINITION
References: Issue FUNCTION-TYPE
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
09-Dec-88, Version 2 by GZ (change name, remove REQUIRED
option, specify first value to be a lambda, add to
discussion and current practice)
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
In many cases, it used to be possible to recover the lambda expression
after a DEFUN by using FUNCTION or SYMBOL-FUNCTION, but the passage of
FUNCTION-TYPE will make this no longer be the case.
Proposal (FUNCTION-DEFINITION:FUNCTION-SOURCE):
Introduce a new function called FUNCTION-SOURCE which takes as
its argument a function and returns three values:
#1: The function's defining lambda expression, or NIL if the information
is not available. The lambda expression may have been pre-processed
in some ways, but it should remain a suitable argument to COMPILE
or FUNCTION.
#2: NIL if the definition was enclosed in the null lexical
environment or something non-NIL if the definition might
have been enclosed in some non-null lexical environment.
#3: the `name' of this function. The name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations are free to always return NIL T NIL, but are encouraged
to return the lambda expression in the case where the argument was created
by an in-core call to COMPILE or EVAL (as opposed to being created by
loading a compiled file).
Examples:
The following examples illustrate some possible return values, but
are not intended to be exhaustive:
#1: (FUNCTION-SOURCE #'(LAMBDA (X) X))
or (FUNCTION-SOURCE (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-SOURCE (FUNCALL #'(LAMBDA (X) #'(LAMBDA () X)) NIL))
might return NIL, T, NIL
or (LAMBDA () X), T, NIL
but -not- (LAMBDA () X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION 'BAR) #'FOO)
(FUNCTION-SOURCE #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) (BLOCK FOO X)), T, NIL
or (LAMBDA (X) (BLOCK FOO X)), NIL, FOO
or (SI::BLOCK-LAMBDA FOO (X) X), NIL, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-SOURCE (FOO))
might return NIL, T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, NIL
or (LAMBDA (X) (BLOCK BAR X)), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) (BLOCK BAR X)), NIL, "BAR in FOO"
Rationale:
This functionality would be useful to a pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
The following implementation is technically legitimate, although many
implementations would want to provide something more useful:
(DEFUN FUNCTION-SOURCE (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL T NIL))
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information. VAXLISP and
Lucid call it SOURCE-CODE. Coral calls it UNCOMPILE-FUNCTION.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
The initial name proposed for this function was FUNCTION-DEFINITION. This
was changed because of technical uses of the term ``definition'' to refer
to the entire defining form (e.g. a DEFUN form) rather than the lambda
expression that might be recovered from it.
The possibility of _requiring_ the lambda expression to be available for
all functions created by in-core calls to COMPILE or FUNCTION was considered
but didn't receive much support. Pitman would prefer that option because
it is considerably more useful in practice, but would like to see at least
the current proposal.
∂09-Dec-88 0133 X3J13-mailer Issue: STREAM-ACCESS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 01:32:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 01:31:00 PST
Date: 9 Dec 88 01:30 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: STREAM-ACCESS (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-013100-5620@Xerox>
!
Issue: STREAM-ACCESS
References: streams (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 17-Jun-88, version 1 by Walter van Roggen
30-Nov-88, version 2 by Masinter
Problem Description:
There are many components of streams which are specified upon creation
but are not accessible afterwards. Furthermore there is no way in
Common Lisp to determine the type of a stream to see if it has particular
components, or even if it is OPEN.
The accessors wanted are those associated with broadcast streams,
concatenated streams, echo streams, file streams, string streams,
synonym streams, two way streams.
There are three proposals, which differ only by the whether
they include types, type predicates, or both, in addition to
the stream component acessors. Ballots can be either for
one of the proposals or none. (Other combinations of, say,
accessors without either predicates or types, or types without
accessors, do not seem reasonable and are not being proposed
at this time.)
Proposal STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
First, add a function to determine whether a stream is "OPEN":
OPEN-STREAM-P stream [Function]
Returns T if a stream is open, NIL if it is closed. It is an error
if the argument is not a stream.
Streams are "open" until they have been closed with
CLOSE, or, the dynamic context of the creating/accessing
macros of WITH-OUTPUT-TO-STRING, WITH-OPEN-FILE,
WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM,
have been exited.
There are three kinds of things to add associated with each kind of
stream: data types, predicates, accessors.
Stream data types:
BROADCAST-STREAM (returned by MAKE-BROADCAST-STREAM)
CONCATENATED-STREAM (returned by MAKE-CONCATENATED-STREAM)
ECHO-STREAM (returned by MAKE-ECHO-STREAM)
FILE-STREAM (returned by OPEN or created by WITH-OPEN-FILE)
STRING-STREAM (returned by MAKE-STRING-INPUT-STREAM,
MAKE-STRING-OUTPUT-STREAM, and created by WITH-INPUT-FROM-STRING
and WITH-OUTPUT-TO-STRING and FORMAT with second argument NIL)
SYNONYM-STREAM (created by MAKE-SYNONYM-STREAM)
TWO-WAY-STREAM (created by MAKE-TWO-WAY-STREAM)
The stream data types are all subtypes of type STREAM and are mutually
exclusive. (In particular, a synonym stream is only of type SYNONYM-STREAM.)
Stream Predicates:
Each of these returns T if the object is of the corresponding type,
and NIL otherwise.
BROADCAST-STREAM-P, CONCATENATED-STREAM-P,
ECHO-STREAM-P, FILE-STREAM-P, STRING-STREAM-P,
SYNONYM-STREAM-P, TWO-WAY-STREAM-P
Note that the predicates do not "follow the link" of a synonym
stream.
Stream Informational Functions:
BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams
This function returns a list of output streams that constitute
all the streams the broadcast stream is broadcasting to. It is
an error if the argument is not of type BROADCAST-STREAM.
CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams
This function returns a list of input streams that constitute
the ordered set of streams the concatenated stream still has to
to read from, starting with the current one it is reading from.
The list may be () if no more streams remain to be read.
It is an error if the argument is not of type CONCATENATED-STREAM.
ECHO-STREAM-INPUT-STREAM echo-stream ==> input-stream
ECHO-STREAM-OUTPUT-STREAM echo-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type ECHO-STREAM.
SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol
This function returns the symbol whose SYMBOL-VALUE the
synonym stream is using. It is
an error if the argument is not of type SYNONYM-STREAM.
TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> input-stream
TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> output-stream
These functions return the corresponding component stream. It is
an error if the argument is not of type TWO-WAY-STREAM.
Proposal: STREAM-ACCESS:ADD-TYPES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to leave out the
stream type predicates.
Proposal: STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Identical to ADD-TYPES-PREDICATES-ACCESSORS except to not
identify new data types. The accessors act as if the types were specified
(i.e., are mutually excusive).
Current Practice:
VAX LISP implements ADD-TYPES-PREDICATES-ACCESSORS.
We have not surveyed other implementations.
Cost to Implementors:
All of the proposals are reasonably simple to implement, since the information
must be present for nearly all types.
Cost to Users:
The proposals are upward-compatible, and should have little impact.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
Discussion:
This issue has come up frequently, particularly dealing with SYNONYM-STREAMs.
The behavior of OPEN-STREAM-P on, for example, broadcast streams, might
be specified in a variety of alternative ways. This specification seems the simplest.
There are three proposals for voting because there was no agreement at the
October X3J13 on the issue of whether types, predicates, or both should be
added.
There was a proposal at one time to add a new function FOLLOW-SYNONYM-STREAM
which could be written as
(defun follow-synonym-stream (x)
(if (synonym-stream-p x)
(follow-synonym-stream (symbol-value (synonym-stream-symbol x)))
x))
i.e., which chases through zero or more synonym stream indirections.
∂09-Dec-88 1008 X3J13-mailer Issue: STREAM-INFO (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:07:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:03:19 PST
Date: 9 Dec 88 10:02 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: STREAM-INFO (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-100319-6354@Xerox>
An amendment to this proposal is under consideration, to change
the following names:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
("PRINTED-WIDTH is misleadingly named (in my opinion) because the function PRINT
is not involved. STREAM-WRITTEN-WIDTH looks a little weird.)
!
Forum: Cleanup
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to
discussion)
30-Nov-88, Version 6 by Masinter (add discussion)
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS:
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a number representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative number. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns a number representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been
exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it
should have the same line-width and width unit as the base output
stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written
portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
This issue probably should have been called PRETTY-PRINT-WIDTH-SUPPORT.
Dick Waters (author of GPRINT, a portable pretty printer), originally
raised this issue.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum required to support
pretty printing into a stream which displays output using a variable width
font.
Originally the functions were defined to return integers; however, there
are some output devices (e.g., those that have arbitrary scaling
operations), for which it would be difficult to find a reasonable
least-common-denominator for line-width.
We considered an alternate proposal which goes significantly beyond what is
needed merely for pretty printing and provides primitives
LINE-DIMENSIONS, LINE-POSITION, PRINTED-DIMENSIONS, and WRITE-SPACE but
it is not included here. A key point of contention was the question of how
to handle the issue of vertical distance (where is the origin, which way
do you count, ...).
We considered requiring PRINTED-WIDTH to return two additional values:
the number of newlines that WRITE-STRING of the string would execute and
the maximum X position encountered (which might differ from the first value
if the number of newlines was non-zero).
This feature wasn't strictly necessary for pretty-printing, and so was
omitted.
Some of the draft proposals from the character committee contained some
proposed functions that were attempting to solve the same problem.
Conflicting proposals should be avoided.
∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-DECLARE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:47:13 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:32:48 PST
Date: 9 Dec 88 10:32 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SYMBOL-MACROLET-DECLARE (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-103248-6444@Xerox>
!
Issue: SYMBOL-MACROLET-DECLARE
References: SYMBOL-MACROLET (88-002R page 2-81)
WITH-ACCESSORS (88-002R page 2-88)
WITH-SLOTS (88-002R page 2-92)
Related Issues: SYMBOL-MACROLET-SEMANTICS
FLET-DECLARATIONS (passed)
Category: ADDITION
Edit history: Version 1, 12-Sep-88, Moon
Version 2, 9-Dec-88, Masinter
(add cross reference, discussion)
Problem description:
It would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet. A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.
Example:
See problem description.
Rationale:
If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations. When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration. However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.
Current practice:
SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
Cost to Implementors:
Less than one man-hour.
Cost to Users:
None.
Cost of non-adoption:
Minor wart in the language.
Benefits:
More consistent language definition.
Esthetics:
More consistent language definition.
Discussion:
This issue is related to SYMBOL-MACROLET-SEMANTICS.
"A macro-definition for SYMBOL-MACROLET would leave the issue of
DECLARE open. But the special-form version of SYMBOL-MACROLET
really should address it."
∂09-Dec-88 1047 X3J13-mailer Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 10:47:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 10:40:52 PST
Date: 9 Dec 88 10:40 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: SYMBOL-MACROLET-SEMANTICS (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-104052-6470@Xerox>
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable CommonLoops (PCL) provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
∂09-Dec-88 1407 X3J13-mailer Caveat on "From: cl-cleanup..."
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:06:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 DEC 88 13:52:02 PST
Date: 9 Dec 88 13:50 PST
From: masinter.pa@Xerox.COM
Subject: Caveat on "From: cl-cleanup..."
To: X3J13@sail.stanford.edu
Message-ID: <881209-135203-1007@Xerox>
While many of the issues distributed for your consideration have been
considered at length, a significant percentage have had last-minute changes
with little or no review by other cleanup committee members.
The urgency of getting items ready for voting coupled with the vacation and
work schedules of cleanup committee members has caused more haste than
usual.
∂09-Dec-88 1406 X3J13-mailer Issue: TAGBODY-CONTENTS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 14:06:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 13:39:52 PST
Date: 9 Dec 88 13:39 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TAGBODY-CONTENTS (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-133952-701@Xerox>
!
Forum: Cleanup
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
05-Oct-88, version 4 by Pitman
(modify proposal based on comments from Peck@Sun
-- allow both (GO NIL) and unused duplicated tags)
9-Dec-88, Version 5 by Masinter (wording per Pitman)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
A TAGBODY's body may contain arbitrary data elements; no
constraints are placed on duplication of those elements.
duplications. Elements that are lists (CONSP) are evaluated in
left-to-right order. Any other elements are ignored by TAGBODY. However,
GO is only legal when the given a tag that is a symbol or integer. The results
of executing GO when there is more than one instance of the same (EQL)
tag at the top level of the innermost TAGBODY containing that tag are
unspecified.
In particular it is an error to use a character, floating point number,
ratio or other data element as a tag to GO.
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Examples:
;; legal, but useless
(TAGBODY 3.4 4.5 (print "hi there"))
;; not legal
(tagbody
(ecase char (#\a (go #\a)) (#\b (go #\b)))
#\a (print "Apple")
#\b (print "Ball"))
;;legal, even when args are NIL:
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
;; legal, but bad style
(do (...)
(...)
-----
(...)
(...)
-----
(...))
Rationale:
The proposed set of tags is expressionally adequate.
Other candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Duplicated tags are permitted in situations where no GO is done
to them; it is not our intent particularly to encourage the
practice. . But current practice is to permit such uses in
many implementations, and there was no driving
reason to force such code to break.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
The TI Explorer permits using NIL as a GO tag, but as a special case,
does not warn about multiple appearances of NIL.
Many implementations allow duplicate tags if there is no GO to them.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Implementations that disallow duplicate tags (generally in the
compiler but not the interpreter) will have to remove the
error checks.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), other (likely minor) changes will be
necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This issue was first included in in ">GLS>clarifications.text"
of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
∂09-Dec-88 1531 X3J13-mailer Issue: TEST-NOT-IF-NOT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 15:31:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 15:30:26 PST
Date: 9 Dec 88 15:26 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TEST-NOT-IF-NOT (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-153026-1243@Xerox>
This issue has two proposals.
Some people have indicated that they will vote for
one of these only conditionally, e.g.,
"Yes, if you change "REMOVE" to "DEPRECATE" and define the
term "DEPRECATE" in a way that permits the retention of these
primitives for the near term with intent to phase them out
later."
!
Forum: Cleanup
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Related Issue: FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Performance impact:
Very small; removing the :TEST-NOT keywords would
make the simple implementation of the functions that
used to have them slightly faster, but the resulting
code of the inner loop is likely to be much slower.
Discussion:
Many people objected strongly to both of these proposals --
they might have been a nice idea five years ago, but are
gratuitous incompatibilities now: incompatible changes with
insufficient payback.
Some of those objections might be tempered if some additional
changes were made to Common Lisp: adding a COMPLEMENT
function, or if there were a strategy to declare some parts of the
language "obsolete". Since these conditions haven't been done,
their objections stand.
Steele noted that one main reservation to FLUSH-ALL is that
he uses REMOVE-IF-NOT much more than REMOVE-IF.
This issue is related to FUNCTION-COMPOSITION, but is not
dependent on it. Some support the combination of FLUSH-ALL and
the NEW-FUNCTIONS part of FUNCTION-COMPOSITION in spite of
the incompatible change because of the aesthetic appeal.
Some people expressed their intention to vote for FLUSH-ALL
only if FUNCTION-COMPOSITION:NEW-FUNCTIONS.
It was noted that and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
The modification of these functions is moot for those who
prefer to use extended LOOP macro/iteration constructs
in lieu of the sequence functions.
Several alternative names for REMOVE-IF-NOT were
suggested: KEEP-IF, ABSTRACT, FILTER. We did not
pursue these suggestions.
∂09-Dec-88 1605 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 16:05:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 15:58:54 PST
Date: 9 Dec 88 15:58 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-155854-1325@Xerox>
This issue arose during the discussion of issue
COERCE-INCOMPLETE, and was only recently cast as
a formal proposal in its own right.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
∂09-Dec-88 1618 X3J13-mailer Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 16:17:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 16:17:10 PST
Date: 9 Dec 88 16:16 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: VARIABLE-LIST-ASYMMETRY (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-161710-1373@Xerox>
!
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: ADDITION
Edit history: 26-Jul-88, Version 1 by Skona Brittain
04-Aug-88, Version 2 by Skona Brittain
08-Oct-88, Version 3 by Pitman
Problem Description:
The syntax of items in the variable-list for various control structues
(do, do*, let, let*, prog, prog*, and compiler-let) varies. This
variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
compiler-let var (var value)
Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms
and compiler-let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
I.e. change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
compiler-let: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(let* (a (b) (c 3)) ... ) would be valid.
(do (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
(compiler-let (a (b) (c 3)) ... ) would be valid.
Rationale:
The asymmetry is unnecessary and impedes learning of CL.
Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*,
would be an incompatible change to the language.
This way just adds the flexibility found in some of the forms to all of them.
Current Practice:
KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.
Cost to Implementors:
Extremely slight. (May involve subtracting code rather than adding it).
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than asymmetry, at least to some of us.
Discussion:
Pitman supports this proposal.
The issue about whether the atomic ``var'' should be allowed at all in the
variable lists for let & let* is a separate issue. (So is whether
it should mean that the var is initially bound to nil.) Since it is allowed,
this proposal merely says that the alternative syntax of an atom within a
list with no initial value, ``(var)'', should also be allowed.
∂09-Dec-88 1705 X3J13-mailer Issue: DECLARATION-SCOPE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 17:05:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 17:00:53 PST
Date: 9 Dec 88 17:00 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DECLARATION-SCOPE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-170053-1466@Xerox>
This issue has two proposals, NO-HOISTING and LIMITED-HOISTING.
!
Issue: DECLARATION-SCOPE
References: Declaration Syntax (CLtL, Section 9.1, pp. 153-157)
LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66)
Cleanup issue FLET-DECLARATIONS (accepted)
Cleanup issue DECLARE-TYPE-FREE (accepted)
Category: CHANGE/CLARIFICATION
Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988
Version 2, Moon, 2-Feb-1988 (edits based on discussion)
Version 3, Moon, 18-Sep-88, for private discussion between JonL and Moon
Version 4, JonL, 15-Nov-88 add 2nd proposal; major rewrite.
Problem description:
The description of the scope of declarations made with DECLARE is
unclear (although unambiguous) and arguably a mistake. At issue is
whether the scope of some or all of the declarations at the head of
a special form includes code appearing in any non-body part of that
special form. CLtL p.155 attempts to address the issue by classifying
declarations into two classes -- "pervasive" and "non-pervasive" -- but
it does not succeed very well.
A particular question of interest is whether the initial value forms for
LET, LET*, FLET, LABELS, DO, PROG etc. are included. The rules of CLtL,
on some cases, are clear enough to see that a declaration inside the
special form is "hoisted" up and around the whole form, so as to include
all the "initial value" forms (and "stepper" forms and "result" forms for
those constructs that have them). This means that lexical argument
variable X in the following function is inaccessible inside the initial
value forms of the LET:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
The declaration intended for the binding of X[3] also alters the
scoping of the reference of X[2]; likely, this was not an intended
consequence. [This is a simplification of the example on CLtL p.155].
In this discussion, the term "body" will include any "stepper" or
"result" forms, such as might be found in a DO or DO-mumble-SYMBOLS
construct. The reasoning for this is that such forms are always
included in the scope of all name bindings (if any) being established
by the special form. They form an extended part of the "body".
Proposal (DECLARATION-SCOPE:NO-HOISTING)
Specify that the scope of a declaration located at the head of a special
form or lambda expression is as follows:
(1) it always includes the body forms [as well as any "stepper" or
"result" forms]
(2) it also includes the scope of the name binding, if any, to which
it applies [LET, LAMBDA, FLET, DO, etc. introduce "name bindings";
LOCALLY doesn't.];
This very straightforward prescription depends on one rather subtle
point, namely that the scope of name bindings is an already solved
question. Whether or not a particular declaration affects an initial
value form (such as for LET or LET*) depends _solely_ on whether it is
applied to a variable or function (name) being bound whose scope
includes such forms. In this sense, the above specification limits the
scope of declarations for name bindings to be exactly the scope of the
name binding itself -- i.e. "like variable". Thus there would be no
"hoisting" of the special declarations in the example cited in the
problem description. [See the Discussion section for a review of the
CL rules on variable/function-name scoping in special forms.]
Those declarations not correlated with any name binding do not cover any
of the initial-value forms; their scope simply includes the body (as well
as any "stepper" or "result" forms). In a sense, the above specification
limits the scope of these kinds of declarations to be the same as an
arbitrary name binding in a LET or FLET construct -- i.e. "like variable".
[See also the issue DECLARE-TYPE-FREE.]
Thus there is to be no "hoisting" for declarations in special forms or
lambda expressions; the only initial value forms affected by a declaration
will be those included indirectly, by the effect, if any, that a
declaration has on a name binding.
A question may arise as to what it means for a declaration to "apply to",
or "be correlated to" a name binding. As stated above about variable
scoping, this is an already solved question in Common Lisp; it is not
the purpose of this proposal to alter, clarify or in any other way bear
upon the basic _applicability_ rules of declarations in Common Lisp.
However, a few reminders about these rules will help one understand the
above specification:
-- SPECIAL and TYPE declarations never apply to function bindings;
-- INLINE and FTYPE declarations never apply to variable bindings;
-- OPTIMIZE never applies to either kind of binding;
-- (<declaration> X) never applies to a binding of Y.
The specific rules are for the most part distributed throughout the
individual declaration definitions. The name-applicibility issue for
bindings must be specified independently of how the declaration scoping
issue is decided, and should not be confused with that scoping issue.
Proposal (DECLARATION-SCOPE:LIMITED-HOISTING)
Specify that the scope of a declaration located at the head of a special
form or lambda expression is as follows:
(1) it always includes the body forms [as well as any "stepper" or
"result" forms]
(2) if the declaration is applicable to a name binding in that form,
then it is limited to exactly the scope of that name binding [LET,
LAMBDA, FLET, etc. introduce "name bindings"; LOCALLY doesn't.];
(3) if the declaration is not applicable to a name binding in that form,
then it includes all the initial value forms, in addition to the
body forms.
This very straightforward prescription depends on one rather subtle
point, namely that the scope of name bindings is an already solved
question. This applies not only to LET and LET* variables, but to the
&optional, &key and &aux variables of LAMBDA-Expressions. In this sense,
the above specification limits the scope of declarations for name bindings
to be exactly the scope of the name binding itself. Thus there would be
no "hoisting" of the special declarations in the example cited in the
problem description.
Those declarations not correlated with any name binding act as if they
were included in a new LOCALLY construct wrapped around the entire
special form. Thus they are not scoped like an arbitrary variable
(or, "name binding") in that special form, but rather are "hoisted" up.
Whether or not a declaration is "hoisted" up around the special form in
which it occurs depends on whether or not it is "captured en passant" by
a correlated name binding.
A question may arise as to what it means for a declaration to "apply to",
or "be correlated to" a name binding. As stated above about variable
scoping, this is an already solved question in Common Lisp; it is not
the purpose of this proposal to alter, clarify or in any other way bear
upon the basic _applicability_ rules of declarations in Common Lisp.
However, a few reminders about these rules will help one understand the
above specification:
-- SPECIAL and TYPE declarations never apply to function bindings;
-- INLINE and FTYPE declarations never apply to variable bindings;
-- OPTIMIZE never applies to either kind of binding;
-- (<declaration> X) never applies to a binding of Y.
The specific rules are for the most part distributed throughout the
individual declaration definitions. The name-applicibility issue for
bindings must be specified independently of how the declaration scoping
issue is decided, and should not be confused with that scoping issue.
Examples:
;;; The following example is from a common-lisp mailing list discussion
;;; (from code suggested by Pavel Curtis). The question is whether or
;;; not the special declaration in FOO applies to the (1+ x) form.
(setf (symbol-value 'x) 6)
(defun foo (x) ;a lexical binding of X
(print x)
(let ((x (1+ x))) ;is the second X special or not?
(declare (special x)) ;`normal' declaration
(bar))
(1+ x))
(defun bar () (print (locally (declare (special x)) x)))
(foo 10) will printout of 10 and 11 by either proposal herein
(foo 10) will printout of 10 and 7 by CLtL style "hoisting"
;;; The following example is due to Jim Boyce, of Lucid Inc. It shows how
;;; the "hoisting" of the declaration inadvertently causes it to act more
;;; like a proclamation than a declaration; namely, the declaration is
;;; applied to two different variables (which happen to have the same
;;; name) -- the first variable is the lexical one bound on line [1] and
;;; the second variables is bound on line [3]. Whereas lexical scoping
;;; rules would say that the reference in line [2] is to the variable
;;; bound on line [1], the effect of the "hoisted" declaration is to
;;; make the line [1]'s variable inaccessible in the initial value forms.
(setf (symbol-value 'x) 6)
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
(bar 'first 'second) ==> (first second) ;by either proposal herein
(bar 'first 'second) ==> (6 second) ;by "hoisting", a la CLtL.
Rationale:
These semantics are simpler to understand. Almost everyone feels that
the example of CLtL p.155 is very unnatural. LIMITED-HOISTING is less
of a change to CLtL semantics; but NO-HOISTING seems more natural to
most people since it restores a closer equivalence between LET forms
and LAMBDA-expressions. Also, several vendors report that customers
frequently seem to assume the semantics of NO-HOISTING.
Current practice:
Most implementations implement the rules in CLtL, as exemplified by
the example on p.155. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future.
Cost to Implementors:
Modest; some minor fixes will be necessary to to compilers, interpreters
and "code walkers" that parse declarations.
Cost to Users:
Modest. It is mostly moot since users tend to avoid the "hoisting"
situations on special declarations.
It is possible to mechanically examine a program to determine whether
its behavior would change under the new rules. This permits an
implementation to provide a transition tool to ease conversion to the
new definition.
Cost of non-adoption:
Serious non-portability of code, since not every implementor seems to
agree on how to read the disputed rules of CLtL pp. 153-157; continuing
confusion in the user community.
Performance impact:
None.
Benefits:
Elimination of confusion; increase of portability between implementations.
Esthetics:
Simplifies the scoping issue; eliminates special-case scoping rules for
SPECIAL declarations.
Discussion:
Only the SPECIAL declaration has semantic import for CL; both
proposals specify an incompatible change for this case, to "retract"
the expansive scope stated or implied in CLtL. All other declarations
are considered "advice" to an optimizing compiler, and should have
no semantic effect on correct programs. However, programmers making
use of such declarations may notice a larger difference in the
NO-HOISTING proposal, since some of their INLINE, OPTIMIZE, TYPE,
etc. declarations will no longer apply to the initial-value forms.
One idiom which will be adversely affected by both of these proposals is:
(let ((*a* *a*))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
where *a* has not been proclaimed special. This idiom would likely
have to be written as:
(let ((*a* (locally (declare (special *a*)) *a*)))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
or [preferably!] *a* should be proclaimed special. Similar idiots
like this may be in use for LAMBDA-Expressions, or DEFUNs etc.
On the other hand, the inadvertent "shadowing" which prevents the
following LET's initial value forms from referencing the input argument
is handily solved by either proposal herein. If neither of these
proposals is not adopted, then the intent of the code for BAR:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x) ;[2] 2nd instance of x -- same as 1st instance?
(x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x)))
would likely have to be expressed by introducing new LET contours:
(defun bar (x y) ;[1] 1st instance of x
(let ((old-x x)) ;[2] 2nd instance of x -- same as 1st instance?
(let ((x y)) ;[3] 3rd instance
(declare (special x))
(list old-x x))))
The source of additional confusion has long been that TYPE declarations
had to be treated differently from all other declarations; this was because
of the prohibition found on p158 of CLtL. Given the acceptance of the
DECLARE-TYPE-FREE proposal, it no longer is necessary to make an exception
for it, nor to categorize declarations into "pervasive" and "non-pervasive",
or "free" and "bound".
It is not the purpose of this proposal to alter, clarify or in any
other way bear upon the scoping rules of variables in Common Lisp.
However, a few reminders about these rules will help one understand
the above prescription. Except LET*, PROG*, DO*, LABELS, and MACROLET,
all the other special forms of CLtL p154 which admit declarations have
the property that the scope of the name binding does not include any
initial value form. As a review of these scopes, note:
-- for LET, FLET, MULTIPLE-VALUE-BIND, none of the initial value
forms are included in the variables' (or functions') scope;
-- for DO-<mumble>-SYMBOLS, the initial value forms are not included,
but the optional result forms are included;
-- for DO, DOLIST, and DOTIMES, the initial value forms are not
included, but the stepper forms and the optional result forms
are included;
-- for LET*, PROG*, and DO*, a variable's scope also includes the
remaining initial value forms, for subsequent variable bindings;
-- for LABELS and MACROLET, a function name's scope includes all the
code forms for the functions being defined by the special form
[a compiler writer must know how not to get into an infinite loop
of substitutions when there are 'in-line' declarations on these
mutually recursive names];
-- for a LAMBDA application, none of the explicit value forms are
included in the bound variable scoping; however, the 'initform'
code (if any) for &optional, &key, and &aux bindings are included
in the same way as LET* does;
-- for DEFUN, DEFMACRO, DEFTYPE and DEFSETF follow the rules for
LAMBDA-Expressions (CLtL, Section 5.2.2, pp. 59-66).
Remember also that new name bindings "shadow" (after a fashion) any
higher level binding or declarations. E.g., presuming that no
proclamations are in effect, consider the inner let bindings of:
(locally (declare (special x) (float y))
(let ((x 5) (y 10))
(print (+ x y))))
then x is bound as local (not special); and y is bound with no particular
type information [because the 'y' being bound is a different variable
than the 'y' declared float in the outer scope].
It has been suggested that compilers could be a bit more helpful in
detecting anomalous bindings, such as in the LET* following:
(defun bar (x y)
(let* ((old-x x)
(x y)
(new-x x))
(declare (special x))
(list old-x x new-x)))
The collection of variables named X in the LET* binding and initial
forms includes both local (lexical) and special ones.
∂09-Dec-88 1742 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Dec 88 17:41:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 17:35:03 PST
Date: 9 Dec 88 17:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DECLARE-TYPE-FREE (Version 8)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881209-173503-1691@Xerox>
This is one of several variations discussed.
!
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
Examples:
;; this is an error:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error, because the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error, even though the violation of the type
;; constraint happens after the form with the declaration
;; is exited.
(let ((f (let ((x 3)) (declare (fixnum x)) #'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
∂10-Dec-88 0348 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Dec 88 03:48:01 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03444g; Sat, 10 Dec 88 03:45:20 PST
Received: by bhopal id AA00267g; Sat, 10 Dec 88 03:47:17 PST
Date: Sat, 10 Dec 88 03:47:17 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812101147.AA00267@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 9 Dec 88 15:58 PST <881209-155854-1325@Xerox>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)
I believe this issue was incorrectly mailed to X3J13. By "cleanup" rules,
only those issues that have "settled down in sub-committee" are to be
mailed out now, and this issue has been under daily disucssion for the
past week. Furthermore, this version 2 has had no review whatsoever;
worse yet, it appears to have an egregious bug in it (a logical inversion
in one sentence).
-- JonL --
∂10-Dec-88 0513 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Dec 88 05:13:53 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03592g; Sat, 10 Dec 88 05:11:16 PST
Received: by bhopal id AA00374g; Sat, 10 Dec 88 05:13:13 PST
Date: Sat, 10 Dec 88 05:13:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812101313.AA00374@bhopal>
To: masinter.pa@Xerox.COM
Cc: x3j13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 9 Dec 88 17:34 PST <881209-173503-1691@Xerox>
Subject: Issue: DECLARE-TYPE-FREE (Version 8)
Please retract this Issue from X3j13 now. You (Larry) substantially
reworked it during the past few days, and provided no opportunity for
review by the principals who originated the proposal.
In particular, if I read Kent's commentary right, from the msg:
Date: Wed, 19 Oct 88 15:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
then his intent, along with that of Moon and myself (who also worked
on this proposal), is diametrically opposite of what you now have it
to be.
In particular, your explanation:
;; this is an error:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
was explained as exactly the opposite by Kent on 19-Oct-88; and the rest
of us have always agreed that "free" type declarations need not be
consistent with "specialized storage" -- that they are merely equivalent
to wrapping (THE <type> ...) around lexical occurances of the variable.
It this point is debateable, it should have been debated in subcommittee
before "release" of the issue.
-- JonL --
∂10-Dec-88 1236 X3J13-mailer ISO Meeting Status
To: ROSENKING@a.ISI.EDU
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
As I mentioned in my trip report, the January ISO meeting which was to
have been held immediately following the X3J13 meeting has been cancelled.
There is no possibility to revive it now. Also as I mentioned, I believe
that the meeting was hastily cancelled - had I been chairman of the
committee I would not have suggested the cancellation and I would not have
entertained the motion to cancel unless there was an overwheling sense of
the committee that it should be cancelled, regardless of any personal
circumstances such as lack of travel funds.
All of the US ISO representatives will, I believe, be at the January X3J13
meeting, and it is reasonable to have a discussion about the ISO situation
at that meeting. However, this meeting is our most important technical
decision-making meeting. I suggest that people who have opinions about the
ISO situation should try to send mail beforehand or try to formulate a
concise statement so that the normal business of the next meeting can be
conducted as planned.
-rpg-
∂12-Dec-88 0832 X3J13-mailer Re: ISO Meeting Status
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 08:32:52 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA08427; Mon, 12 Dec 88 08:35:20 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA08700; Mon, 12 Dec 88 08:32:00 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA05945; Mon, 12 Dec 88 08:32:35 PST
Message-Id: <8812121632.AA05945@suntana.sun.com>
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: ROSENKING@a.ISI.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re: ISO Meeting Status
In-Reply-To: Your message of 10 Dec 88 12:36:00 -0800.
<14Oq5E@SAIL.Stanford.EDU>
Date: Mon, 12 Dec 88 08:32:33 PST
From: kempf@Sun.COM
>All of the US ISO representatives will, I believe, be at the January X3J13
>meeting, and it is reasonable to have a discussion about the ISO situation
>at that meeting. However, this meeting is our most important technical
Considering the recent exchange of notes on the ISO Meeting, I think it would be
worthwhile to have this discussion. I also agree that it should be
arranged such that it does not conflict with the technical sessions,
as they are, at this point, more important. Perhaps we can schedule an
evening session for it.
jak
∂12-Dec-88 0942 X3J13-mailer Issue release & scheduling
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:42:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:31:01 PST
Date: 12 Dec 88 09:30 PST
From: masinter.pa@Xerox.COM
Subject: Issue release & scheduling
To: x3j13@sail.stanford.edu
Message-ID: <881212-093101-4200@Xerox>
I will be mailing out hardcopy of the "released" issues this week. If
there are errors, problems, or corrections to any of the issues--
especially the late-breaking ones-- please prepare amendments or new
versions to bring to the January meeting. While there will be a ballot, the
purpose of the ballot is to help us avoid discussing the non-controversial
issues; the ballot will tell us which issues should be included in a
"block" vote of endorsement/rejection. Certainly there will be opportunity
at the January meeting to correct mistakes or review issues, if there is
some belief that they were incorrectly framed, misunderstood, or should
otherwise be reviewed.
My personal schedule for getting the mailing out is tight enough that it is
likely there will be more of these than just the ones that JonL has pointed
out. Given the large number of issues, there's been more haste than usual,
for which I apologize.
After issues go into the mail, I will be on vacation until the new year, so
please do not expect a reply if you send mail to me alone.
∂12-Dec-88 0942 X3J13-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 09:42:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:34:46 PST
Date: 12 Dec 88 09:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-093446-4207@Xerox>
!
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
V2, 15 Sep 1988, Sandra Loosemore
V3, 7 Dec 1988, Masinter
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type. A print function that uses the
default #S syntax (overriding any print function for the parent type)
can be specified by providing the :PRINT-FUNCTION option without an
argument.
Supplying a :PRINT-FUNCTION in a DEFSTRUCT is equivalent
to defining an appropriate method on the PRINT-OBJECT generic
function.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Current Practice:
Lucid Common Lisp makes structures inherit print functions.
VaxLisp uses #S syntax unless an explicit :PRINT-FUNCTION
is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Pitman and VanRoggen support this proposal.
The original version of the proposal did not provide for a way to
force #S syntax to be used. This functionality was added to the
current version because there seemed to be general agreement that it
would be useful. Other alternatives would be to name the function
that does what the #S printer does, or to provide a function that
returns the #S information as a list (as suggested by Waters) so users
can write their own.
∂12-Dec-88 1004 X3J13-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:04:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:55:34 PST
Date: 12 Dec 88 09:53 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-095534-4250@Xerox>
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Version 2 by Larry Masinter 14-Sep-88
Version 3 by Larry Masinter 23-Sep-88
Version 4 by Larry Masinter 31-Oct-88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL. Is it allowed?
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same symbol-name;
that is, the SYMBOL-NAME of the slot names should not be STRING=.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
The situation of expanding a DEFSTRUCT macro with a duplicate name "should
signal an error." (While not yet formally defined, the intent is that
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)
Examples:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.
Current Practice:
In KCL, if two slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
This issue was first circulated to X3J13 June 1988.
This proposal does not address the issue of whether NIL is a legitimate
slot name. There seems to be no current reason why it might be prohibitied.
The compiler committee is proposing to address generally the issue
of how macro-expansion errors during compile-file might be caught and
turned into compiler warnings.
∂12-Dec-88 1111 X3J13-mailer Issue: FIXNUM-NON-PORTABLE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:10:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 11:02:59 PST
Date: 12 Dec 88 10:49 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FIXNUM-NON-PORTABLE (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-110259-4502@Xerox>
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88, Sandra Loosemore
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Version 4, 7-Dec-88, Masinter (two proposals)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
CLtL p14 and p34 disagree about BIGNUM. One says that
FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Example:
Consider an implementation with three numeric representations:
Fast (INTEGER -1024 1023)
Immediate 29 bits
Extended Multi-precision
Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM, if it
remains, would then refer to multi-precision integers.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason; thus
two proposals.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits; TOSS-BIGNUM would have to remove the BIGNUM type
specifier to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
There was little consensus on whether to leave BIGNUM in the language.
We don't currently have a way to "deprecate" features, so we are not
proposing it here.
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarily mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
----- End Forwarded Messages -----
∂12-Dec-88 1054 X3J13-mailer Issue: EXIT-EXTENT (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 10:53:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 10:39:04 PST
Date: 12 Dec 88 10:37 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: EXIT-EXTENT (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-103904-4431@Xerox>
!
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
(Terminology: In this issue writeup, the noun "exit" is
refera to the thing that can be exited from, rather than the
act of exiting. When the extent of an exit has ended, it is
no longer legal to exit from it. This is different from
the scope of the exit. For example, a BLOCK has lexical
scope but dynamic extent; a the scope of a CATCH--the
visibility of the CATCH tag to corresponding THROWs--
could differ from the extent of the CATCH.)
The problem arises when there are nonlocal exits from the
"cleanup" clauses of an UNWIND-PROTECT.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control.
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
For example,
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
For example, in
(block testem
(when (zilched) (return-from testem nil))
(when (zorked) (throw 'uh-oh))
(format t "Neither zilched nor zorked."))
if (zilched) returns true, the block testem is exited via a
'nonlocal exit'. If (zorked) returns true, the block testem
is 'passed over'. Otherwise, the block is exited normally.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
!
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
Note that this does not affect the extent of the binding of CATCH
tags; that is, under this proposal, a THROW to a CATCH which was
already in the process of being exited would be an error.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL. A program that presumed a longer extent
would be in error. Implementations may support longer extents for
exits than is required by this proposal; in particular, an
implementation which allowed the larger extent of the MEDIUM
proposal below would still conform.
Proposal (EXIT-EXTENT:MEDIUM):
The dynamic extent of an exit, whether target or passed-over, ends
only after the exit is complete.
A transfer of control from within an UNWIND-PROTECT cleanup form
to a point outside of the UNWIND-PROTECT causes the original control
transfer which initiated the execution of the cleanup forms to be
abandonded.
During the execution of the cleanup forms of an UNWIND-PROTECT a
non-local exit to a point outside of the scope of the UNWIND-PROTECT,
but still within the dynamic scope of of the target of the original
non-local exit succeeds, and the original pending exit is discarded.
Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a
point outside the original non-local exit, control is passed to the
outer exit (and the pending original non-local exit is discarded.)
In no case will UNWIND-PROTECT cleanup forms ever be attempted more
than once.
!
Examples:
Each of the following programs are an error under either
proposal:
;; Error: BLOCK has normal exit before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
Each of these programs are an error under MINIMAL, but
not under MEDIUM:
;;returns 2 under MEDIUM, is error under MINIMAL
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; An error under MINIMAL because the catch of b is passed over by
;; the first throw, hence portable programs must assume its dynamic extent
;; is terminated. The catch is not yet disestablished and therefore it
;; is the target of the second throw.
;; the following is an error under MINIMAL; the extent of the
;; inner catch terminates as soon as the throw commences, even
;; though it remains in scope. Thus, the throw of :second-throw
;; sees the inner catch, but its extent has ended.
;; under MEDIUM, it prints "The inner catch returns :second-throw"
;; and then returns :outer-catch.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
The following cases are errors under MINIMAL, and have
the following interpretation under MEDIUM:
In
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the pending exit to tag FOO is discarded by the second THROW
to BAR and the value 4 is transfered to (CATCH 'BAR ...),
which returns 4. The (CATCH 'FOO ...) then returns the 4
because its first argument has returned normally.
XXX is not printed.
In
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed.
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. It is not an error, even though the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW to FOO.
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.
For MEDIUM: Giving exits a longer exent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter exent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all nonlocal exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the nonlocal exit
that caused the cleanup clause to be invoked.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal. It was argued that the likely
resolution of those issues would be more consistent with the
MEDIUM proposal than MINIMAL.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
----- End Forwarded Messages -----
∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:29:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:19:43 PST
Date: 12 Dec 88 11:19 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-111943-4569@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Related-issues: DECLARE-TYPE-FREE
Edit history: #1, 7 Sept 1988, Walter van Roggen
#2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
#3, 7-Dec-88, Masinter
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
way of providing this information is with the FTYPE declaration
or the FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
This proposal is written as if DECLARE-TYPE-FREE (Version 6, 06-Oct-88)
is in effect.
Specify that a declaration of the form
(ftype (function (arg0-type arg1-type ...) val-type) f))
implies that any call of the form (f arg0 arg1 ...) within the scope of
the declaration can be treated as if it were
(the val-type (f (the arg0-type arg0) (the arg1-type arg1) ...))
That is, it is an error for any of the arguments not to be of the specified
types or the result not to be of the specified type. (In particular,
If any argument is not of the correct type, the result is not guaranteed
to be of the specified type.)
Thus, an FTYPE declaration for a function describes calls to the function,
not the actual definition of the function.
Similarly, specify that a declaration of the form
(type (function (arg0-type arg1-type ...) val-type) fn-valued-variable)
has the interpretation that, within the scope of the declaration, it
is an error to call the value of fn-valued-variable with arguments
not of the specified type; assert that the value resulting from a valid
call will be of type val-type.
As with variable type declarations (cf DECLARE-TYPE-FREE), nested declarations
imply intersections of types, as follows:
If two (or more) declarations of the form "ftype" are in effect,
(ftype (function (arg0-type1 arg1-type1 ...) val-type1) f))
and
(ftype (function (arg0-type2 arg1-type2 ...) val-type2) f))
then within the shared scope of the declarations, calls to f can be
treated as if it were declared
(ftype (function ((and arg0-type1 arg0-type2) (and arg1-type1 arg1-type2 ...) ...)
(and val-type1 val-type2))
f))
(It is legitimate to ignore one or all of the declarations in force.)
If two (or more) type declarations are in effect for a variable, and
they are both FUNCTION declarations, the declarations combine similarly.
This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type, or the nesting and scoping rules for
FTYPE declarations.
Example:
(DEFUN FFF (F)
(DECLARE (TYPE (FUNCTION (FLOAT STRING) LIST) F))
... (FUNCALL F (FOO ...) ...) ... )
then #'CONS is a valid argument to be passed to FFF because the declared
type of the argument is consistent with type (FUNCTION (T T) CONS).
Within FFF, the declaration permits us, for example, to assume that FOO
returns a FLOAT.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP assumes and makes use of the semantics different than CLtL
but not exactly what is specified here. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Cost to Implementors:
Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.
Cost to Users:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Cost of Non-Adoption:
There already exists user code on many implementations that assume the
proposed semantics. Not adopting this proposal would continue to render
such code incorrect or at least non-portable.
Benefits:
Better type checking and more compiler optimizations should be possible.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
A declaration of
(FUNCTION (FIXNUM FIXNUM) CONS)
is a not proper global declaration for CONS if any program might
call CONS with arguments that are not FIXNUM.
The list form of the FUNCTION type specifier is different from most
type specifiers because it cannot be used for discrimination.
Thus, the notion of "subtype" does not make sense, since assertions
about the functional value of a variable are only partially
about the actual value of the variable and mainly about the
values that might be passed to the variables (function) value.
∂12-Dec-88 1129 X3J13-mailer Issue: FUNCTION-COMPOSITION (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 11:29:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 11:17:46 PST
Date: 12 Dec 88 11:04 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: FUNCTION-COMPOSITION (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-111746-4560@Xerox>
!
Forum: Cleanup
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
7-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter (additional comments)
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Proposal: FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Only add the functions COMPLEMENT and ALWAYS.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases. The NEW-FUNCTIONS proposal
will permit a programming style which is currently awkward
in most Common Lisp implementations.
Current Practice:
No Common Lisp implementations provide these functions,
but they do exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
It is technically possible to define this functionality portably,
the really important part of this proposal is that native compiler
support is needed to really do them justice. Portable implementations
are not likely to be efficient enough for serious use.
Placing these functions in the core language not only permits
but encourages a very useful set of compiler optimizations that
would otherwise be difficult to obtain.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added. [See issue TEST-NOT-IF-NOT.]
Pitman and van Roggen support the proposal.
Jim McDonald (JLM@Lucid.COM) seemed supportive of this proposal
and even suggested adding more elaborate operators such as
PERMUTE and COMMUTE. eg, (COMMUTE #'CONS) would be like what
Maclisp called XCONS.
Other comments:
"I don't like it. I really don't."
The names chosen are too "generic"; pick other names.
No existing implementations have functions like these, although they
could easily have added them.
If COMPOSE is added, deal with multiple values, e.g.,
(funcall (multiple-value-compose #'f #'g #'h) a b c)
is the same as
(multiple-value-call #'f
(multiple-value-call #'g
(h a b c)))
"this is the sort of gratuitious addition to the
language that ought to be tested first -- tested by it's utililty to some
vendor/implementor who feels it's worth the risk to add something like it
to his product. I deplore the tendency to think that vendors shouldn't make
an offering unless it is "sanctioned" by the X3J13 committee."
Additional Comments:
"The names are OK with me except for ALWAYS. ALWAYS reminds me of the
SOME/EVERY/etc. mapping functions, perhaps because it's a LOOP keyword
(btw, what's the status of LOOP keywords?). I would prefer something
like RETURNER. Also, I presume it's defined as taking (&rest ignore)
for an arglist. Is that true? Shouldn't that be specified in the proposal?"
"Although the discussion mentions some criticism from within the subcommitte,
I don't think it does full justice. ....
. . .
I say "gratuitious" because
(1) no vendor/implementor supplies them now; thus it is not "existing
practice" that needs to be standardized;
(2) no fundamental problem has been exposed because of its lack; no
implementational headaches would be resolved, and few (if any) pleas
from the user community would be addressed;
(3) no confusions exists among our community as to what these functionals
(or similar such features) mean; hence no need to clarify.
. . .
While it is useful to encourage the "functional style" of programming,
these functions are *not nearly enough* to do that. That is, if you really
wanted to build a useful library, you would find these few functions
inadequate.
Extensions that no current vendor offers -- even those that have extensive
sets of extensions to Common Lisp in their product -- should be viewed with
great suspicion.
"
∂12-Dec-88 1212 X3J13-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 12:12:28 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 12:11:02 PST
Date: 12 Dec 88 12:10 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 4)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-121102-4751@Xerox>
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
Related-Issues: DEFPACKAGE
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only minimal
loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many
will want to make IN-PACKAGE signal an error.
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In some cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some support this only if DEFPACKAGE passes; others would like
to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
However, there might be some compilation problems if IN-PACKAGE
changes and MAKE-PACKAGE signals an error if the package exists.
The issue of compile-time processing of package related functions is
complex, and full of a number of compatibility issues. Should we remove
the requirement of special compile-time handling of IN-PACKAGE?
Should we disallow mid-file switching of *PACKAGE* or package
use lists? These issues are not addressed here.
The issue of the "proper" preface for files needs more thought.
Should files that need demand-created packages start with DEFPACKAGE
followed by IN-PACKAGE?
".... unless the file begins with an
IN-PACKAGE, then the DEFPACKAGE form will be read into totally random
package, doing who knows what sort of damage.
Ideally, every file of a multi-file module should begin with an
IN-PACKAGE form to get "in" that module's package. The exceptions
are files which might as start out (IN-PACKAGE "USER"). For example,
the package creator file might look something like:
(in-package "USER") ;guaranteed to exist, and not be harmful!
(defpackage :phlogiston ...)
Another exception might be the DEFSYSTEM surrogate, which also would
start out in the USER package, and simply load the rest of the files."
∂12-Dec-88 1212 X3J13-mailer Issue: HASH-TABLE-STABILITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 12:12:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:51:33 PST
Date: 12 Dec 88 11:51 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: HASH-TABLE-STABILITY (Version 1)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-115133-4704@Xerox>
This issue has "additional comments" at the end that are not
part of this version.
!
Issue: HASH-TABLE-STABILITY
References: CLtL, p.282 "Hash on Lisp object"
The Art of Computer Programming, vol 3, Section 6.4 "Hashing"
Category: CLARIFICATION
Edit history: Version 1, 11-Nov-88, by JonL
Problem description:
The performance, and to some degree the semantics, of hash tables
depends not only on the kind of table as specified by the :test
argument to MAKE-HASH-TABLE, but also on the underlying techniques
of key transformation (into an integer) and of "collision" resolution.
CLtL is not specific enough to encompass current, desirable practice.
People tend to be confused as to what "Hash on EQ" means, both in terms
of semantics and expected performance. Many will often suggest using
SXHASH as the key-transformation function for EQ/EQL type tables, in
order to circumvent the well-known GC-related problem with those tables.
[See, for example, the message from Barry Margolin to the common-lisp
mailing list dated "12 Sep 88 11:05 EDT"; it is reproduced at the end of
the Discussion section below.] Unfortunately, this suggestion violates
the commonly perceived notion of what "Hash on EQ" means, even though
CLtL nowhere explicitly would rule it out. CLtL is not precise enough
as to what is expected of these types of tables, and certainly the
phrase "commonly perceived notion" is not precise enough.
A similar ambiguity can arise as to what "Hash on EQUAL" means; CLtL
p.285 only indirectly implies that SXHASH should be used as the
key-transformation function for EQUAL type tables. [See below for
definition of "key-transformation".]
The term "Hashing on Lisp objects" has come to be called "Hash on EQ",
and "Hashing on Tree Structure" is called "Hash on EQUAL"; see CLtL
p.282 , which describes the differences between hash-table kinds as
being merely which function they use as the equivalence predicate
(the :TEST function argument to MAKE-HASH-TABLE.) However, the term
"Hash Table" carries a strong connotation about how such a table is
implemented; in particular, for sufficiently large tables, some technique
for "collision resolution" must be done. (See Knuth vol 3, p507-8).
Since CLtL merely focuses on the :test function, people -- implementors
as well as end-users -- tend to be confused as to how these techniques
play a central part in the notion of "hash tables; furthermore, CLtL is
silent about what actions must preserve the stabililty of these
"collision chains" (i.e., the ability of the table to "find" previously
entered keys).
Proposal (HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS)
Summary of proposals:
-- Clarify that by "hashing", we mean more than simple linear search.
-- Generalize the following requirement from CLtL p.285:
(EQUAL X Y) implies (EQUAL (SXHASH X) (SXHASH Y))
and clarify that this requirement exactly prescribes how sensitive
hash tables can be to user-initiated data modifications.
-- Characterize just what key-transformation functions may be used for
EQ, EQL, EQUAL and EQUALP hash tables.
First, some terminology:
"Key-Transformation". This is a term used by Knuth to describe the
homomorphic transformation of a hash-table key argument into an integer.
[See the index for "The Art of Computer Programming", vol 3; especially
see Section 6.4 and page 512.] It also can refer to the transformation
into a set of two or more integers (which is not really a distinct
notion considering Goedel numbering). From this integer, the pattern
of table indices to use when searching for that key will be completely
characterized. Knuth also uses a related term "hash function" to mean
"the address where the search begins"; that term is much too subject to
confusion, and will not be used herein.
"Collision Chain". This term is limited in use by Knuth to just one
particular method of collision resolution; herein it will be used to
describe the sequence of probes specified for a given candidate entry
by a particular key-transformation; i.e. a virtual "chain" of table
indices (or address) to be examined. Two different objects which "hash"
to the same table address are "in conflict", and their respective
collision chains may or may not be equal.
"Expected number of (re-)probes". A particular algorithm for key-
transformation and collision-chain specification could be analyzed to
show a graph of the "Expected" number of calls on the :test function,
as a function of the fullness of the table (number of entries divided
by table size). "Expected" has a technical, mathmatical meaning here:
it basically means "average", so one must be careful not to get carried
away with particular counter examples of "badly distributed" data. A
"probe" is one comparison of the argument with the key of an entry in
the table, using the test function.
"%UNIQUE-NO". The implementation of Lisp data, encoded into machine-
specific data and addresses, is not part of the portable specification
of CL; but we are aware that every implemetation _must_ do some such
embedding. Thus we will use %UNIQUE-NO to name a one-to-one function
which maps any Lisp object into a Lisp integer. Normally, this will
just be the machine address of where the object is stored, possibly with
some data-type tag bits added. But for non-stored, or "immediate" data,
it doesn't matter what %UNIQUE-NO returns as long as its bijective nature
is maintained. The following equivalence is a defining characterization:
(eq x y) <--> (= (%unique-no x) (%unique-no y))
Now for the actual proposals.
1. Clarify that the term "hash table" implies the use of some techniques
designed to make the expected number of probes be bounded by a small
constant rather than growing linearly with the number of entries in the
table [for "small constant", one could also accept "log of the number of
entries"]. Although nothing in CLtL explicitly prohibits it, very few
people would accept simple linear searching as any kind of hash table.
For example, the following definition is counter to our understanding:
(defun gethash (x ht &optional default)
(let ((index (position x (hash-table-key-vector ht)
:test (hash-table-test ht))))
(if index
(values (svref (hash-table-value-vector ht) index)
T)
(values default
NIL))))
Such a simple definition may be functionally useful when the total
number of entries is small (e.g., a couple dozen or so); but the
"Expected" number of probes grows linearly with the number of entries.
As a consequence of this requirement, the collision chain for a give item
in a given table will likely not cover the whole table; otherwise, if
every such chain covered a substantial fraction of the table, then the
behaviour time would be linear in the size of the table. Thus it should
be noted that even though an item is entered in a hash table, it
typically _cannot_ be found by searching through the wrong collision
chain.
2. Specify that for any equivalence relation <eqv> used as a hash table
:test function, there must be a corresponding key-transformation function
<sxh> used in that hash table such that the following implication is true
for all X and Y:
(<eqv> x y) --> (= (<sxh> x) (<sxh> y))
This could be said to mean that a key-transformation function must be "not
more discriminating" than the equivalence function it is associated with;
i.e. as a numerical function, it must not create more equivalence classes
of data than the associated equivalence function does.
This requirement resembles that placed upon SXHASH [CLtL, p285], and
from it, one may deduce that SXHASH is a acceptable key-transformation
function for EQUAL type hash tables. Note well, however, that there
are many many functions satisfying this property for EQUAL. Hence
key-transformation for EQUAL tables:
(1) need not be constant over all CL implementations;
(2) need not be constant over all instances of EQUAL hash-tables in
a given implementation;
(3) need not be constant even over all entry counts for a particular
hash table in a given implementation.
Note also that this requirement -- "not more discriminating" -- rules
out the use of key-transformations which "notice" data modifications
that are not likewise "noticed" by the test function. Since user-
initiated data modifications might conceivably affect either the
equivalence relation of a hash-table (the :test function) or the
associated key-transformation function, we want to ensure that the
ability of the table to "find" a previously entered key is related only
to the ability of the :test function to identify equivalent copies of
the key.
3. Clarify that %UNIQUE-NO is acceptable as a key-transformation for an
EQ type table, but that it is not suitable for EQUAL or EQUALP tables.
Clarify also that most SXHASH implementations are _not_ suitable for EQ
or EQL type tables.
Numerous implementations have some function like %UNIQUE-NO called
either %POINTER or POINTER-TO-FIXNUM; they are generally acceptable for
EQ type tables. But one must be careful to note that similar, unrelated
functions could also be used; in particular, many "unique identification"
schemes have been employed where the integer is cached with the object by
some means other than the bits of its address (e.g. a "hidden" component
inside the object). Of course, any %UNIQUE-NO defined as above would not
be acceptable for EQUAL or EQUALP tables; two EQUAL but non-EQ cons cells
must have different %UNIQUE-NO values, violating the general rule stated
in item 2 above.
A trivial variant on %UNIQUE-NO is acceptable for EQL tables:
(if (numberp x) (sxhash x) (%unique-no x))
By itself, %UNIQUE-NO would not be acceptable since it would be too
"discriminating" on numbers.
Many persons have noted that the definition:
(defun sxhash (x) 5) ;for any random integer value of "5"
meets the CLtL criterion for SXHASH. In fact, such a constant function
may be quite useful for hash-tables with entry counts below a specified
mininum. But of course it is not really suitable in general since it
would put every entry into the same collision chain; that would cause
the expected re-probe cost to be linear in the number of entries, which
violates item 1 above.
On the other hand, an SXHASH function suitable for use as the key
transformation in an EQUAL type table is _not_ acceptable for use
with an EQ or EQL table. Every implementation the proposer has queried
returns different values for the lists (A) and (B). Thus consider the
example of hashing a list (A) into an EQ type table, and observe what
happens after altering the (first) element of this list to be B. Let
x = the list before modification
y = the list after modificaton
now clearly (EQ X Y) is true, so we would obviously like a GETHASH call
after the modification has been done to find the same cons cell that
had been entered before the update. If SXHASH were used as the key-
transform, then the collision chain selected _after_ the alteration would
be different from the one selected beforehand. Since the two different
collision chains can not be guaranteed to intersect, then in at least
some circumstances, GETHASH on X would find the entry, but GETHASH on Y
would fail to find it. See also the examples section.
Although SXHASH is not very tightly defined in CLtL, one must be careful
not to make assumptions about whether or not it is acceptable for use in
EQUALP tables. In order to get a reasonable amount of randomization in
the collision chains, a key-transformation function for EQUAL tables
ought to be "more discriminating" than any minimal function acceptable
for EQUALP tables [because EQUAL partitions the object world up into
many more equivalence classes than does EQUALP].
In item 2 above, there are listed three areas where key-transformation
functions may differ: when going from one vendor to another (or from one
release by the same vendor to another), when going from one hash-table
to another of the same type, and when increasing or decreasing the entry
count of the table. To this list we can add another more general rule on
key-transformations.
(4) [they] need not be constant even over a particular "core image"
saving and restoration, or over a "memory reorganization" such as
a garbage collection.
Of course, if a change is made at some point in time in the key-
transformation algorithm being used for a particular table, then that
table should be "re-hashed" to ensure the continuity of its entries.
As has been noted before, many implementations use algorithms for EQ
type tables which change after any data is relocated; that is why
re-hashing may be required after a "GC".
Examples:
It is not surprising that in the following example, the value Y
cannot be found in the table after it has been altered by the first
SETF, even though it could be found before the alteration.
(setq ht (make-hash-table :test 'equal)) ==> #<Hash-Table>
(setq x '(A (B) (C D))
y (copy-tree x)) ==> (A (B) (C D))
(and (equal x y) (not (eq x y))) ==> T
(setf (gethash x ht) T) ==> T
(setf (car (second y)) 'E) ==> E
(gethash x ht) ==> T
(gethash y ht) ==> NIL
After all, the :test function will not be able to identify the
altered key with with the one originally entered, because at the
time gethash is called:
(equal x y) ==> NIL
However, the circumstances under which the following can fail are
not at all obvious:
(setq ht (make-hash-table :test 'equal)) ==> #<Hash-Table>
(setq x '(A #(B) (C D))
y (copy-tree x)) ==> (A #(B) (C D))
(and (equal x y) (not (eq x y))) ==> T
(setf (gethash x ht) T) ==> T
(setf (aref (second y)) 'E) ==> E
(gethash x ht) ==> T
(gethash y ht) ==> ?
Note however that:
(equal x y) ==> T
If the key-transformation function used in this hashtable failed to obey
the "not more discriminating" contraint imposed by item 2 above, it
might be tempted to descend into the vector #(B) in order to randomize
the keys a bit more; but EQUAL on pointer vectors is defined to be EQ.
Thus X and Y, while being EQUAL, might fall into different collision
chains, and hence not be identified as the same key.
On the other hand, EQ/EQL type tables should be impervious to the
updates in the above examples:
(setq ht (make-hash-table)) ==> #<Hash-Table>
(setq y (setq x (copy-tree '(A (B) (C D))))) ==> (A (B) (C D))
(setf (gethash x ht) T) ==> T
(gethash x ht) ==> T
(setf (car (second y)) 'E) ==> E
(gethash y ht) ==> T
Thus x and y are "EQ, but not EQUAL" [which only makes sense when
they refer to the same object at different points in time]; however,
the EQ/EQL-type table is not affected by this.
Rationale:
The performance expectations about hash-tables, and consequent
implementational constraints, need to be formalized.
Current practice:
Every implementation that the proposer has tried *seems* to satisfy
these constraints.
Cost to Implementors:
None.
Cost to Users:
None.
Cost of non-adoption:
Continuing confusion as to what is stable in EQ/EQL tables, and what
is stable in EQUAL tables. Possible confusion when it comes to
implementing EQUALP tables.
Performance impact:
N.A.
Benefits:
See Cost of non-adoption.
Esthetics:
The proposal more closely relates the term "Hash Table" to the
classic use of it in "The Art of Computer Programming", vol 3.
Discussion:
One of the attractions to Common Lisp is that many common techniques are
a required part of the language; C programmers who continue to re-invent
hasing techniques over and over have praised CL in particular for hash
tables. After all, it is much more likely that efficient, correctly
coded algorithms will be provided by the system supplier than that every
code writer will understand and correctly apply the information found
in Knuth's "The Art of Computer Programming", vol 3.
The requirement that the expected number of reprobes be bounded by a
"small constant" should not be taken to extreme. In particular, a
simple trade-off of space for time can assure some compliance with it.
For example, a data set of size N could be partitioned into N/20
subsets; as long as the partitioning function does a fairly good job
of balancing the number of elements in each partition class, and as
long as the partition function can be quickly calculated, then the one
could say that the expected number of probes would be bounded by "about
twenty or so". The generally understood meanings of the :rehash-size
and :rehash-threshold components of hash-tables may be biased towards
an "open-addressing" implementation; but "bucketizing" implementations
are not arbitrarily ruled out. This proposal is in no way intended to
rule out "bucketizing" implementations of hash tables.
Here's an example of how one might analyze the problems relating GC
and EQ/EQL type tables:
Date: Mon, 12 Sep 88 11:05 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: MAKE-HASH-TABLE :TEST arg
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: common-lisp@sail.stanford.edu
. . .
Various aspects of the behavior of a hash table are dependent upon the
TEST argument. An EQUAL hash table need not be rehashed after a copying
GC. The hash function is generally dependent upon the test function;
for an EQUAL hash table it would be SXHASH, while for an EQ hash table
it would probably be a simple hash on the address.
I suppose you COULD use SXHASH for all hash tables, since EQ objects are
necessarily EQUAL, and you COULD rehash ALL hash tables. Or you could
implement hash tables without actually hashing (e.g. implement them as
alists). But if performance is an issue (which it generally is when you
use a hash table), you'll probably want to do things dependent on the
test function.
barmar
This suggestion is not prohibited by CLtL, although it violates the
commonly accepted understanding of what "Hash on EQ" means.
!
----- Additional Comments -----
"This proposal is so long that I got lost while reading it. From the
examples, one would think it was proposing some rules about what users
can expect when they modify objects that are used as keys of hash
tables. However, I couldn't find anything actually proposed about that.
Most of the proposal seems to be about what performance users of hash
tables should expect, but I didn't see anything specific enough that I
could write a Common Lisp program to test whether an implementation
conforms to the proposal.
I think this proposal needs to be shortened and rewritten. I would
prefer to see it speak about the behavior a user can or cannot expect
from a Common Lisp implementation, rather than in terms of internal
details of how Common Lisp might be implemented. The essay on
implementation techniques could go in the discussion section, or could
be published separately, but I don't think it is suitable as a language
specification.
It might be a good idea to break this into two proposals, one on key
modification and a separate one on performance. The reason I say that
is that I think standardizing performance is extremely difficult, and I
would hate to see the problems with that sink the other proposal."
∂12-Dec-88 1400 X3J13-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:00:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 13:38:46 PST
Date: 12 Dec 88 13:34 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-133846-5027@Xerox>
A number of comments on this version are excerpted
in a section "Additional Comments" at the end.
!
Issue: MAKE-PACKAGE-USE-DEFAULT
References: MAKE-PACKAGE, CLtL p183
"USER" package, CLtL p181
Related issues: PACKAGE-CLUTTER
Category: CHANGE
Edit history: JonL White, 6-Oct-88 (version 1)
Masinter, 8-Oct-88 (version 2)
Problem description:
The proposal in the issue PACKAGE-CLUTTER would specify that
implementation-specific extensions are not in the LISP package.
With that restriction, access to implementation-specific features
is awkward; it is necessary to always name the vendor-specific
extensions in the :USE list of MAKE-PACKAGE or (if the proposal
in DEFPACKAGE is adopted) in DEFPACKAGE.
This forces users of a specific implementation to always have
to type something to get the default set of features for that
implementation, even if they have no intention of writing portable
code.
Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
adopted) so that the default for the :USE keyword is
implementation-dependent. Normally, the default will include
the packages containing the implementation-specific features.
Portable programs should instead always specify :USE '("LISP")
explicitly.
Examples:
(package-use-list (make-package "SOME-USER"))
(package-use-list "USER")
Test Cases:
(assert
(subsetp `(,(find-package "LISP"))
(package-use-list (or (find-package "SOME-USER")
(make-package "SOME-USER")))))
Rationale:
Every implementation either already does the equivalent of this, or
else has a confusing assymetry about the USER package (i.e., their
extensions are "available" in USER, but not in SOME-USER).
Current practice:
TI and Lucid's 3.0 versions "implement" this proposal in that they set
the default :USE argument to be a list of the LISP package and the
implementation-specific package.
In VAXLISP the LISP package is the implementation-specific
package, which contains the 775 symbols supposed to be in the LISP packge
along with all the extensions; the package named COMMON-LISP
has only the 775. Thus this implements the proposal in the sense that
the inheritance of a package made with a default :USE list contains
all the implementation-specific symbols -- not just the 775 "LISP" ones.
Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
default MAKE-PACKAGE use list, but have the aforementioned assymetry
about the USER package.
Cost to Implementors:
None; this relaxes a constraint imposed by CLtL.
Cost to Users:
In theory, every user porting code from one vendor to another would
have to ensure that every package definition, via IN-PACKAGE or
MAKE-PACKAGE, had an explicit :USE list. This is probably at most
a 5-minute text editor search. But in fact this imposition is moot,
since virtually every such user has *already* supplied explicit
:USE lists; given the current practice, he has had no alternative.
Cost of non-adoption:
There will continue to be a lack of clear standardization in this area,
especially since vendors are more willing to violate this apparently
unuseful mandate from CLtL than they are to give up a minor bias towards
their customer base.
Performance impact:
None.
Benefits:
This new default behaviour for package creation will permit
documented extensions to appear on equal footing with the basic facilities
in the LISP package. It appears as though the _majority_ of any
users are developing and running their code totally within the
enviornment provided by that one vendor; hence it seems reasonable for
implementations to bias their default use list towards those making
frequent use of their specific extensions to Common Lisp.
Esthetics:
Some feel that fewer implementation-dependent loopholes in the language
is preferable, even when the practical import is virtually moot.
Discussion:
Lucid "exposes" the default :use list as the value of the special
variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
time, one could do
(setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
to return to the 1984 CLtL behaviour. [This is not being proposed
at this time.]
----- Additional Comments -----
" I don't like this proposal, but I made a note to myself about another
reason that just occurred to me: There is no syntax for getting the default
(ie, system-dependent) package included if you want to -also- use some other
package."
- - - - - -
"MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.
I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?
In response to Kent's remarks, the issue is whether the default should
be a portable way to get the local extensions, or a portable way to
get the portable language without the extensions. I think either of
those choices is portable and reasonable, it just depends on what you
want to make easier, which probably depends on whether a package is
being set up for use only by a predefined program or for use by user
typein and/or user-written programs, either of which are likely to
expect the local extensions.
Hence I would also accept a proposal to make the default for :USE
continue to be the LISP package, rather than incompatibly changing it,
and add a portable name for the local extensions."
- - - - - -
"re: I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?
I agree, sort of. Especially since one of the motivating factors for
this proposal was that some Lucid 2.1 user's were complaining that
"things" look a lot different from the USER package than from a
user-created package.
The only question is whether or not you really want the default to be
sensitive to subsequent alterations of USER's :use list. As mentioned
in the Discussion section of the proposal, Lucid's implementation
exposes the default as the value of a global variable, which happens
to be a copy of the initial :use list of USER; but subsequent changes
to USER have no affect on this global variable."
- - - - - -
"The point: non-portable programs should declare that intent up-front.
This is a virtue of the current situation: if the program uses a
non-portable package, they have to state that at the head of the file. Us
poor losers who try to load it into the wrong environment get a error
before we've gotten on with the load."
∂12-Dec-88 1400 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:00:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 13:45:36 PST
Date: 12 Dec 88 13:44 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PACKAGE-CLUTTER (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-134536-5049@Xerox>
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
7-Oct-88, Version 4 by Masinter (response to KMP)
8-Dec-88, Version 5 by Masinter
(add property lists)
12-Dec-88, Version 6 by Masinter (respond to comments)
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
External symbols of the LISP package may have function, macro, or
special form definitions, top level value or SPECIAL proclamations,
or type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions, macros or special forms; BOUNDP will be false
for all those except those documented to be variables,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
This proposal constrains implementations as to what their
initial package configuration must be. That is, valid programs
can assume that the conformal Lisp implementation will not
have prohibited properties. The proposal LISP-SYMBOL-REDEFINITION
addresses the converse; that is, what user programs are allowed
to do.
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
More likely the extension symbols would be moved to one or more
extensions packages, e.g. ACME-COMMON-LISP, so user packages in which
the extensions were desired could simply :USE the extensions package(s).
Implementations might want to use this way of conforming with this
proposal in order to minimize cost to users.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
----- End Forwarded Messages -----
∂12-Dec-88 1434 X3J13-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:27:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 14:26:26 PST
Date: 12 Dec 88 14:26 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-142626-5215@Xerox>
This issue has consumed a large number of "cleanup" committee
cycles. (I have over 80 messages filed on this one topic.)
We hope to have another proposal available as a possible
resolution of the same issue...
!
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
Version 4 by Pierson 10/31/88, remove from language
Version 5 by Pierson 11/15/88, cleanup, fix discussion
Version 6 by Pierson 12/9/88, remove *MODULES* as well
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
Proposal (REQUIRE-PATHNAME-DEFAULTS:ELIMINATE):
Remove PROVIDE, REQUIRE, and *MODULES* from the Common Lisp standard.
Test Cases/Examples:
(PROVIDE 'fft)
Would not be Common Lisp.
(REQUIRE 'fft)
Would not be Common Lisp.
Rationale:
The file loading feature of REQUIRE is non-portable. The remaining
functionality of PROVIDE and REQUIRE (pushing and testing *MODULES*)
can easily be implemented by user code. Since some implementations
will retain the automatic module loading features of REQUIRE and some
won't, use of REQUIRE will almost always make code less portable.
Current practice:
All implementations currently support some sort of file loading via
single-argument REQUIRE. In general, the Lisp Machine implementations
invoke the system module building/loading facility while the Unix
implementations simply try to load a file in the current directory.
Cost to Implementors:
Implementations will have to move PROVIDE and REQUIRE to their package
for implementation extensions and change their documentation to
indicate that PROVIDE and REQUIRE are non-standard. This is a fairly
small change.
Cost to Users:
Non-portable programs that rely on PROVIDE and REQUIRE will probably
be unaffected since implementations will probably maintain their
existing functionality. Since the current behavior is decidedly
non-portable, portable programs have to aviod or special-case PROVIDE
and REQUIRE anyway.
Cost of non-Adoption:
PROVIDE and REQUIRE will continue as impediments to portability.
Benefits:
The non-portability of PROVIDE and REQUIRE will be made obvious.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
The cleanup committee tried to come up with a proposal to restrict
PROVIDE and REQUIRE to the portable subset of their functionality.
This failed because several implementors objected that it compelled
them to significantly reduce the functionality they provided users in
order to create a trivial feature which any user could easily write
for herself.
Fahlman, Gregor, Grey, Loosemore, Moon, Pierson, Pitman, Steele, and
Zacharias have expressed support for removing PROVIDE and REQUIRE from
the language, at least as the lesser of several evils.
JonL would much rather see PROVIDE and REQUIRE remain in the language
as a safety net behind any implementation-specific system building
facility. Pierson likes the safety net idea, but doesn't think it's
workable without forbidding REQUIRE from loading files.
Pitman suggested that PROVIDE and REQUIRE should be depricated rather
than removed entirely. Pierson agrees, but notes that Larry wants us
to deal with deprication versus elimination as a separate global topic.
Several people have expressed a desire not to break existing user
code. If accepted, this proposal should not break existing code
because all implementations are expected to retain their current
PROVIDE and REQUIRE functionality as an extension to Common Lisp.
∂12-Dec-88 1434 X3J13-mailer Issue: PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 14:27:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 14:10:50 PST
Date: 12 Dec 88 14:08 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: PROCLAIM-LEXICAL (Version 9)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-141050-5132@Xerox>
!
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Version 8 by Pitman 06-Oct-88 (merge recent discussion)
Version 9 by Masinter 8-Dec-88 (make JonL's changes)
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which implies
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Clarify that special variable access does DG lookup. That is,
variables declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the dynamic one. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
and the dynamic environment (D) unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect LEXICAL declarations.
Examples:
#1: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
#2: ; Warning: It is unlikely that any serious program would
; be written in so obscure a manner as this example.
; This just tests the fringe cases.
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
If the results of this example confuse you, keep in mind
that the results of code like this would be somewhat
confusing no matter what the chosen semantics because the
code itself is far from perspicuous.
An explanation of this behavior, which some people find less
than intuitive because of the bizarre choice of constructs:
X gets bound lexically to 3 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively]
proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making
lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making
dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively]
proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not
[special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding
of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically
active Y=4 in a list which becomes third list element.
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
A fair amount compiler work would probably be needed. Some compilers
may have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Moon says...
I have now thought of an efficient way to do this on Lisp machines,
using invisible pointers, and another efficient way to do it on
stock hardware, using one extra instruction on every global
reference of one or the other sort, plus a few extra instructions
in SPECIAL binding and unbinding. Given that, I no longer object
to the proposal as unimplementable.
It doesn't just require a few compiler changes, it requires some
reimplementation of the representation of global variables, with
concomitant changes to the compiler, the loader, the interpreter,
and probably the debugger. Every symbol now potentially has two
values accessible from the interpreter (the current SPECIAL and
the global LEXICAL) and you need the corresponding new data
structure to keep track of that.
Rees suggests...
In shallow-bound implementations, implementors may have to add a
small run-time routine that searches the dynamic saved-binding
stack to look for the global value in the case where the variable
has been dynamically bound. One might want a bit (or a count)
somewhere (perhaps in the symbol itself) to speed up the common
case of access to a global binding of a variable that hasn't been
dynamically bound; without some kind of optimization, you have to
search the whole saved-binding stack on every reference to a
free [lexical] variable.
While naively you might think you'd incur the cost of clearing the
valid bit on every dynamic binding (not acceptable), in actuality
the bit is a static property of programs (PROGV excepted). So the
only places you ever need to clear FOO's valid bit are in PROGV,
in the interpreter, and when FASLOADing code that contains a compiled
dynamic binding of FOO.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
Improved appeal to a certain sector of the programming community.
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
In principle, we could imaging saying that free variables should be
lexical by default, but that would only reduce error checking to no
good end. To be really useful, this proposal will need to be followed
by a proposal for primitives analogous to DEFVAR and/or DEFPARAMETER
but for lexical variables. However, since arguments over syntax are
likely to have plenty of issues of their own, we've separated this
proposal for primitive functionality from issues of syntax which
can be dealt with separately once this is passed.
Moon expressed concerns about the efficiency issues but after
thinking about it for a while convinced himself that this is
efficiently implementable both on stock and special purpose hardware.
JonL expressed concerns about the last-minute nature of this change,
which he sees as untested. This concern applies to the mixin of
the dynamic environment implicit in the LDG proposal.
Dalton suggests that an alternative solution to the speed issue
might be possible to obtain by restricting a particular variable to
be either LEXICAL or SPECIAL but not both.
Dalton points that even if people don't like the details here, there
must be a better fallback solution than "do nothing". Pitman agrees
heartily.
∂12-Dec-88 1528 X3J13-mailer Issue: TAILP-NIL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 15:27:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 15:18:20 PST
Date: 12 Dec 88 15:17 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TAILP-NIL (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-151820-5387@Xerox>
!
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
18-Oct-88, version 3 by van Roggen (just one proposal)
01-Dec-88, version 4 by Pitman (minor edits per discussion)
9-Dec-88, Version 5 by Masinter (clarify EQL)
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two implementations of this definition might be:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eql sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eql list sublist))
(if (eql sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Also at issue is the question of whether dotted lists are permissible
second arguments.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP sublist list) returns true iff (NTHCDR n list) is
sublist for some value of n, and false otherwise.
Note, however, that since the list may be dotted, so the end test
used by TAILP must be ATOM, not ENDP. That is, if (TAILP x l)
returns true, it means there was n such that (NTHCDR n list) would
return x; however, it doesn't follow that if TAILP returns false,
it is safe to go blithely NTHCDR's into the list looking for it,
since the list might be dotted and NTHCDR might hit bad data.
Note that TAILP uses EQL or equivalent to compare
sublist to list in the case where sublist is a number, etc.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Some reasons for preferring an ATOM check to ENDP include:
- The name TAILP suggests tails, not sublists. Some users might
expect this distinction to mean that data more general than
proper sublists.
- Making TAILP require lists limits its usefulness. If we did
not make this choice, some users would end up having to write
their own extended TAILP which we could just as well have
provided compatibly.
- TAILP is not considered to be used frequently enough in code
that the minor loss in speed to an ATOM check is worth the
lost functionality. Indeed, expanding the scope of its
capabilities may lead to more uses for TAILP.
- Other operators (eg, APPEND) have recently been extended to
treat dotted lists in an interesting way because users have
expressed a desire for this. As such, this change is
culturally consistent.
- Some implementations already support this feature, and the
wording in CLtL is sufficiently ambiguous that some users
might think it appropriate to depend on the feature. In the
absence of compelling efficiency reasons to the contrary,
we should lean toward extending some implementations rather
than tightening others in our efforts to achieve cross-dialect
consistency.
Examples:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns T under this proposal.
#4: (TAILP 3 '(A B C))
returns NIL under this proposal.
#5: (TAILP 3 '(A B C . 3))
returns T under this proposal.
#6: (TAILP '(X Y) '(A B C . 3))
returns NIL under this proposal.
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
Neither Lucid nor VAX LISP currently implements TAILP-NIL:T.
VAX LISP effectively implements definition "A" from the
Problem Description above.
Cost to Implementors:
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Avoids unnecessary incompatibilities between implementations.
Non-Benefits:
Slows down TAILP slightly in some implementations because ENDP is
potentially faster than ATOM.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
It recommended an earlier proposal, TAILP-NIL:NIL, which is effectively
equivalent to Definition "A" from the Problem Description.
Pitman introduced TAILP-NIL:T as an alternative, arguing that the
definition TAILP-NIL:NIL offered no practical value to programmers
in the disputed situations, while TAILP-NIL:T was of arguable usefulness.
Pitman and van Roggen support TAILP-NIL:T.
It was suggested more than once by more than one cleanup
committee member that we remove TAILP from the language
"since almost nobody uses it".
∂12-Dec-88 1601 X3J13-mailer Re: Issue: TEST-NOT-IF-NOT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:01:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 15:55:20 PST
Date: 12 Dec 88 15:53 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TEST-NOT-IF-NOT (Version 3)
In-reply-to: my message of 9 Dec 88 15:26 PST <881209-153026-1243@Xerox>
To: X3J13@sail.stanford.edu
Message-ID: <881212-155520-5496@Xerox>
The writeup in this issue was mislabelled Version 2. In fact, it was
Version 3, 1 Dec 88, Masinter (add comments).
The ballot will reflect this.
∂12-Dec-88 1609 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:09:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 16:01:09 PST
Date: 12 Dec 88 16:00 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-160109-5511@Xerox>
As JonL pointed out, Version 2 was missing a "not" in
a key sentence in the proposal.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
----- End Forwarded Messages -----
∂12-Dec-88 1623 X3J13-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:22:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 16:17:33 PST
Date: 12 Dec 88 16:17 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-161733-5559@Xerox>
!
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Version 2 by Masinter 2-Dec-88
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW):
Rewrite the specification so that it is clear that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not specified.
In particular, the results of calling UNREAD-CHAR after PEEK-CHAR
is unspecified.
Example:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
This is not legal, since the PEEK-CHAR for char2a "commits"
the character read by char1a, and so the unread-char is not legal.
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another did not.
In Symbolics Genera, for the Example above:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
Cost to Implementors:
Presumably none. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
<none>
∂12-Dec-88 1622 X3J13-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:22:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 16:11:10 PST
Date: 12 Dec 88 16:08 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-161110-5531@Xerox>
Thanks to Will Clinger for getting a last minute revision in.
!
Forum: Cleanup
Issue: REST-LIST-ALLOCATION
References: CLtL pp 107-108 (APPLY)
Related issues: DYNAMIC-EXTENT
Category: CLARIFICATION
Edit history: 8-Dec-88, Version 1 by Masinter
9-Dec-88, Version 2 by Clinger (add rationale, more discussion)
12-Dec-88, Version 3 by Clinger (delete bogus examples)
Problem description:
In the special case of calling a function with an &REST list via APPLY,
Common Lisp fails to specify whether a new copy of the list is freshly
allocated. For example, given
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
does
(APPLY #'FOO *MY-LIST*)
return T?
This issue is different from the question of the extent of "rest lists" in
the case when they *are* newly allocated which is indefinite; the issue
DYNAMIC-EXTENT also contains some proposals about extent.
Proposal (REST-LIST-ALLOCATION:NEWLY-ALLOCATED):
Specify that &REST lists are newly allocated in the case when the function
is called via APPLY.
Proposal (REST-LIST-ALLOCATION:MAY-SHARE):
Specify that the value of an &REST parameter is permitted, but not required,
to share (top-level) structure with the last argument to APPLY.
Proposal (REST-LIST-ALLOCATION:MUST-SHARE)
Specify that the value of an &REST parameter is required
to share (top-level) structure with the last argument to APPLY.
>> this needs better spec about how the args match <<
Examples:
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
(APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
; many stock hardware implementations
This implies that
(DEFUN BAR (&REST X) (RPLACA X 'D))
(APPLY #'BAR *MY-LIST*)
*MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
; hardware implementations
Another example: which of the following have the same semantics?
(setq x '(1 2 3))
[1] (apply #'foo 1 2 3 NIL)
[2] (apply #'foo 1 2 (cddr x))
[3] (apply #'foo 1 (cdr x))
[4] (apply #'foo x)
[5] (funcall #'foo 1 2 3)
Under REST-LIST-ALLOCATION:NEWLY-ALLOCATED:
[1]-[5] are equivalent.
Under REST-LIST-ALLOCATION:MAY-SHARE:
Any answer to the question is correct for some conceivable implementation.
Abstracting over implementations, this means that [1]-[5] are pairwise
non-equivalent.
Under REST-LIST-ALLOCATION:MUST-SHARE:
[1]-[4] are pairwise non-equivalent in all implementations. This proposal
leaves open the question of whether [1] is equivalent to [5].
And finally:
Should (defun foo (&rest x) ...)
behave (aside from efficiency) as if it were defined:
(defun foo (&rest G0047) ;Gensym really
(let ((x (copy-list G0047)))
...))
Rationale:
The semantics of APPLY is unclear. In consequence it is impossible
to write portable code that relies on &REST arguments sharing structure
with the last argument to APPLY. Portable code can rely on &REST arguments
*not* sharing structure with the last argument to APPLY, but only by
performing an explicit COPY-LIST on all &REST arguments; this is redundant
and inefficient in implementations where &REST arguments are newly
allocated anyway.
Current practice:
Some implementations always share. Some implementations never share.
A few may share interpreted and not share compiled, or vice versa.
Cost to Implementors:
None for MAY-SHARE, since that is the status quo. Both of the other
proposals entail a significant cost for some implementations.
If MUST-SHARE is adopted, then implementations that don't share structure
may be nearly impossible to convert. If NEWLY-ALLOCATED is adopted, then
implementations that do share will have to insert a call to COPY-LIST
inside either APPLY or &REST list handling, which will slow things down
and may be difficult as well.
Cost to Users:
No matter what, somebody gets hurt. MAY-SHARE means you have to
write awkward and inefficient code if you care. (This is already
the case for portable code.) MUST-SHARE means you have to add
explicit calls to COPY-LIST to code that assumes the contrary.
NEWLY-ALLOCATED means you have to rewrite code that assumes sharing.
Cost of non-adoption:
Great confusion over the issue. A certain amount of awkwardness and
inefficiency would remain inevitable if you want to write portable code.
Performance impact:
MUST-SHARE costs least in consing, but might slow down function call
for some implementations. MAY-SHARE lets implementations pick, has
least impact. NEWLY-ALLOCATED requires consing in cases where it
didn't before.
Benefits:
Less confusion. Improved portability.
Esthetics:
Differing, strongly held opinions.
Discussion:
The Revised3 Report on Scheme specifies that the equivalent of a
&REST argument must be a newly allocated list, to avoid precisely this
problem.
The argument for MUST-SHARE is that copying is inefficient, so
&REST should never cause copying of a list passed to it from APPLY.
Functions that desire a new copy can just call COPY-LIST.
Two arguments for MAY-SHARE are:
1. In no other place does Common Lisp automatically unshare structure,
except when the user is explicitly modifying the structure (as in REMOVE).
Making APPLY automatically unshare would be a semantic wart.
2. If APPLY copies its last argument, recursive programs that receive an
&REST argument and pass it to APPLY become inefficient. A linear time
algorithm can change to a quadratic time algorithm. While the efficiency
could be regained through compiler flow analysis in many cases, it's
better not to put the inefficiency into the language in the first place.
The DYNAMIC-EXTENT proposal would allow &REST lists
that were "newly allocated" to have dynamic extent if they were
to be passed down via APPLY. This puts the burden in the
right place.
Two (closely related) arguments for NEWLY-ALLOCATED:
1. The programmer's model of function calling is simpler: functions
take arguments, and any two calls that pass the same arguments to the
same function are equivalent. The MAY-SHARE and MUST-SHARE proposals
require a model in which functions generally take their arguments in
the form of a list, and the extent to which that list shares structure
with other lists in the system becomes an important part of the
semantics of a function call.
2. It's not only smashing a &rest argument that's a problem, it's
smashing any list that has been given as the last argument to APPLY as
well. Consider the following in an implementation that doesn't copy
the last argument to APPLY when it is passed as a &rest argument:
> (defvar *message*)
*MESSAGE*
> (defun set-message (&rest mess)
(setq *message* mess))
SET-MESSAGE
> (let ((winner (list 'a 'winner)))
(apply #'set-message winner)
(setf (cdr winner) (list 'loser))
winner)
(A LOSER)
Is *message* (A WINNER) or (A LOSER)? (It might be
(#<DTP-LOCATIVE 76123756> #<DTP-ODD-PC 12313453> ...)
but that's a different problem.) This suggests that once a list has
been given as the last argument to APPLY it is no longer OK to modify
it.
Gail Zacharias talked about the common idiom of simply doing a COPY-LIST
on every &rest argument, to insure some normalcy. Her reasoning seems
to bolster the case for those who claim that the current CL semantics
(MAY-SHARE) are deficient:
Subject: &REST Lists
Date: 24 Mar 88 12:23:15 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)
. . .
If Common Lisp doesn't require unshared &rest lists, then I think
it must provide a declarative version of this idiom so the COPY-LIST can
be portably avoided when it's redundant. Seems to me that the fact that
this is a common case where users find a need for conditionalization
indicates a real deficiency in Common Lisp's specification.
. . .
So we have a responsibility to resolve the very thorny issue
of REST-LIST-ALLOCATION.
∂12-Dec-88 1735 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:35:03 PST
Received: from fafnir.think.com by Think.COM; Mon, 12 Dec 88 19:47:10 EST
Return-Path: <kahle@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 12 Dec 88 20:33:03 EST
Received: from ungar.think.com by verdi.think.com; Mon, 12 Dec 88 20:31:35 EST
Received: by ungar.think.com; Mon, 12 Dec 88 20:32:57 EST
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
Message-Id: <8812130132.AA13377@ungar.think.com>
To: x3j13@sail.stanford.edu
Subject: CommonLisp/C interface
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable. On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
-brewster
Brewster@think.com
∂12-Dec-88 1755 X3J13-mailer Issue: TAILP-NIL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:55:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507602; Mon 12-Dec-88 20:55:04 EST
Date: Mon, 12 Dec 88 20:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: x3j13@sail.stanford.edu
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: <881212-151820-5387@Xerox>
Message-ID: <19881213015522.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Correction: Contrary to what the current practice section says,
the proposal TAILP-NIL:T is not what Symbolics Genera does. In
fact I know of no implementation that does what the proposal says.
However, I support the proposal anyway, because I think it's the
most consistent with the rest of Common Lisp.
∂12-Dec-88 1838 X3J13-mailer ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 18:38:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 18:16:49 PST
Date: 12 Dec 88 18:16 PST
From: masinter.pa@Xerox.COM
to: x3J13@sail.stanford.edu
Subject: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Message-ID: <881212-181649-5908@Xerox>
The issues and proposals named below have been mailed to the X3J13 mailing
list. (Hardcopy mail will follow.)
This ballot is "for informational purposes": If there are errors, problems,
or corrections to any of the issues-- especially the late-breaking ones--
please prepare amendments or new versions to bring to the January meeting.
The purpose of the ballot is to help us avoid discussing the
non-controversial issues; the ballot will tell us which issues should be
included in a "block" vote of endorsement/rejection. There will be
opportunity at the January meeting to correct mistakes or review issues, if
there is some belief that they were incorrectly framed, misunderstood, or
should otherwise be reviewed.
For each proposal, please chose one of the following:
[Y]es: adopt the Proposal
[N]o: don't adopt the Proposal
[I]f the following condition holds....
Only adopt the proposal given some precondition
[C]larify the following point & resubmit
You don't understand the proposal (please explain)
[A]bstain
You have read & understood the proposal but don't care
about the outcome
The result of the vote will be used by the cleanup committee:
Y (if majority): we will include in a "block" resolution
N (if majority): we will not raise the issue at X3J13
I: if no "unconditional" majority, your conditions will
affect what we propose to X3j13
C: we will attempt to clarify (even if the issue gets
a majority vote.)
Our goal is that all "voters" understand all
the issues.
A: your vote will not count in the total
Who can vote?
Anyone who wants to vote may do so, whether members of X3J13, observers, or
interested parties. Please indicate on your ballot your organization,
whether your organization is an X3J13 member, and whether your ballot is
the "official" position of your organization.
Reminders:
The fact that a proposal is before you does not mean that the cleanup
committee, or the person(s) listed as the author(s), actually endorse the
proposal. Please read the discussion section if you would like
testimonials.
Several of the proposals are interlinked in important ways. The linkage is
identified in each proposal. Please be careful to not vote for mutually
exclusive proposals.
There are a large number of issues remaining; some already "ready for
release". The selection criteria was to bring to ballot those issues which
were already pending prior to the October 1988 issue. (A few "new" issues
slipped in....) No "slight" of other issues is intended. We will bring to
the January meeting drafts of many of the issues still pending.
Only those issues modified since the October distribution have been
e-mailed to the X3J13 distribution list. All of these issues are available
online for anonymous FTP from host arisia.xerox.com, directory
clcleanup/pending. (User name "anonymous", any password.)
Again, due to my haste in preparing this ballot, there have been several
mistakes and "hasty" issue releases, for which I apologize.
I will not be reading electronic mail until after 3 January, so please send
administrative mail or ballots to cl-cleanup@sail.stanford.edu.
If you wish to mail your ballot in hardcopy form, please
send it to:
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94022
USA
before January 7.
If you wish to discuss several unrelated issues, please send a separate
message for each issue, preferably with Subject of the form "Re: Issue:
ISSUE-NAME (Version nnnn)".
!
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
DECLARATION-SCOPE:NO-HOISTING
DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW
Version 8, 7-Dec-88, Mailed 9-Dec-88
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
EXIT-EXTENT:MINIMAL
EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
FUNCTION-COMPOSITION:NEW-FUNCTIONS
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
TEST-NOT-IF-NOT:FLUSH-ALL
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂13-Dec-88 0800 X3J13-mailer CommonLisp/C interface
Received: from goldhill.com ([128.168.1.225]) by SAIL.Stanford.EDU with TCP; 13 Dec 88 07:58:08 PST
Received: by god.goldhill.com; Tue, 13 Dec 88 10:57:48 EST
Date: Tue, 13 Dec 88 10:57:48 EST
From: ejs@goldhill.com (Eric Swenson)
Message-Id: <8812131557.AA14746@goldhill.com>
To: x3j13@sail.stanford.edu
Cc: kahle@think.com
In-Reply-To: kahle@think.com's message of Mon, 12 Dec 88 20:32:57 EST <8812130132.AA13377@ungar.think.com>
Subject: CommonLisp/C interface
We at Gold Hill agree with Brewster's assessment that the lack of
standards vis-a-vis a foreign-function interface are a serious
deficiency for Common Lisp system programmers. Although the Lucid 3.0
foreign function interface may be lacking in some respects, it is
certainly a good starting place. I second the motion to adopt Lucid's
interface as a standard -- or at least the starting point for a standard.
-- Eric Swenson
Gold Hill Computers, Inc.
∂13-Dec-88 0819 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:19:22 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 13 Dec 88 10:29:30 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Dec 88 11:14:54 EST
Date: Tue, 13 Dec 88 11:15 EST
From: Barry Margolin <barmar@Think.COM>
Subject: CommonLisp/C interface
To: kahle@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8812130132.AA13377@ungar.think.com>
Message-Id: <19881213161509.5.BARMAR@OCCAM.THINK.COM>
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable.
It's a bit late in the process for us to consider an entirely new area
of standardization. We are hoping to get a draft standard out in the
next six months or so. We chartered ourselves with producing a standard
based primarily on CLtL, with the addition of necessary cleanups, an
object-oriented programming facility, error handling, and improved
iteration facilities, and we formed subcommittees to work on each area.
Had we planned on including foreign function calling at that time we
could have formed such a subcommittee, and I am confident that we would
have had something acceptable by this time. But at this time we are
basically finalizing our work, and I think it is not the time to start
discussing a new, potentially controversial aspect of the language.
On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
barmar
∂13-Dec-88 0833 X3J13-mailer Re: CommonLisp/C interface
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:32:56 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA01286; Tue, 13 Dec 88 08:34:57 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA17218; Tue, 13 Dec 88 08:31:37 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA02234; Tue, 13 Dec 88 08:32:11 PST
Message-Id: <8812131632.AA02234@suntana.sun.com>
To: ejs@goldhill.com (Eric Swenson)
Cc: x3j13@sail.stanford.edu, kahle@think.com
Subject: Re: CommonLisp/C interface
In-Reply-To: Your message of Tue, 13 Dec 88 10:57:48 -0500.
<8812131557.AA14746@goldhill.com>
Date: Tue, 13 Dec 88 08:32:07 PST
From: kempf@Sun.COM
Perhaps we can schedule a discussion and vote at the Hawaii meeting?
jak
∂13-Dec-88 1115 X3J13-mailer [barmar@Think.COM: CommonLisp/C interface]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:15:39 PST
Received: from kent-state ([192.9.200.24]) by heavens-gate.lucid.com id AA05058g; Tue, 13 Dec 88 11:12:46 PST
Received: by kent-state id AA01166g; Tue, 13 Dec 88 11:10:11 PST
Date: Tue, 13 Dec 88 11:10:11 PST
From: Harlan Sexton <hbs@lucid.com>
Message-Id: <8812131910.AA01166@kent-state>
To: kahle@Think.COM, barmar@Think.COM, ejs@goldhill.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Eric Benson's message of Tue, 13 Dec 88 10:00:56 pst <8812131800.AA00280@blacksox>
Subject: [barmar@Think.COM: CommonLisp/C interface]
I am very pleased to hear people pushing for a Common Lisp standard for a
foreign-function interface, and I am especially pleased that they like what
we did at Lucid enough to recommend it as a starting point. As Barry
Margolin mentioned in his mail, I wrote a survey/proposal for CL FFI's
which appeared in Lisp Pointers, and also in Computer Language, Aug. 1988.
(We can send hard-copies or a LaTeX "source" of this article to interested
parties.)
To summarize my views, I like Lucid's FFI best (not too surprising), but
each of the FFI's that I looked at (Franz ExCL, DEC Vax Lisp, Lucid CL)
have features that I feel belong in the standard and that are found in none
of the other FFI's. (KCL has, I think, the best Lisp to C interface of all,
but duplicating that in any other Lisp just doesn't seem feasible.)
Ideally we would have implemented my proposed standard FFI, but it was only
after implementing the one we did and using it that some of its
short-comings were seen. I then looked (again) at what had been done with
some other implementations, thought for awhile, and formulated a proposal
which seemed to add the features missing from what we had done (and to fix
some design warts).
I would be very interested in reactions to my proposal, because it
currently exists only on paper is still very easy to change. I expect that
we will eventually implement this proposal (although it is not scheduled or
even seriously planned at this time), and it would be nice to have some
outside reactions temper the design.
--Harlan
∂13-Dec-88 1120 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:20:12 PST
Received: from fafnir.think.com by Think.COM; Tue, 13 Dec 88 13:31:56 EST
Return-Path: <kahle@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 13 Dec 88 14:18:22 EST
Received: from ungar.think.com by verdi.think.com; Tue, 13 Dec 88 14:16:55 EST
Received: by ungar.think.com; Tue, 13 Dec 88 14:18:18 EST
Date: Tue, 13 Dec 88 14:18:18 EST
From: kahle@Think.COM
Message-Id: <8812131918.AA15056@ungar.think.com>
To: barmar@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 13 Dec 88 11:15 EST <19881213161509.5.BARMAR@OCCAM.THINK.COM>
Subject: CommonLisp/C interface
Date: Tue, 13 Dec 88 11:15 EST
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable.
It's a bit late in the process for us to consider an entirely new area
of standardization.
...
This is a reasonable reply, of course. I have not followed your committee,
so I am sending this out of the blue.
The reason I bring it up is that the foreign function interface (to C) has
become very important to us. Without a standard we will have a very
difficult time porting much of our software if we ever want to (and we have
no plans to port as far as I know).
On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
barmar
I suggested Lucid's interface to get the conversation rolling and no more.
I have not studied the other vendor's interfaces, but the lucid interface
is pretty good. I thought that making a specific recommendation would draw
out counter proposals.
-brewster
brewster@think.com
∂13-Dec-88 1233 X3J13-mailer Re: CommonLisp/C interface
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 12:33:39 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA07900; Tue, 13 Dec 88 15:28:14 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11784; Tue, 13 Dec 88 14:24:15 EST
Message-Id: <8812131924.AA11784@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: x3j13@sail.stanford.edu, kahle@think.com
Subject: Re: CommonLisp/C interface
In-Reply-To: Your message of Tue, 13 Dec 88 11:15:00 -0500.
<19881213161509.5.BARMAR@OCCAM.THINK.COM>
Date: Tue, 13 Dec 88 14:24:13 EST
From: Dan L. Pierson <pierson@mist.encore.com>
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
Well, actually Lucid rewrote their foreign function interface to
essentially what's in Harlan's paper for 3.0. So it would seem likely
that the responsible developer does support it.
I agree that it's late in the standardization process to entertain
major new areas. On the other hand, as Larry Masinter pointed out at
the last meeting, the foreign function interface is one of the three
most important remaining areas to standardize. By now, all stock
hardware vendors have significant experience in this area; at least
one vendor has moved to a second generation design (presumably after
discovering shortcomings in their first generation design).
Therefore, we do have a substantial body of current practice and
experience to draw on.
I think it would be well worthwhile to work some on this area and see
if there really is fundamental disagreement before assuming that we
can't succeed in time.
∂14-Dec-88 1043 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 10:43:16 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00847; Wed, 14 Dec 88 13:42:09 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA00470; Wed, 14 Dec 88 13:42:04 EST
Message-Id: <8812141842.AA00470@mist.>
To: Harlan Sexton <hbs@lucid.com>
Cc: x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Tue, 13 Dec 88 11:10:11 -0800.
<8812131910.AA01166@kent-state>
Date: Wed, 14 Dec 88 13:42:02 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I was confused, sorry. Of course your Lisp Pointers paper is
different from the Lucid 3.0 implementation. Your paper also looks
like an improvement, though it is missing a few important features
such as the ability to determine the size of a foreign structure.
We should establish a working group on foreign function interface at
the January meeting. Will you be able to be there?
We should also find a way to move this discussion to another mailing
listt, but I'm afraid that that may be tied up in question of moving
everything off of Sail...
∂14-Dec-88 1157 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 14 Dec 88 11:56:23 PST
Received: by goldhill.com; Wed, 14 Dec 88 14:55:55 EST
Date: Wed, 14 Dec 88 14:55:55 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8812141955.AA16807@goldhill.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 12 Dec 88 13:44 PST <881212-134536-5049@Xerox>
Subject: Issue: PACKAGE-CLUTTER (Version 6)
I just noticed two problems in this paragraph:
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
1. The spelling of the third word.
2. It should be OK for an implementation to use property list indicators
that are *internal* symbols in the LISP package. (Of course, the ``internal''
concept doesn't make sense, really, for keywords, and internal USER symbols
are the most common kind.)
∂14-Dec-88 1205 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88 12:05:31 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA03961; Wed, 14 Dec 88 12:07:13 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA04016; Wed, 14 Dec 88 12:03:50 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA04870; Wed, 14 Dec 88 11:24:33 PST
Message-Id: <8812141924.AA04870@suntana.sun.com>
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Harlan Sexton <hbs@lucid.com>, x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Wed, 14 Dec 88 13:42:02 -0500.
<8812141842.AA00470@mist.>
Date: Wed, 14 Dec 88 11:24:09 PST
From: kempf@Sun.COM
>We should establish a working group on foreign function interface at
>the January meeting.
This sounds like an excellent idea.
jak
∂14-Dec-88 1659 X3J13-mailer Hawaii registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 16:59:14 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA11077g; Wed, 14 Dec 88 16:56:28 PST
Received: by challenger id AA13417g; Wed, 14 Dec 88 16:52:36 PST
Date: Wed, 14 Dec 88 16:52:36 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812150052.AA13417@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration
Please let me know if there are any changes/additions. Note that there will
be room to bring guests to the luau, I just need to know how many.
---jan---
X3J13 Attendee Information
12/14/88
Name Institute Paid L1 L2 L3 Luau
Jim Antonisse MITRE Corp. 113.50 y y y 1
Bill Arbaugh U.S. Army -0- y y y -
Paul Beiser HP -0- y y y -
Jerome Chailloix ILOG -0- y y y -
Kathy Chapman DEC -0- y y y 1
Jeff Dalton University of Edinburgh -0- y y y -
Jerry Duggen HP -0- y y y -
Patrick Dussud Lucid, Inc. -0- y y y 1
Dick Gabriel Lucid, Inc. -0- y y y 1
Kevin Layer Franz, Inc. $75.00 y y y 1
Thom Linden IBM $75.00 y y y 1
David Loeffler MCC 113.50 y y y 1
Larry Masinter Xerox $75.00 y y y 1
Greg Nuyens ILOG -0- y y y -
Chris Perdue SUN MicroSystems -0- y y y 1
Jeff Rosenking Grumman Corp. -0- y y y -
David Unietis Lucid, Inc. -0- y y y 1
Mary Van Deusen IBM -0- y y y -
Ellen Waldrum TI $75.00 y y y 2
JonL White Lucid, Inc. -0- y y y 1
Jan Zubkoff Lucid, Inc. -0- y y y 2
∂14-Dec-88 1707 X3J13-mailer Re: CommonLisp/C interface
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88 17:06:25 PST
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 14 Dec 88 20:03:13 EST
To: Dan L. Pierson <pierson@mist.encore.com>
cc: Barry Margolin <barmar@Think.COM>, x3j13@sail.stanford.edu,
kahle@think.com
Subject: Re: CommonLisp/C interface
In-reply-to: Your message of Tue, 13 Dec 88 14:24:13 -0500.
<8812131924.AA11784@mist.>
Date: Wed, 14 Dec 88 20:00:32 EST
From: Rob.MacLachlan@WB1.CS.CMU.EDU
I agree that a foreign function call mechanism is an important part of any
Common Lisp implementation on an architecture that supports multiple
languages. Nonetheless, I think that attempts to standardize foreign
function call are premature. Good results are especially unlikely under
time pressure.
I believe that the acid test of a foreign interface facility is that it
can be use to define an interface to arbitrary foreign subroutine library.
Use of magical glue code that knows about Lisp or foreign data structure
representations isn't allowed.
Inter-language communication is in general a hard problem. The problem
isn't in calling a routine written in another language, it is with making
foreign data structures sensible. Consider complex data structures: linked
list structures, pointers to arrays of records, etc. Also consider byte
ordering, foreign compiler decisions about record packing, etc.
Since there are spurious proposals in the air, I propose that the CMU
Common Lisp Alien type, the associated C type definition macros, and the
DEFROUTINE macro be made part of Common Lisp. The CMU Lisp facility comes
a lot closer to meeting the desiderata than any other foreign interface
facility that I have seen. For example, we provided a complete interface
to version 10 Xlib without using any glue code.
This is a spurious proposal, since I am sure that our current facility can
be improved quite a bit. It was also never designed to be part of a
portable standard.
In addition to the technical issue of "do we know a good foreign interface
when we see one?", there is the language definition issue of "do we know
how to define a foreign interface mechanism in the Common Lisp context, and
does it make any sense to do so?"
The current standardization effort is undertaking to determine what it
means to "be Common Lisp": what properties all Common Lisp implementations
must have. Availability of C or any other foreign language is not a
required part of the Common Lisp environment, so it doesn't make any sense
to adopt a foreign interface mechanism as part of the core Common Lisp
standard.
People interested in standardizing interface to C should look to what was
done with CLX (the Common Lisp interface to X11.) Informal work on a
mailing list resulted in a Common Lisp extension that is available in
almost all environments where it is meaningful.
Rob
∂15-Dec-88 0929 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:28:42 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05577; 15 Dec 88 16:27 GMT
Date: Thu, 15 Dec 88 16:38:16 GMT
Message-Id: <6378.8812151638@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
To: kempf@sun.com, "Dan L. Pierson" <pierson%mist.encore.com@NSS.Cs.Ucl.AC.UK>
In-Reply-To: kempf@com.sun's message of Wed, 14 Dec 88 11:24:09 PST
Cc: Harlan Sexton <@sail.stanford.edu:hbs@lucid.com>, x3j13@sail.stanford.edu
>We should establish a working group on foreign function interface at
>the January meeting.
I too think this is a good idea.
It also turns out that the ISO Lisp working group, WG-16, is supposed
to comment on a document, "Working documents on CALLING MECHANISMS
and LANGUAGE-INDEPENDENT DATA TYPES", prepared by WG-11, the working
group for Language Bindings.
Anyone interested in these issues may want to comment, and the plan,
at the last WG-16 meeting, was for anyone interested to prepare
comments by the next WG-16 meeting, in March.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂15-Dec-88 0945 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:44:51 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA12664; Thu, 15 Dec 88 09:44:56 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA01149; Thu, 15 Dec 88 09:41:36 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA07434; Thu, 15 Dec 88 09:42:10 PST
Message-Id: <8812151742.AA07434@suntana.sun.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: kempf@Sun.COM, "Dan L. Pierson" <pierson%mist.encore.com@NSS.Cs.Ucl.AC.UK>,
Harlan Sexton <@sail.stanford.edu:hbs@lucid.com>,
x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Thu, 15 Dec 88 16:38:16 +0000.
<6378.8812151638@subnode.aiai.ed.ac.uk>
Date: Thu, 15 Dec 88 09:42:08 PST
From: kempf@Sun.COM
Jeff:
Could you bring along a copy of this document to the Hawaii
meeting, presuming you're coming. If not, perhaps you could let
us know where we could get it, or mail it electronically or otherwise?
Thanx.
I'll ask Jan Zubkov about arranging a subcommittee meeting.
jak
∂15-Dec-88 1504 X3J13-mailer Hawaii registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 15:04:29 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00573g; Thu, 15 Dec 88 15:01:40 PST
Received: by challenger id AA14949g; Thu, 15 Dec 88 14:56:18 PST
Date: Thu, 15 Dec 88 14:56:18 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812152256.AA14949@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration form
It's been a while since I've sent this....
X3J13/ISO Meeting
X3J13: 1/16/89 - 1/18/89
ISO: 1/19/89 - 1/20/89
Kauai, Hawaii
Committee Meeting:
Dates: 1/16/89 - 1/18/89
Time: 9:00 - 5:00
City: Kapaa, Kauai, Hawaii
Place: Sheraton Coconut Beach Hotel
REGISTRATION FEE: $75 Payable to: LUCID, Inc.
ISO Meeting:
Dates: 1/19/89 - 1/20/89
Hotel Accomodations:
Hotel: Sheraton Coconut Beach Hotel
Address: Coconut Plantation
Phone: 808/822-3455
Directions from airport:
Turn right onto route 56 north (Kuhio Highway)
Look for the 7 mile marker and take next right (can see hotel from the
road but it is not on the main road)
Rate: $80/night
Mention: "X3J13 Standards Committee" for rate
Group Luau:
Place: Shearton Coconut Grove
Date: 1/17/89
Time: TBA
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13/ISO January Meeting Registration Form
Please include check for $75.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________ Attend ISO _________
Lunch 1/16: _________ yes _______ no
Lunch 1/17: _________ yes _______ no
Lunch 1/18: _________ yes _______ no
Luau 1/17 $38.50: _________ yes _______ no
∂15-Dec-88 1525 X3J13-mailer Hawaii registration form OOOPS!
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 15:25:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00611g; Thu, 15 Dec 88 15:22:51 PST
Received: by challenger id AA15067g; Thu, 15 Dec 88 15:18:58 PST
Date: Thu, 15 Dec 88 15:18:58 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812152318.AA15067@challenger>
To: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Thu, 15 Dec 88 14:56:18 PST <8812152256.AA14949@challenger>
Subject: Hawaii registration form OOOPS!
Scratch the ISO meeting from the registration form. It really has been
cancelled.
---jan---
∂15-Dec-88 1715 X3J13-mailer Symbolics Cambridge office is moving
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Dec 88 17:15:23 PST
Date: Thu, 15 Dec 88 20:16:17 EST
From: KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@AI.AI.MIT.EDU
Subject: Symbolics Cambridge office is moving
To: X3J13@SAIL.STANFORD.EDU
Message-ID: <505706.881215.KMP@AI.AI.MIT.EDU>
The Symbolics Cambridge office (corporate HQ and R&D) is moving to
Burlington this week. Our file servers will be offline for some of
the transition and mail to me, Moon, etc. may bounce. If you get
back mail because Symbolics doesn't respond (and if it's possible,
convenient, etc.), please hang onto any bounced messages and
re-send them to us mid next week when things will (hopefully) be
back in order. Thanks very much.
∂16-Dec-88 0847 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 16 Dec 88 08:47:33 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05376; 16 Dec 88 16:11 GMT
Date: Fri, 16 Dec 88 16:22:55 GMT
Message-Id: <7682.8812161622@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
To: kempf@sun.com, x3j13@sail.stanford.edu
In-Reply-To: kempf@com.sun's message of Thu, 15 Dec 88 09:42:08 PST
Cc: pierson <@NSS.Cs.Ucl.AC.UK:pierson@mist.encore.com>,
hbs <@sail.stanford.edu:hbs@lucid.com>
> Could you bring along a copy of this document to the Hawaii
> meeting, presuming you're coming. If not, perhaps you could let
> us know where we could get it, or mail it electronically or otherwise?
Dick Gabriel should have received a copy fro ISO. I've received
several by now, via various paths, and will try to remmeber to
bring one.
-- Jeff
∂19-Dec-88 2242 X3J13-mailer Corrections to the ISO Report
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Dec 88 22:42:08 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03191g; Mon, 19 Dec 88 22:39:08 PST
Received: by challenger id AA19722g; Mon, 19 Dec 88 22:35:13 PST
Date: Mon, 19 Dec 88 22:35:13 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8812200635.AA19722@challenger>
To: x3j13@sail.stanford.edu
Subject: Corrections to the ISO Report
Colleagues:
There have been a couple of questions directed privately to me about
my ISO meeting report. I think the answers are of general interest, so
I will direct them to the X3J13 mailing list.
1. The first regards the Japanese position on CLOS. I believe there
are two concerns that the Japanese have: one is that the CLOS
specification is difficult to read and thus is difficult to evaluate;
the other is that CLOS is comparatively new and represents relatively
recent research, which leads them to believe that it would be good to
gather some practical experience with it before international
standardization. I believe this is a reasonable position. I believe
the US must make its case convincingly for the Japanese to agree to
adopting CLOS into a near-term international standard.
2. There was a wording problem with my comments on the AFNOR
delegation's response to the US position. The US indeed voted to
accept the New Work Item that is the basis for the establishment of
WG16. At the first meeting AFNOR proposed a work plan (which I
inaccurately referred to as a ``work item''). The proposed work plan
is to adopt Common Lisp as the starting point for IsLisp but to try to
alter Common Lisp in certain ways. The structure of the work plan is
to identify features of Common Lisp that WG16 should alter and to
associate with the feature a default. For each such feature, if no
acceptable technical alternative to the feature is determined within a
reasonable time period, the default replaces the feature. For
example, the package system is on the list of features to alter, and
if no better solution than the current Common Lisp package system is
determined, the default is to provide only a flat namespace - that is,
the default is no package system. The US did not agree to this work
plan, and the evidence for this is simply that the acceptability of
the work plan never came to a vote at WG16. Therefore, the US did not
change its position regarding this work plan, and the current US
position is the first time the US took any position with regard to the
work plan for WG16 proposed by the AFNOR delegation.
When the AFNOR delegation stated that the US position represented a
``preposterous'' change in position by the US, I interpreted their
statement as a response to an incorrectly perceived change in position
by the US regarding the never-agreed-on AFNOR-proposed work plan. The
only alternative interpretation I could think of is that the AFNOR
delegation incorrectly perceived a change in position by the US to the
New Work Item that defines the goal of WG16. Since the latter
interpretation is illogical, I adopted the other one.
3. There was a minor error in my report on the presentation by Mr
Kurokowa. The following is the amended section (the word that should
be deleted is in [square brackets]):
``Mr Kurokowa presented a report on Japanese activity on provisions
within [Common] Lisp for international character sets. Thom Linden
presented the latest X3J13 work on the same topic. In addition, the
U.S. was asked to present the current WG16 status on character
handling at the next SC22 meeting.''
That is, Mr Kurokowa discussed international character set handling
for an internationally standardized Lisp and not for Common Lisp.
-rpg-
∂20-Dec-88 0233 X3J13-mailer Gabriel's report
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Dec 88 02:33:05 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab19605; 20 Dec 88 4:03 EST
Received: from utokyo-relay by RELAY.CS.NET id ab03791; 20 Dec 88 3:58 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA21505; Tue, 20 Dec 88 16:24:50 JST
Received: by nttlab.ntt.jp (3.2/6.2NTT.h) with TCP; Tue, 20 Dec 88 15:56:01 JST
Received: by tutics.tut.junet (ver3.3/6.2J/systemV)
id AA07407; Tue, 20 Dec 88 12:37:46 jst
Message-Id: <8812201237.AA07407@tutics.tut.junet>
Date: Tue, 20 Dec 88 12:37:46 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
To: x3j13@SAIL.STANFORD.EDU
Subject: Gabriel's report
Cc: RPG@SAIL.STANFORD.EDU
As a secretary of Japanese SC22/LISP WG, I have some comments on Richar
d
Gabriel's report on the November ISO meeting.
> Mr. Kurokawa presented a report on Japanese activity on
> provisions within Common Lisp for international character sets.
This sentence is wrong. The Japanese SC22/LISP WG is working for ISO
standard, but NOT for Common Lisp standard. Mr. Kurokawa is supposed t
o
have presented (and he confirmed me that he indeed presented) a Japanes
e
contribution on international character set handling within ISO standar
d,
but not necessarily within Common Lisp. He may have used some Common L
isp
terminology, but this is because of the WG16 agreement that Common Lisp
be a starting point.
> Professor Ito
> is primarily concerned about CLOS,
This is true. And, this is not only his personal concern, but a genera
l
concern of Japanese Lisp WG as well. It seems to me that this is a mor
e
general concern of the Japanese computer science community, since CLOS
has not received a citizenship in object-oriented world in Japan.
> but after private discussions I
> learned that because of lack of study he did not understand it,
This is not true. I know he fully understands CLOS. Note, however, th
at
it is painful to read the CLOS document, especially when no one has off
icially
proposed it to WG16, and when inclusion of CLOS to ISO standard is so d
oubtful
in one's country.
> and
> the expert group that advises him consists of object-oriented
> programming researchers who press their own ideas on him.
I'm afraid this sentence came from Gabriel's misunderstanding or prejud
ice
about Japanese activities for Lisp standardization. Prof. Ito himself
is a programming expert (he is one of the first Lisp hackers in Japan)
and
his opinion has been reflected to "the expert group" to a great extent.
Programming experts including Prof. Ito himself is working very hard fo
r
ISO standard, as well as investigating their own ideas.
To sum up, I found the sentences of Gabriel's report concerning with
Japanese activities are quite misleading. I hope my comments can
help you avoid misinterpretation of these sentences.
-- Taiichi Yuasa
∂20-Dec-88 0757 X3J13-mailer Re: Gabriel's report
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Dec 88 07:57:15 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA28013; Tue, 20 Dec 88 07:59:03 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA28535; Tue, 20 Dec 88 07:55:43 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA18561; Tue, 20 Dec 88 07:56:17 PST
Message-Id: <8812201556.AA18561@suntana.sun.com>
To: Taiichi Yuasa <yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Cc: x3j13@SAIL.STANFORD.EDU, RPG@SAIL.STANFORD.EDU
Subject: Re: Gabriel's report
In-Reply-To: Your message of Tue, 20 Dec 88 12:37:46 +0200.
<8812201237.AA07407@tutics.tut.junet>
Date: Tue, 20 Dec 88 07:56:14 PST
From: kempf@Sun.COM
>concern of Japanese Lisp WG as well. It seems to me that this is a more
>general concern of the Japanese computer science community, since CLOS
>has not received a citizenship in object-oriented world in Japan.
What, precisely, is the Japanese concern with CLOS? The committee has
made an effort over the past 2 years to remain open to suggestions
about modifying the design. There have been several electronic mail
messages from someone in Japan on the subject (it may have been Prof. Ito)
which have been taken into account during the design. What changes do
the Japanese delegates feel are needed (if any) for CLOS to receive
"full citizenship" in the Japanese object-oriented world, presuming,
of course, that Common Lisp is accepeted as an adequate base? Is there
a reasonable chance that CLOS can achieve that status, or do most
Japanese object-oriented programmers feel more confortable using Smalltalk?
jak
∂20-Dec-88 1137 X3J13-mailer access to the standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88 11:37:37 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA29610; Tue, 20 Dec 88 11:36:35 PST
Message-Id: <8812201936.AA29610@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 14:02
To: x3j13@sail.stanford.edu
Subject: access to the standard
Following is the updated account information for accessing the
working draft of the standard:
Username: ftp_user
Password: merrychristmas
Node: hudson@dec.com
The password has changed.
kc
∂22-Dec-88 1139 X3J13-mailer Error terminology
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Dec 88 11:39:15 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04427g; Wed, 21 Dec 88 22:05:23 PST
Received: by bhopal id AA10159g; Wed, 21 Dec 88 22:06:00 PST
Date: Wed, 21 Dec 88 22:06:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812220606.AA10159@bhopal>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 3 Oct 88 15:42 <8810031951.AA06841@decwrl.dec.com>
Subject: Error terminology
re: - THE "CONSEQUENCES ARE UNSPECIFIED"
means that
. . .
- ... and all portable programs are required to treat
the situation as unpredictable but harmless.
It looks like to me that "harmless" has the same lack of specificity
as Barry's word "benign". Taken in context of the rest of your message,
it could only mean "not fatal". Is that good enough?
[By the bye, was this msg really intended for x3j13 distribution? or
should it have been cl-editorial?]
-- JonL --
∂22-Dec-88 1241 X3J13-mailer Re: Corrections to the ISO Report
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Dec 88 12:35:20 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06698; 22 Dec 88 20:30 GMT
Date: Thu, 22 Dec 88 20:27:12 GMT
Message-Id: <20454.8812222027@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Corrections to the ISO Report
To: rpg <@sail.stanford.edu:rpg@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Mon, 19 Dec 88 22:35:13 PST
> 2. There was a wording problem with my comments on the AFNOR
> delegation's response to the US position.
I think there are two issues. One is that the NWI does not talk
about multiple standards for multiple varieties ("dialects" might
be prejudicial) of Lisp. At the first WG-16 meeting in Paris,
the US made the point that an ISO standard named something like
"ISO Lisp" might seem to preclude standards for other varieties
of Lisp but there was not, as far as I can recall (I haven't checked
my notes), anything said about multiple standards under the current
Work Item. The US seemed willing then to have WG-16 work on a
single standard, even one based on Common Lisp. Indeed, the US
insisted that the WG-16 schedule (the 18 months) required a starting
point in existing work, and the US voted for "Common Lisp or Scheme"
as the starting point.
This brings us to the second issue, for which you have found the
convenient term "work plan". I think the following is a fair
summary:
1. At the first WG-16, the US cooperated in drafting the work
plan and did not voice strong objections. We can contrast
this with the US approach to the name of the standard, where
the US made it clear that "ISO Lisp" was unacceptable.
However, the US made the point that any deviation from
CL would need an environmental impact statement.
2. At the second WG-16, the US was unhappy with some of the defaults
and preferred that changes be deletions (so that the ISO standard
would be a strict rather than "extended" subset). It was
explained, by the Convenor and others, that the default values
would not be adopted just because they were the defaults. The
US seemed to accept this explanation.
3. Before the third WG-16, the US distributed a position statement
which, in effect, said that the US would oppose any changes to
Common Lisp that were not deletions. This was a hardening of
what seemed to be the US position in the second meeting, because
changes would be opposed simply because they were not deletions,
regardless of technical or practical merit. (Of course,
deletions might still be opposed on those grounds, and such
reasons might be given as additional reasons for opposing
non-deletions.)
So, it appears to me that the US position has changed. Whether it
is a "preposterous" change is less clear. It might be argued that
the position has evolved. Nonetheless,
> The US did not agree to this work plan, and the evidence for this
> is simply that the acceptability of the work plan never came to a
> vote at WG16. Therefore, the US did not change its position regarding
> this work plan, and the current US position is the first time the US
> took any position with regard to the work plan for WG16 proposed by the
> AFNOR delegation.
It can be argued that the US has officially said only three things.
One is the comment on the NWI stating opposition to the name "ISO
Lisp". Another is the position statement distributed before the
3rd WG-16. Then, finally, there's the proposal for an ISO Common
Lisp standard presented at the 3rd meeting. Indeed, it might be
argued that only the first is really official, because only it
involved a vote in X3J13 (if even that is enough). However, if
we're to take a "letter of the law" approach, it must be noted that
a change from no official position to official opposition is still
a change.
There is one additional point I would like to make. Although the
initial list of issues and defaults, and the idea that we should
proceed in this way, came from AFNOR, the final list was the result
of comments by other countries, including the US. Moreover, there
appeared to be a consensus (that included the US) on the following
statement:
The draft standard to be provided by the Working Group within
18 months will take as starting point Common Lisp (with X3J13
cleanups) with treatment of major issues and default values
to be identified (including issues in the AFNOR list and on
agenda).
> When the AFNOR delegation stated that the US position represented a
> ``preposterous'' change in position by the US, I interpreted their
> statement as a response to an incorrectly perceived change in position
> by the US regarding the never-agreed-on AFNOR-proposed work plan. The
> only alternative interpretation I could think of is that the AFNOR
> delegation incorrectly perceived a change in position by the US to the
> New Work Item that defines the goal of WG16. Since the latter
> interpretation is illogical, I adopted the other one.
I think you were right to adopt the other one.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂22-Dec-88 1447 X3J13-mailer Re: Corrections to the ISO Report
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Dec 88 14:45:02 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06698; 22 Dec 88 20:30 GMT
Date: Thu, 22 Dec 88 20:27:12 GMT
Message-Id: <20454.8812222027@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Corrections to the ISO Report
To: rpg <@sail.stanford.edu:rpg@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Mon, 19 Dec 88 22:35:13 PST
> 2. There was a wording problem with my comments on the AFNOR
> delegation's response to the US position.
I think there are two issues. One is that the NWI does not talk
about multiple standards for multiple varieties ("dialects" might
be prejudicial) of Lisp. At the first WG-16 meeting in Paris,
the US made the point that an ISO standard named something like
"ISO Lisp" might seem to preclude standards for other varieties
of Lisp but there was not, as far as I can recall (I haven't checked
my notes), anything said about multiple standards under the current
Work Item. The US seemed willing then to have WG-16 work on a
single standard, even one based on Common Lisp. Indeed, the US
insisted that the WG-16 schedule (the 18 months) required a starting
point in existing work, and the US voted for "Common Lisp or Scheme"
as the starting point.
This brings us to the second issue, for which you have found the
convenient term "work plan". I think the following is a fair
summary:
1. At the first WG-16, the US cooperated in drafting the work
plan and did not voice strong objections. We can contrast
this with the US approach to the name of the standard, where
the US made it clear that "ISO Lisp" was unacceptable.
However, the US made the point that any deviation from
CL would need an environmental impact statement.
2. At the second WG-16, the US was unhappy with some of the defaults
and preferred that changes be deletions (so that the ISO standard
would be a strict rather than "extended" subset). It was
explained, by the Convenor and others, that the default values
would not be adopted just because they were the defaults. The
US seemed to accept this explanation.
3. Before the third WG-16, the US distributed a position statement
which, in effect, said that the US would oppose any changes to
Common Lisp that were not deletions. This was a hardening of
what seemed to be the US position in the second meeting, because
changes would be opposed simply because they were not deletions,
regardless of technical or practical merit. (Of course,
deletions might still be opposed on those grounds, and such
reasons might be given as additional reasons for opposing
non-deletions.)
So, it appears to me that the US position has changed. Whether it
is a "preposterous" change is less clear. It might be argued that
the position has evolved. Nonetheless,
> The US did not agree to this work plan, and the evidence for this
> is simply that the acceptability of the work plan never came to a
> vote at WG16. Therefore, the US did not change its position regarding
> this work plan, and the current US position is the first time the US
> took any position with regard to the work plan for WG16 proposed by the
> AFNOR delegation.
It can be argued that the US has officially said only three things.
One is the comment on the NWI stating opposition to the name "ISO
Lisp". Another is the position statement distributed before the
3rd WG-16. Then, finally, there's the proposal for an ISO Common
Lisp standard presented at the 3rd meeting. Indeed, it might be
argued that only the first is really official, because only it
involved a vote in X3J13 (if even that is enough). However, if
we're to take a "letter of the law" approach, it must be noted that
a change from no official position to official opposition is still
a change.
There is one additional point I would like to make. Although the
initial list of issues and defaults, and the idea that we should
proceed in this way, came from AFNOR, the final list was the result
of comments by other countries, including the US. Moreover, there
appeared to be a consensus (that included the US) on the following
statement:
The draft standard to be provided by the Working Group within
18 months will take as starting point Common Lisp (with X3J13
cleanups) with treatment of major issues and default values
to be identified (including issues in the AFNOR list and on
agenda).
> When the AFNOR delegation stated that the US position represented a
> ``preposterous'' change in position by the US, I interpreted their
> statement as a response to an incorrectly perceived change in position
> by the US regarding the never-agreed-on AFNOR-proposed work plan. The
> only alternative interpretation I could think of is that the AFNOR
> delegation incorrectly perceived a change in position by the US to the
> New Work Item that defines the goal of WG16. Since the latter
> interpretation is illogical, I adopted the other one.
I think you were right to adopt the other one.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂03-Jan-89 1228 X3J13-mailer Hawaii registration status
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 12:27:56 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03395g; Tue, 3 Jan 89 12:24:09 PST
Received: by challenger id AA07960g; Tue, 3 Jan 89 12:20:10 PST
Date: Tue, 3 Jan 89 12:20:10 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901032020.AA07960@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration status
Please let me know if you have any changes.
---jan---
X3J13 Attendee Information
01/03/89
Name Institute Paid L1 L2 L3 Luau
Jim Antonisse MITRE Corp. 113.50 y y y 1
Bill Arbaugh U.S. Army -0- y y y -
Kim Barrett Integrated Inference 113.50 y y y 1
David Bartley Texas Instruments $75.00 y y y -
Paul Beiser HP -0- y y y -
Skona Brittan Microcomputer Systems -0- y y y -
Jerome Chailloix ILOG -0- y y y -
Kathy Chapman DEC -0- y y y 2
Jeff Dalton University of Edinburgh -0- y y y 1
Jerry Duggen HP -0- y y y 2
Patrick Dussud Lucid, Inc. -0- y y y 1
Dick Gabriel Lucid, Inc. -0- y y y 3
George Hadden Honeywell -0- y y y 2
Jim Kempf SUN Microsytsems -0- y y y 1
Gregor Kiczales Xerox Corp. -0- y y y 1
Aaron Larson Honeywell -0- y y y 2
Kevin Layer Franz, Inc. $75.00 y y y 1
Thom Linden IBM $75.00 y y y 3
David Loeffler MCC 113.50 y y y 1
Sandra Loosemore University of Utah -0- y y y -
Barry Margolin Thinking Machines, Inc. 113.50 y y y y
Larry Masinter Xerox $75.00 y y y 1
Robert Mathis CONTEL -0- y y y 4
David Moon Symbolics, Inc. -0- 1 1 1 -
Greg Nuyens ILOG -0- y y y -
Chris Perdue SUN MicroSystems -0- y y y 1
Dan Pierson Encore Computer -0- y y y 1
Jeff Rosenking Grumman Corp. -0- y y y -
Paul Tucker IBM -0- y y y 2
David Unietis Lucid, Inc. -0- y y y 1
Mary Van Deusen IBM -0- y y y -
Ellen Waldrum TI $75.00 y y y 2
JonL White Lucid, Inc. -0- y y y 1
Gail Zacharias Coral Software Corp. -0- y y y 2
Jan Zubkoff Lucid, Inc. -0- y y y 2
∂03-Jan-89 1324 X3J13-mailer issues from cl-compiler
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 13:24:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA27137; Tue, 3 Jan 89 14:23:35 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA05977; Tue, 3 Jan 89 14:23:33 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032123.AA05977@defun.utah.edu>
Date: Tue, 3 Jan 89 14:23:32 MST
Subject: issues from cl-compiler
To: x3j13@sail.stanford.edu
I will be sending out a number of issues from the compiler committee
over the next several days. We plan to discuss these at the upcoming
meeting and vote on any that appear to be noncontroversial. Some of
the issues are marked **DRAFT**; these are issues that we do not feel
have had enough consideration to be voted upon yet, but where we would
like to get feedback from a larger group.
Please send comments on these issues to cl-compiler@sail.stanford.edu
(-not- to the X3J13 mailing list). Alternatively, we will consider
amendments at the upcoming meeting. (Having your amendment written
down in advance will help considerably in reducing confusion.)
-Sandra
-------
∂03-Jan-89 1424 X3J13-mailer issue ALLOW-LOCAL-INLINE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:24:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00523; Tue, 3 Jan 89 15:23:04 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06032; Tue, 3 Jan 89 15:23:02 MST
Date: Tue, 3 Jan 89 15:23:02 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032223.AA06032@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue ALLOW-LOCAL-INLINE
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: ALLOW-LOCAL-INLINE
References: CLtL p. 156, 159
Related issues: PROCLAIM-INLINE-WHERE
Category: CLARIFICATION
Edit History: 21 Sept. 88 V1 by David Gray
27 Oct. 88 V2 by David Gray - new proposal
9 Nov. 88 V3 by David Gray - expanded problem
description and discussion sections.
30 Dec. 88 V4 by Sandra Loosemore -- suggestions from Pitman
Problem Description:
The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
on 10/12/88) clarifies the use of INLINE proclamations, but there
remains a similar problem with the use of a local (DECLARE (INLINE
...)): how can the compiler expand the function inline if it didn't
know that the necessary information should have been saved when the
function was compiled?
Note that an INLINE proclamation does two things:
(1) It tells the compiler to do extra things when it sees the
function -definition-, to make it possible to code the function
inline.
(2) It tells the compiler to code -calls- to the function inline.
In order for local INLINE declarations to be useful, we need part 1
without part 2.
Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE
Clarify that to define a function FOO which is not INLINE by default
but for which (DECLARE (INLINE FOO)) will make FOO be locally inlined,
the proper definition sequence is:
(PROCLAIM '(INLINE foo))
(DEFUN foo ...)
(PROCLAIM '(NOTINLINE foo))
The INLINE proclamation preceding the DEFUN ensures that compiler will
save the information necessary for inline expansion, and the NOTINLINE
proclamation following the DEFUN prevents it from being expanded
inline everywhere.
Note that while implementations are never required to perform inline
expansion of function calls, many implementations that do support
inline expansion will not be able to respond to local INLINE requests
if this technique is not followed.
Rationale:
Local INLINE declarations are of little use without some way of
alerting the compiler to the possibility of inline expansion before
the function is compiled. This seems the simplest solution since it
just clarifies existing practice instead of adding a new feature to
the language.
A compiler could use some heuristic to save the definitions of functions
that are short enough to look like good candidates for inline expansion,
but then the user is never sure what to expect. It is possible that a
compiler could simply save all definitions (assuming availability
of adequate storage space) but we shouldn't require that.
Test Cases/Examples:
Given the following input to COMPILE-FILE, does F1 get expanded inline
in F2, and does F3 get expanded inline in F4?
(defun f1 (a) (+ a 100))
(defun f2 (b) (declare (inline f1)) (f1 b))
(proclaim '(inline f3))
(defun f3 (a) (+ a 100))
(proclaim '(notinline f3))
(defun f4 (b) (f3 b)) ;F3 is not inline.
(defun f5 (c) (declare (inline f3)) (f3 c)) ;F3 is locally inline.
(defun f6 (c) (f3 c)) ;The local effect is not
; persistent.
Current Practice:
In the example above, using Symbolics, Lucid, or Explorer, F1 is not
expanded in F2, but F3 is expanded in F5.
Cost to implementors:
None, since this is a clarification in accordance with current
practice.
Cost to users:
None.
Benefits:
Users will be able to use (DECLARE (INLINE ...)) with greater assurance
that it will really do something.
Costs of Non-Adoption:
Users will not know how to reliably request inline expansion on a
local basis. This technique is not obvious, and even the need
for it likely to be apparent only to people who understand something
about how the compiler does inline expansion.
Discussion:
Version 1 of this issue included proposal
ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE to make an addition to the
language:
(PROCLAIM '(ALLOW-INLINE foo))
This was met with a lack of enthusiasm since it was pointed out that
the same effect could be obtained by using a combination of INLINE and
NOTINLINE.
This is may not be completely true, however, since people's thinking
about NOTINLINE has evolved in the direction of a declaration that
tells the compiler "assume nothing about this function". Thus, a
NOTINLINE proclamation might suppress some optimizations that would
have occurred if there had never been an INLINE and NOTINLINE.
Ideally, it would be nice to have multiple levels of control instead
of just INLINE or NOTINLINE -- something like:
* always inline
* maybe inline (let the compiler decide)
* just save the definition for possible local inline
* default
* never inline
Pitman has said that he generally approves of the direction of this
proposal, but he has also expressed concerns about how the persistance
of INLINE proclamations may cause confusion when functions are redefined
in an incremental development environment.
∂03-Jan-89 1428 X3J13-mailer issue DEFCONSTANT-SPECIAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:28:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00602; Tue, 3 Jan 89 15:26:55 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06038; Tue, 3 Jan 89 15:26:53 MST
Date: Tue, 3 Jan 89 15:26:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032226.AA06038@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue DEFCONSTANT-SPECIAL
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: DEFCONSTANT-SPECIAL
References: CLtL p. 68-69, 55-56
Issue DEFCONSTANT-NOT-WIRED
Issue PROCLAIM-LEXICAL
Issue SYNTACTIC-ENVIRONMENT-ACCESS
Issue SPECIAL-VARIABLE-TEST
Category: CLARIFICATION
Edit History: V1, 15 Nov 1988, Sandra Loosemore
V2, 22 Nov 1988, Sandra Loosemore
V3, 30 Dec 1988, Sandra Loosemore
Problem Description:
It is unclear whether DEFCONSTANT is supposed to proclaim the variable
SPECIAL. Page 56 says that symbols defined by DEFCONSTANT "may not be
further assigned to or bound". Page 69 says that "further assignment
to or binding of that special variable is an error" but permits
compilers to "choose to issue warnings about bindings of the lexical
variable of the same name". Does this mean that it is legal (but
perhaps only questionable style) to lexically rebind constants? If
so, this would seem to imply that they must not be proclaimed SPECIAL
(since CLtL provides no way to override a SPECIAL proclamation).
Some people think that DEFCONSTANT is supposed to proclaim the
variable SPECIAL because CLtL says that DEFVAR does, and that
DEFPARAMETER is like DEFVAR, and DEFCONSTANT is like DEFPARAMETER.
Also, the use of the phrase "that special variable" rather than "the
special variable of the same name" might indicate that the variable
really is supposed to be special.
Proposal DEFCONSTANT-SPECIAL:NO:
Clarify that DEFCONSTANT does not proclaim the variable special, but
that it is an error to rebind constant symbols as either lexical or
special variables. (In other words, a reference to a symbol declared
with DEFCONSTANT always refers to its global value.)
Rationale:
If DEFCONSTANT declared the variable special, the lexical rebindings
mentioned on p. 69 could never arise. Clarifying that lexical
rebinding (as well as special rebinding) of constants "is an error"
seems to be the behavior that most users expect. One serious problem
that might arise from allowing constants to be rebound lexically is
that it would not be reliable to include symbolic constants in macro
expansions, because the user might have rebound them to something
else.
Current Practice:
Most implementations apparently proclaim the variable special anyway.
Cost to implementors:
Minor.
Cost to users:
Probably none. Since many implementations do proclaim the variable to
be special (while at the same time forbidding special binding), there
is probably no user code that depends upon lexical rebinding of
DEFCONSTANTs.
Benefits:
An area of confusion in the language is removed.
Discussion:
This issue is primarily a documentation clarification. It arose
during a discussion of what the DEFCONSTANT macro might expand into.
As far as users are concerned, it makes no difference whether
constants are special or lexical, as long as all rebinding is
prohibited. The only situation where the distinction might become
important is if a function is added to the language to test whether a
variable has been proclaimed special.
The "problem description" section of the writeup on issue
PROCLAIM-LEXICAL (version 8) also appears to assume that constants
declared with DEFCONSTANT are not special.
∂03-Jan-89 1426 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:25:59 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00548; Tue, 3 Jan 89 15:24:53 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06035; Tue, 3 Jan 89 15:24:49 MST
Date: Tue, 3 Jan 89 15:24:49 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032224.AA06035@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program. While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase. For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation. User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.
In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.
In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well. Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.
(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.
(a) Macro definitions must be available in the compiletime environment.
The compiler may assume that forms that are lists beginning with
a symbol that does not name a macro or special form is a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) Special variables must be declared as such before they are bound.
The compiler must treat any undeclared variable binding as a
lexical binding.
(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment. However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment. Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation. In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compile may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
retain the same definition in the runtime environment as in the
compiletime environment. (Note that it is not an error for an
unknown type to appear in a declaration at compiletime, although
it is reasonable for the compiler to emit a warning in such a
case.)
(h) The compiler may assume that a class name defined by DEFCLASS
that is present in the compiletime environment will also be a
class name at runtime, and that class will be an instance of the
same metaclass. There may be additional conformance requirements
imposed by the metaclass, but there are none for STANDARD-CLASS.
(i) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the behavior of the program is undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above. It is, however,
reasonable for the compiler to emit warning messages about
calls to functions that are defined at compiletime, but where
the wrong number or type of arguments are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible to emit
a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
I know of no compiler that does not implement the provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
∂03-Jan-89 1432 X3J13-mailer issue SHARP-COMMA-CONFUSION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:31:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00762; Tue, 3 Jan 89 15:30:48 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06046; Tue, 3 Jan 89 15:30:43 MST
Date: Tue, 3 Jan 89 15:30:43 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032230.AA06046@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue SHARP-COMMA-CONFUSION
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: SHARP-COMMA-CONFUSION
References: CLtL p. 356
Issue LOAD-TIME-EVAL
Category: CHANGE
Edit History: V1, 17 Oct 1988, Sandra Loosemore
V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)
Problem Description:
The way the read macro #, is defined in CLtL does not make it clear
that it can only appear inside of (implicitly) quoted structure to
guarantee consistent handling between the interpreter and the
compiler. Examples of inconsistent uses would be #, forms appearing
outside of a QUOTE that expand into list or symbol forms that could be
interpreted as code, or strings that could be interpreted as
documentation strings. Users are even more likely to be confused
because the wording in CLtL compares the behavior of #, to the special
form EVAL-WHEN, which must appear in a for-evaluation position.
#, also presents a serious problem to program-analyzing programs
because evaluation is tied to the reader, rather than the interpreter
or compiler. In theory, this could be handled by altering the read table
to have #, construct a "magic cookie" instead of performing read-time
evaluation and having the code walker examine quoted structures, but I've
never seen this actually done in practice.
Proposal SHARP-COMMA-CONFUSION:REMOVE:
Remove the #, read macro from the language.
Rationale:
Removing #, is simpler than trying to redefine it. Removing it from
the standard, rather than redefining it to mean something else (see
issue LOAD-TIME-EVAL), would allow implementations to continue to
provide it as an extension. (Although CLtL does not appear to
explicitly address the question of whether implementations may extend
the reader syntax, some implementations already provide sharp-sign
read macros other than those described in CLtL, such as #P syntax for
pathnames.)
Current Practice:
#, is not used very frequently, but the functionality it provides is
important in some advanced applications; one such application that has
been cited is CLOS. Maintainers of such applications have generally
expressed a willingness to give up #, only if a suitable alternative
is offered (see issue LOAD-TIME-EVAL).
PSL/PCLS has never bothered to implement #, correctly (it's treated
just like #.), and nobody has ever complained about it being broken.
Cost to implementors:
None.
Cost to users:
Because #, is used so infrequently, most users would probably not even
notice its absence.
Issue LOAD-TIME-EVAL proposes to add a special form that would provide
a somewhat cleaner mechanism for load-time evaluation.
It is also possible to use a global variable to get the similar effect as
#,, although this is sometimes awkward and carries a space and
performance penalty in many implementations.
Benefits:
The language specification is simplified by removing a peculiar
feature of the language that is accessible only through the reader.
Removing #, may also allow simpler strategies for implementing
compiled file loaders to be used.
Discussion:
If this proposal is rejected, the definition of #, in the standard will
still need to be clarified to indicate that #, can only appear in
quoted structure. It should probably also include some mention of the
problems that #, can cause code walkers.
Kent Pitman says:
I approve of the ideas being discussed, but ONLY contingent on
LOAD-TIME-VALUE being introduced.
I am optimistic that LOAD-TIME-EVAL will pass, and so I don't think this
will keep #, from passing, but:
- I want people who vote for this to realize the importance of voting
for LOAD-TIME-EVAL.
- On the off chance LOAD-TIME-EVAL doesn't pass, I want people to have
been warned that the consequences were severe for some major
applications.
- I want the records to reflect the actual rationale people should and
hopefully will be using to make these decisions.
∂03-Jan-89 1429 X3J13-mailer issue LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:29:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00654; Tue, 3 Jan 89 15:28:33 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06041; Tue, 3 Jan 89 15:28:30 MST
Date: Tue, 3 Jan 89 15:28:30 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032228.AA06041@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue LOAD-TIME-EVAL
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
issue SHARP-COMMA-CONFUSION
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
21-Sep-88, Version 6 by Moon (stripped down)
17-Oct-88, Version 7 by Loosemore (change direction again)
30-Dec-88, Version 8 by Loosemore (tweaks)
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
performs normal semantic processing such as macro expansion but
arranges for the evaluation of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, (LOAD-TIME-VALUE <form>) is equivalent to (VALUES
(EVAL (QUOTE <form>))). Implementations which implicitly compile
(or partially compile) expressions passed to EVAL may evaluate the
<form> only once, at the time this compilation is performed. This is
intentionally similar to the freedom which implementations are given
for the time of expanding macros in interpreted code.
Note that, in interpreted code, there is no guarantee as to when
evaluation of <form> will take place, or the number of times the
evaluation will be performed. Since successive evaluations of the
same LOAD-TIME-VALUE expression may or may not result in an evaluation
which returns a "fresh" object, destructive side-effects to the
resulting object may or may not persist from one evaluation to the
next. It is safest to explicitly initialize the object returned by
LOAD-TIME-VALUE, if it is later modified destructively.
Implementations must guarantee that each reference to a
LOAD-TIME-VALUE expression results in at least one evaluation of its
nested <form>. For example,
(CONS #1=(LOAD-TIME-VALUE (COMPUTE-IT)) #1#)
must perform two calls to COMPUTE-IT; although there is only one
unique LOAD-TIME-VALUE expression, there are two distinct references
to it.
In the case of a LOAD-TIME-VALUE form appearing in a quoted expression
passed to EVAL, each call to EVAL must result in a new evaluation of
<form>. For example,
(DEFVAR X 0)
(DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
is guaranteed to increment X each time FOO is called, while
(DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
may cause X to be evaluated only once.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
The requirement that LOAD-TIME-VALUE expressions be evaluated once per
reference (rather than once per unique expression) prevents problems
that could result by performing destructive side-effects on a value
that is unexpectedly referenced in more than one place.
Current Practice:
This is an addition to the language and has not yet been implemented.
Cost to Implementors:
In compiled code, (LOAD-TIME-VALUE <form>) is similar to
'#,<form>. Most implementations can probably make use of the same
mechanism they use to handle #, to handle LOAD-TIME-VALUE. Note that
#, does not currently provide a mechanism for dealing with
non-read-only-ness.
Implementing LOAD-TIME-VALUE in the interpreter should be fairly
straightforward, since one simply needs to evaluate the <form> in the
null lexical environment. Implementations that use a preprocessing
code walk in the interpreter to perform macro expansion could process
LOAD-TIME-VALUE forms at that time.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Benefits:
Users are given a mechanism that to force evaluation to be delayed
until load time that does not rely on a feature of the reader.
Discussion:
Earlier versions (up to version 7) of this proposal stated that
all semantic processing of the LOAD-TIME-VALUE form should be postponed
until load time.
The semantics of LOAD-TIME-VALUE would be simplified considerably if
the READ-ONLY-P argument were removed and destructive operations on
the result of evaluating <form> prohibited. However, some people feel
that the ability to destructively modify the value is an essential
feature to include.
"Collapsing" of multiple references to the same LOAD-TIME-VALUE
expression could be allowed for read-only situations, but it seems
like it would be more confusing to make it legal in some situations
and not in others.
A number of other alternatives have been considered on this issue,
including:
- A proposal for a new special form that would force evaluation of
the <form> to happen only once. This was rejected because of
implementation difficulties.
- A proposal to add a function making the "magic cookie" used by #,
available to user code. The current proposal does not prevent such
a function from being added, but this approach appeared to have
less support than making the hook available as a new special form.
- A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).
- A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).
Kent Pitman says:
Although I'm willing to take multiple evaluation in the interpreter
as a compromise position, I would like it mentioned in the discussion
that this was only an expedient to getting this issue accepted at all,
and that I'm not really happy about it. I have said that I think a
number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
this -- for example) are due to the presence of interpreters which do
not do a semantic-prepass at a known time. If I had my way, we would
require a semantic pre-pass and we would then be able to forbid
multiple evaluations even in the interpreter.
∂05-Jan-89 1342 X3J13-mailer ISO discussion and X3J13 Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jan 89 13:42:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA05813g; Thu, 5 Jan 89 13:38:32 PST
Received: by challenger id AA12199g; Thu, 5 Jan 89 13:34:30 PST
Date: Thu, 5 Jan 89 13:34:30 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901052134.AA12199@challenger>
To: x3j13@sail.stanford.edu
Subject: ISO discussion and X3J13 Agenda DRAFT
Monday, January 16
8:00am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports at the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Character Subcommittee Report, Thom Linden (2 hours)
7 Coffee Break 10:30
8 Character continuation
9 Chapter 3 CLOS, Gregor Kiczales (1 hour)
10 LUNCH 12:00 Voyage Room Restaurant
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
13 Recess 3:00
14 Call to Order, 8:00pm
15 Other Subcommittee Reports
16 Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Cleanup continuation
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
* Monday 8:00 - ISO discussion
Not part of X3J13 Committee Meeting
∂06-Jan-89 1504 X3J13-mailer Ballots, please
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:04:38 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 00:23:39 PST
Date: 6 Jan 89 00:23 PST
From: masinter.pa@Xerox.COM
Subject: Ballots, please
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <890106-002339-193@Xerox>
We've gotten very few ballots back. Please let us know soon if you plan to
vote even if you can't get your ballot in right away; we'll need some time
to respond to some of the comments and prepare new versions for the
meeting!
Thanks,
Larry
∂06-Jan-89 2253 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:52:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 22:51:48 PST
Date: 6 Jan 89 22:51 PST
From: masinter.pa@Xerox.COM
To: X3J13@Sail.Stanford.Edu
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890106-225148-2007@Xerox>
This issue will be voted separately at the X3J13 meeting.
I (unfortunately) caused some controversy by changing the
sense of the proposal at the last minute. I'm sorry, as I do
not feel stringly about this issue, although there are some
additional considerations. I've included some, but not all,
Additional Comments at the end.
This version has two proposals, both the ALLOW proposal
which I introduced with version 8 and a LEXICAL proposal.
The difference is about whether a type declaration affects only variable
references within its scope, or also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the declaration.
This really has nothing to do with the original goal of the proposal,
since exactly the same issue arises for a type declaration attached
to a binding of a special variable.
If you've yet to complete your ballot, please indicate which
version of the proposal you're votes apply to.
!
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Version 9, 2-Jan-89, Moon (2 proposals, to clarify discussion)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
In this proposal, a type declaration affects not only variable
references within its scope, but also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the
declaration. Such references can exist when the variable is SPECIAL
or when the declaration is not attached to the variable's binding, so
that the scope of the declaration does not include the entire scope
of the variable.
Proposal (DECLARE-TYPE-FREE:LEXICAL):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any reference to the
declared variable within the scope of the declaration, it is an error for
the value of the declared variable not to be of the declared type; and
during the execution of any SETQ of the declared variable within the scope
of the declaration, it is an error for the newly assigned value of the
declared variable not to be of the declared type; and at the moment the
scope of the declaration is entered, it is an error for the value of the
declared variable not to be of the declared type.
In this proposal, a type declaration affects only variable references within
its scope, and the meaning of "free" and "variable-binding-associated" type
declarations can be described identically.
This proposal is equivalent to saying that the meaning of a type declaration
is equivalent to changing each reference to <var> within the scope of the
declaration to (THE <type> <var>), changing each expression assigned to the
variable within the scope of the declaration to (THE <type> <new-value>),
and executing (THE <type> <var>) at the moment the scope of the declaration
is entered.
Examples:
;; this is an error under DECLARE-TYPE-FREE:ALLOW:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error under both proposals
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(print x)
(zap)
x)))
;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
;; the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error under both proposals, even though the
;; violation of the type constraint happens after the form
;; with the declaration is exited.
(let ((f (let ((x 3))
(declare (fixnum x))
#'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
more freedom for optimizing compilers. DECLARE-TYPE-FREE:LEXICAL is easier
to understand but allows a specialized representation only where the scope
of the variable is the same as the scope of the declaration or the compiler
can prove that there are no relevant other references to the variable.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
!
Additional Comments:
"The ALLOW proposal has the problems that:
- It isn't enforceable.
- In exactly those cases where it is enforceable, it's useful to enforce.
In those case where it is not enforceable (the odd middle-ground cases
in the Examples), it doesn't help you any to enforce the restriction, and
it might get in your way.
"
"Btw, both versions 8 and 9 have the non-preemptive problem that the
only examples they provide illustrate what happens in the screw
cases. This might lead some people to think that this whole issue
is kind of random. I think there should be a few examples of the
"normal use" (such as the un-filled-out examples in the problem
description). "
"Suppose I have
(defun frob (delta)
(flet ((more (x) (+ x delta)))
;; if you like, put (declare (inline more)) here
(typecase delta
(float (locally (declare (type float delta))
... (more rho ) ... )
((signed-byte 8)
(locally (declare (type (signed-byte 8) delta))
... (more zz) ... )
...)
Even without the INLINE, it is a common & legal transformation
to do inline substitution on small FLETted functions. Even though
the reference DELTA in the definition of MORE isn't within the
lexical scope of the local declaration, it *is* the same delta. While
its not impossible to maintain a separate contour in order to segregate
the type declarations, it seems like unnecessary work, and in fact, the
declaration is quite useful if MORE is inlined. This is only the case
with the ALLOW proposal and not the LEXICAL proposal."
∂07-Jan-89 0935 X3J13-mailer Issue CONSTANT-MODIFICATION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:35:06 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19620; Sat, 7 Jan 89 10:33:59 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08864; Sat, 7 Jan 89 10:33:56 MST
Date: Sat, 7 Jan 89 10:33:56 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071733.AA08864@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Issue CONSTANT-MODIFICATION, version 2
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-MODIFICATION
References: CLtL p. 78, 87
Issue CONSTANT-COLLAPSING
Category: CLARIFICATION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
Problem Description:
CLtL states that an implementation is permitted to "collapse"
constants appearing in code to be compiled if they are EQUAL. This
implicit sharing of compiled data structures may result in
unpredictable behavior if destructive operations are performed.
However, CLtL does not explicitly allow or disallow destructive
operations on constants.
Proposal CONSTANT-MODIFICATION:DISALLOW:
Clarify that it is an error to destructively modify objects which are
self-evaluating forms or which appear inside of a QUOTE special form.
Rationale:
Disallowing modification of constants consistently in all situations,
rather than just in compiled code, is proposed because in some
compiled-only situations it may be difficult to distinguish between
"compiled" and "interpreted" code.
Current Practice:
Many implementations "collapse" compiled constants.
Many implementations treat compiled constants as read-only. In
PSL/PCLS, for example, quoted data structures in compiled code are
copied into a part of memory that is not scanned by the garbage
collector. The TI Explorer's loader also copies constants into a
write-protected memory area.
Cost to implementors:
None.
Cost to users:
User programs which perform destructive operations on constants are
already nonportable.
Benefits:
Many novice programmers do not realize that modifying quoted data
structures is an error in many implementations. Including an explicit
statement in the standard that doing so is a bad idea will reduce
confusion.
Discussion:
The issue of whether implementations are permitted to copy constants
seen by EVAL or COMPILE is discussed separately as issue QUOTE-MAY-COPY.
∂07-Jan-89 0933 X3J13-mailer Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:33:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19606; Sat, 7 Jan 89 10:32:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08861; Sat, 7 Jan 89 10:32:22 MST
Date: Sat, 7 Jan 89 10:32:22 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071732.AA08861@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References: CLtL pages 66-70, 143
Category: CLARIFICATION
Edit history: V1, 07 Oct 1987 Sandra Loosemore
V2, 15 Oct 1987 Sandra Loosemore
V3, 15 Jan 1988 Sandra Loosemore
V4, 06 May 1988 Sandra Loosemore
V5, 20 May 1988 Sandra Loosemore
V6, 09 Jun 1988 Sandra Loosemore
V7, 16 Dec 1988 Sandra Loosemore
(Comments from Pitman, change DEFCONSTANT, etc.)
V8, 31 Dec 1988 Sandra Loosemore
(CLOS additions, etc.)
Problem Description:
Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled. However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly. In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are.
Inter-file compilation dependencies are distinct from, and not
addressed by, this issue.
Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled. A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form.
(2) The affected defining macros and their specific side effects are
as follows. In each case, it is identified what users must do to
ensure that their programs are conforming, and what compilers must do
in order to correctly process a conforming program.
DEFTYPE: Users must ensure that the body of a DEFTYPE form is
evaluable at compile time if the type is referenced in subsequent type
declarations. The compiler must ensure that the DEFTYPE'd type
specifier is recognized in subsequent type declarations. If the
expansion of a type specifier is not defined fully at compile time
(perhaps because it expands into an unknown type specifier or a
SATISFIES of a named function that isn't defined in the compile-time
environment), an implementation may ignore any references to this type
in declarations and/or signal a warning.
DEFMACRO, DEFINE-MODIFY-MACRO: The compiler must store macro
definitions at compile time, so that occurrences of the macro later on
in the file can be expanded correctly. Users must ensure that the
body of the macro is evaluable at compile time if it is referenced
within the file being compiled.
DEFUN: DEFUN is not required to perform any compile-time side effects.
In particular, DEFUN does not make the function definition available
at compile time. An implementation may choose to store information
about the function for the purposes of compile-time error-checking
(such as checking the number of arguments on calls), or to enable the
function to be expanded inline.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. However, it must
not evaluate the initial value form or SETQ the variable at compile
time.
DEFCONSTANT: The compiler must recognize that the symbol names a
constant. An implementation may choose to evaluate the value-form at
compile time, load time, or both. Therefore users must ensure that
the value-form is evaluable at compile time (regardless of whether or
not references to the constant appear in the file) and that it always
evaluates to the same value.
DEFSETF, DEFINE-SETF-METHOD: The compiler must make SETF methods
available so that it may be used to expand calls to SETF later on in
the file. Users must ensure that the body of DEFINE-SETF-METHOD and
the complex form of DEFSETF are evaluable at compile time if the
corresponding place is referred to in a subsequent SETF in the same
file. The compiler must make these SETF methods available to
compile-time calls to GET-SETF-METHOD when its environment argument is
a value received as the &ENVIRONMENT parameter of a macro.
DEFSTRUCT: The compiler must make the structure type name recognized
as a valid type name in subsequent declarations (as for DEFTYPE) and
make the structure slot accessors known to SETF. In addition, the
compiler must save enough information about the structure type so that
further DEFSTRUCT definitions can :INCLUDE a structure type defined
earlier in the file being compiled. The functions which DEFSTRUCT
generates are not defined in the compile time environment, although
the compiler may save enough information about the functions to code
subsequent calls inline. The #S reader syntax may or may not be
available at compile time.
DEFINE-CONDITION: The rules are essentially the same as those for
DEFSTRUCT; the compiler must make the condition type recognizable as a
valid type name, and it must be possible to reference the condition
type as the parent-type of another condition type in a subsequent
DEFINE-CONDITION in the file being compiled.
DEFCLASS: The compiler must make the class name be recognized as a
valid type name in subsequent declarations (as for DEFTYPE) and be
recognized as a valid class name for DEFMETHOD parameter
specializers and for use as the :METACLASS option of a subsequent
DEFCLASS. The compiler must make the class definition available to
be returned by FIND-CLASS when its environment argument is a value
received as the &ENVIRONMENT parameter of a macro.
DEFGENERIC and DEFMETHOD: These are not required to perform any
compile-time side effects. In particular, the methods are not
installed for invocation during compilation. An implementation may
choose to store information about the generic function for the
purposes of compile-time error-checking (such as checking the number
of arguments on calls, or noting that a definition for the function
name has been seen).
DEFINE-METHOD-COMBINATION: The compiler is not required to perform
any compile-time side-effects.
DEFPACKAGE: All of the actions normally performed by this macro at load
time must also be performed at compile time.
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE. For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:
(defmacro foo (x) `(car ,x))
(eval-when (eval compile load)
(print (foo '(a b c))))
A portable way to do the same thing would be to include the macro
definition inside the EVAL-WHEN:
(eval-when (eval compile load)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Rationale:
The proposal generally reflects standard programming practices. The
primary purpose of the proposal is to make an explicit statement that
CL supports the behavior that most programmers expect and many
implementations already provide.
The primary point of controversy on this issue has been the treatment
of the initial value form by DEFCONSTANT, where there is considerable
variance between implementations. The effect of the current wording is
to legitimize all of the variants.
Current Practice:
Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.
In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent
calls to COMPILE or COMPILE-FILE), but are not available to the
interpreter (even within the file being compiled).
By default, Kyoto Common Lisp evaluates *all* top level forms as they
are compiled, which is clearly in violation of the behavior specified
on p 69-70 of CLtL. There is a flag to disable the compile-time
evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do not make
their definitions available at compile-time either.
Cost to implementors:
The intent of the proposal is specifically not to require the compiler
to have special knowledge about each of these macros. In
implementations whose compilers do not treat these macros as special
forms, it should be fairly straightforward to use EVAL-WHENs in their
expansions to obtain the desired compile-time side effects.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
most of the behavior described in this proposal and will not find it
to be an incompatible change.
Benefits:
Adoption of the proposal will provide more definite guidelines on how
to write programs that will compile correctly under all CL
implementations.
Discussion:
Reaction to a preliminary version of this proposal on the common-lisp
mailing list was overwhelmingly positive. More than one person
responded with comments to the effect of "but doesn't CLtL already
*say* that somewhere?!?" Others have since expressed a more lukewarm
approval.
It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism. A separate proposal
seems more appropriate.
Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter. The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.
It should be noted that user-written code-analysis programs must
generally treat these defining macros as special forms and perform
similar "compile-time" actions in order to correctly process
conforming programs.
∂07-Jan-89 0946 X3J13-mailer **DRAFT** Issue COMPILER-VERBOSITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:46:19 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19738; Sat, 7 Jan 89 10:45:11 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08872; Sat, 7 Jan 89 10:45:08 MST
Date: Sat, 7 Jan 89 10:45:08 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071745.AA08872@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** Issue COMPILER-VERBOSITY, version 5
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILER-VERBOSITY
References: CLtL p. 438-329; 426
issue COMPILER-DIAGNOSTICS
Category: CHANGE/CLARIFICATION/ENHANCEMENT
Edit History: V1, 25 Oct 1988, Sandra Loosemore
V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
V5, 06 Jan 1989, Sandra Loosemore (update discussion)
Status: **DRAFT**
Problem Description:
Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE. In some situations, it would be useful to control
how much information is printed.
Proposal COMPILER-VERBOSITY:LIKE-LOAD:
Introduce a special variable, *COMPILE-VERBOSE*, with an implementation-
dependent initial value.
Add :VERBOSE and :PRINT keyword arguments to the function COMPILE-FILE,
analogous to those for the function LOAD.
The :VERBOSE argument (which defaults to the value of *COMPILE-VERBOSE*),
if true, permits COMPILE-FILE to print a message in the form of a comment
to *STANDARD-OUTPUT* indicating what file is being compiled and other
useful information.
The :PRINT argument (which defaults to NIL), if true, causes
information about top-level forms in the file being compiled to be
printed to *STANDARD-OUTPUT*. Exactly what is printed will vary from
implementation to implementation, but nevertheless some information
will be printed.
Rationale:
This proposal makes COMPILE-FILE behave like LOAD. There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).
Current Practice:
Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send progress messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".
On the TI Explorer, COMPILE-FILE displays the name of the function being
compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true. (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)
Cost to implementors:
This is an incompatible change for some implementations. While the
changes required should be conceptually simple, their implementation
may involve a significant amount of grunt work. At least two
implementations already provide some similar mechanism for suppressing
messages.
Cost to users:
Some (non-portable) user code may break in implementations where this is
an incompatible change.
Specifying that the :PRINT argument defaults to NIL is consistent with
LOAD, but in most implementations the default now is to print out a
lot of information about each function or top-level form. Some users
may find it irritating to have to type in :print t to get the same
amount of information they're used to seeing.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Proposal COMPILER-VERBOSITY:USE-CONDITIONS:
Add the new subtype of CONDITION, NOTICE, defined in
COMPILER-DIAGNOSTICS (V5). Add a new subtype of NOTICE, INFO.
Require compilers to "print" all messages covered by this proposal by
using the function NOTICE to signal a condition of type INFO instead
of directly writing the message. For the purposes of this proposal
"compilers" refers to both COMPILE and COMPILE-FILE.
Note that, since a compiler is never required to print any messages
covered by this proposal, no portable program may assume that any
conditions of type INFO will actually be signalled.
Rationale:
This allows informational compiler messages and compiler diagnostics
to be handled in a uniform manner with a simple, well defined way for
the user to gain any desired degree of control over these messages.
Current Practice:
No one currently controls compiler messages via the condition system.
Cost to implementors:
This is an incompatible change for all implementations. It should be
a conceptually simple change to make once an implementation supports
the condition system, however the actual implementation of the change
may involve a significant amount of grunt work.
All existing implementations can continue support their current
message control interfaces as long as the implementation of their
current interface is changed to comply with this proposal. This could
be done by:
1. Causing the old interface to either establish a condition
handler that accepts messages that shouldn't be printed and
does nothing with them. Note that it would not be legal to
make the handler print the messages that should be printed,
because a user handler must still be given a chance to look at
them.
2. Changing the old interface to conditionally write the message
as it used to, except that NOTICE is used to actually write the
message.
Cost to users:
Some user code may break in implementations which remove any
(non-portable) existing mechanisms to control compiler output.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Aesthetics:
Using a well defined, already existing, general mechanism is more
aesthetically pleasing than adding another ad-hoc flag or special
variable.
Discussion:
Rather than just treating :PRINT and :VERBOSE as boolean values, it
might be useful to have them convey more information. For example,
Pitman has suggested using keyword values like :BRIEF or :DETAILED to
allow varying amounts of information of each type to be printed.
Alternatively, it might be reasonable to follow Lucid's precedent to
allow the values of :PRINT and :VERBOSE to be streams to allow
messages to be directed somewhere other than *STANDARD-OUTPUT*.
Either of these suggestions could reasonably be made to apply to LOAD
as well, but the intent of LIKE-LOAD is to make COMPILE-FILE
behave like LOAD, not to change the specification of LOAD.
Loosemore questions whether using conditions for this purpose is
appropriate, because this issue deals with messages indicating the
normal progress of the compiler and conditions are supposed to be used
to signal exceptional (non-ordinary) situations.
Pierson believes that conditions provide a well defined, portable,
non-intrusive interface for user control of infrequent events. While
the use of conditions is not notably efficient, compiler informational
messages are sufficiently infrequent that this should not impose a
noticeable performance penalty.
Pierson would like to see LOAD, etc. changed to also use this
interface.
The two proposals are not mutually incompatible in that the LIKE-LOAD
keywords can be added to an implementation whether or not it is based
on USE-CONDITIONS.
∂07-Jan-89 0944 X3J13-mailer **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:44:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19722; Sat, 7 Jan 89 10:43:32 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08867; Sat, 7 Jan 89 10:43:26 MST
Date: Sat, 7 Jan 89 10:43:26 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071743.AA08867@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
Status: **DRAFT**
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Add the following to the language:
NOTICE [Type]
The notice type is a subtype of CONDITION, disjoint from
WARNING, SEVERE-CONDITION, and SIMPLE-CONDITION. All types of
notices should inherit from this type.
SIMPLE-NOTICE [Type]
Conditions signalled by NOTICE when given a format string as a
first argument are of this type. This is a subtype of NOTICE,
and in implementations supporting multiple inheritance, this
type will also be a subtype of SIMPLE-CONDITION. The init
keywords :FORMAT-STRING and :FORMAT-ARGUMENTS are supported to
initialize the slots, which can be accessed using
SIMPLE-CONDITION-FORMAT-STRING and SIMPLE-CONDITION-FORMAT-ARGUMENTS.
ALERT [Type]
This is a subtype of NOTICE.
NOTICE datum &rest arguments [Function]
This function signals a condition of type NOTICE. The arguments
are interpreted similarly to those for the function WARN; if the
"datum" is a string, then a condition of type SIMPLE-NOTICE will
be signalled.
While the NOTICE is being signalled, this function establishes
the MUFFLE-NOTICE restart for use by a handler to cause the NOTICE
function to return immediately without further action. If no
handlers for the notice condition are found, or if all such
handlers decline, then the condition will be reported to
*ERROR-OUTPUT*.
The value returned by NOTICE is NIL.
MUFFLE-NOTICE [Function]
This function transfers control to the restart named MUFFLE-NOTICE.
If no such restart exists, MUFFLE-NOTICE signals an error of type
CONTROL-ERROR.
(2) Clarify that ERROR, WARNING, and ALERT conditions may be signalled
within COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation that "is an error" would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) All other diagnostics issued by the compiler should be conditions
of type ALERT. In particular, this category includes all
diagnostics about matters of programming style. Although
conditions of type ALERT -may- be signalled in these
situations, no implementation is -required- to do so.
However, if an implementation does choose to signal a
condition, that condition will be of type ALERT and will be
signalled by a call to the function NOTICE.
Examples:
redefinition of function with different argument list
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) Require COMPILE-FILE to establish a condition handler. Add a
:HANDLER keyword argument to COMPILE-FILE, which is a user condition
handler function which is to be used during compilation. If the user
handler is not supplied or declines to handle a condition, then the
compiler's default handler will be invoked. Require the compiler
to handle the ABORT restart by aborting the smallest feasible part
of the compilation.
(4) Specify that COMPILE-FILE returns three values. The first value is the
truename of the output file, or NIL if the file could not be created.
The second value is non-NIL if errors were signalled during compilation
that were not handled by the user condition handler (indicating that
the output file is almost certainly unusable). The third value is
non-NIL if warnings were signalled during compilation that were not
handled by the user condition handler (indicating that the output
file may or may not be usable).
(5) Clarify that COMPILE does not establish a condition handler. Instead,
it uses whatever condition handler has been established in the environment
from which it is called.
Rationale:
Point by point,
(1) The new condition types NOTICE and ALERT are structured to allow
this part of the condition hierarchy to be further extended. In
particular, the issue COMPILER-VERBOSITY proposes an additional
subtype of NOTICE named INFO. The description of the NOTICE
function parallels the behavior of WARN.
(2) Conditions such as syntax errors which are errors in the interpreter
remain errors in the compiler. The division of other conditions
into WARNINGs and ALERTs allows potentially serious problems to be
distinguished from mere kibbitzing on the part of the compiler.
(3) It is reasonable for the default handling of compiler errors not to
cause the debugger to be invoked. However, any condition handler
established by COMPILE-FILE would override handlers established by the
user in the surrounding environment.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire file compilation if it is not feasible to abort a
smaller part.
(4) This allows users to determine whether or not COMPILE-FILE is able to
actually compile the file successfully. Returning several values is
is more useful than a single success/failure value because there are
several degrees of failure.
(5) This is to reflect the use of COMPILE-FILE as being more "batch"-oriented
and COMPILE as being more interactive. There is less motivation to have
COMPILE try to recover from errors without user interaction.
Test Case/Example:
An example to illustrate how COMPILE-FILE should set up its condition
handlers is:
(defvar *output-file-truename* nil)
(defvar *errors-detected* nil)
(defvar *warnings-detected* nil)
;;; Call INTERNAL-COMPILE-FILE to do the real work. Note, that function
;;; may set up additional ABORT restarts.
(defun compile-file (input-file &key output-file handler)
(let ((*output-file-truename* nil)
(*errors-detected* nil)
(*warnings-detected* nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((condition #'compile-file-default-handler))
(if handler
(handler-bind ((condition handler))
(internal-compile-file input-file output-file))
(internal-compile-file input-file output-file))))
(values *output-file-truename*
*errors-detected*
*warnings-detected*)))
;;; The default condition handler keeps track of errors and warnings,
;;; and may also perform other implementation-specific actions.
(defun compile-file-default-handler (condition)
(typecase condition
(error
(setq *errors-detected* t)
...)
(warning
(setq *warnings-detected* t)
...)
(alert
...)
))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the new functions and types may cause conflicts with user code
already using those names.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
The biggest complaint directed against this proposal is that it is much
too complicated.
Kent Pitman suggested an alternate approach:
Specify that COMPILE and COMPILE-FILE return a second value, SUCCESS-P.
Define that compilers are permitted to handle conditions of type ERROR,
turning them into warnings and continuing to compile as appropriate,
but that if an error was turned into a warning so that COMPILE or
COMPILE-FILE could complete its operation, NIL must be returned as the
second value. The normal successful return value would be T.
Loosemore responded:
I'm concerned that besides possibly not being enough to satisfy the
needs of people who are trying to write portable system-building
utilities, this won't do anything to solve the stated problem, namely
how to suppress useless style warning messages.
Some other possible ways of simplifying the proposal include:
- Remove the :HANDLER argument and the requirement that COMPILE-FILE
establish a condition handler and the :HANDLER argument. Continue
to require it to establish an ABORT restart so that user error
handlers established outside the call to COMPILE-FILE can cause
compilation to proceed.
- Put all of the things relating to the NOTICE condition into a
separate proposal, since it's intended to be a more general tool.
- Forget about the NOTICE condition and use STYLE-WARNING (a subtype
of WARNING) instead of ALERT.
Some might wonder why NOTICE is needed instead of just making ALERT a
subtype of WARNING. This is for compatability with other proposed
conditions, notably INFO. While it might be reasonable to say that a
style "warning" is a legitimate WARNING error message, it is really
hard to justify WARNING status for a message like
;;; Starting to compile file foo.
We also contemplated using the name MESSAGE instead of NOTICE, but it
was felt that NOTICE would be less likely to cause conflicts with
existing user code. Another suggestion has been to call the type
NOTIFICATION and the signalling function NOTIFY; some people think
that the name NOTICE might also be too generic.
Pitman says that he would like to require COMPILE-FILE's default
condition handler never to invoke the debugger. I have left that out
of this proposal because it seems like an unnecessary restriction; if
users want to ensure that kind of behavior it is possible to do so by
supplying a user handler. (Of course, the converse is also true.)
Some of the things specified in section 2c as being ALERTS were
described in CLtL as being WARNINGs. There seems to be general
agreement that these things (particularly complaints about unused
variables) are not as serious as other problems described as warnings.
We might consider introducing a COMPILER-CONDITION that can be used in
mixins with the other condition types, so that error handlers can
distinguish between errors signalled by the compiler itself and errors
signalled during macroexpansion or EVAL-WHEN processing. This would
have to wait until the condition system is fully CLOSified.
Possibly NOTICE should write to *STANDARD-OUTPUT*, or even *TRACE-OUTPUT*,
rather than *ERROR-OUTPUT*.
David Gray writes:
This proposal looks good, but there are a couple of little things worrying
me. One is the potentially confusing shift in terminology by which
compiler messages that are conventionally referred to as "warnings", are
now called "alerts", programmer errors are reported as "warnings", and
only what is conventionally called "fatal errors" are reported as "errors".
I don't know what can be done about this, though, since we do want some
down-grading in severity so that the compiler issues a message and continues
for a situation that will signal an error if the compiled code is run.
Probably we just need to be careful how this is documented in order to
minimize confusion.
Another thing is that this doesn't provide a way to suppress style
"warnings" [ALERT conditions] on a local basis. For example, Lisp
Machines have a macro INHIBIT-STYLE-WARNINGS that can be wrapped around a
single form to keep the compiler quiet. I wonder if we might want a
COMPILER-HANDLER-BIND macro for specifying handlers at compile time? This
would be analogous to COMPILER-LET, but it could avoid the problems that
have doomed COMPILER-LET by specifying that the evaluator is free to
ignore it.
∂07-Jan-89 1048 X3J13-mailer issues relating to compiled constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:47:59 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20410; Sat, 7 Jan 89 11:46:53 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08916; Sat, 7 Jan 89 11:46:51 MST
Date: Sat, 7 Jan 89 11:46:51 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071846.AA08916@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issues relating to compiled constants
Reply-To: cl-compiler@sail.stanford.edu
Coming up shortly will be drafts of four issues relating to the
semantics of quoted and self-evaluating constants:
CONSTANT-COMPILABLE-TYPES
What kinds of objects are dumpable by COMPILE-FILE? What
attributes of those objects must the compiler preserve?
CONSTANT-CIRCULAR-COMPILATION
Must the compiler correctly handle circular objects? Must it
preserve sharing of substructures?
CONSTANT-COLLAPSING
Should the compiler be allowed to use a more general equivalence
relationship than EQUAL in coalescing constants?
QUOTE-MAY-COPY
May COMPILE and EVAL, as well as COMPILE-FILE, substitute
equivalent copies of quoted objects?
All of these issues are very closely related, and the outcome of one
issue may affect each of the others. I apologize for not having a
single document that presents a unified view of the semantics of
constants, but since each of these subissues have been controversial
in their own right (some have competing proposals) it seemed better
not to try to lump them all together. I am hoping that distributing
these writeups to a larger audience will result in some feedback that
will allow us to narrow down the range of possibilities.
-Sandra
∂07-Jan-89 1049 X3J13-mailer **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:49:17 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20434; Sat, 7 Jan 89 11:48:08 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08922; Sat, 7 Jan 89 11:48:05 MST
Date: Sat, 7 Jan 89 11:48:05 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071848.AA08922@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-CIRCULAR-COMPILATION
References: Issue CONSTANT-COLLAPSING
Issue QUOTE-MAY-COPY
Category: CLARIFICATION, ADDITION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 14 Nov 1988, Cris Perdue
V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
Status: **DRAFT**
Problem Description:
CLtL does not specify whether constants containing circular or
recursive references may be compiled. It is also not clear whether
the compiler must preserve sharing of EQ substructures; that is, whether
subobjects that are EQ in the source code must remain EQ after being
compiled.
The proposals below apply to COMPILE-FILE, since it must inherently
copy structures. If issue QUOTE-MAY-COPY is resolved in favor of
allowing COMPILE and possibly EVAL to copy structures, the same
constraints would also apply in those situations. [We would also have
to decide upon the scope over which sharing must be detected in such
situations; the minimal scope would be over a single call to EVAL or
COMPILE.]
In the proposals that follow, "preserving EQness" means that
subobjects that are EQ in the source code must remain EQ after being
compiled; that is, things don't get "less EQ" after compilation.
(Note that coalescing of constants implies that things may get "more
EQ".)
Proposal CONSTANT-CIRCULAR-COMPILATION:NO
State that it is an error for an object containing a circular reference to
appear as a constant to be compiled. State that the compiler is not
required to preserve EQness of substructures.
Rationale:
This proposal would not require any existing implementation to change.
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
State that it is an error for an object containing a circular
reference to appear as a constant to be compiled. State that the
compiler is required to preserve EQness of substructures within a file
compiled with COMPILE-FILE.
Rationale:
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Some programs (such as PCL) have come to depend on COMPILE-FILE
preserving the EQness of uninterned symbols, and it is cleaner
to require sharing to be preserved in general instead of making
symbols be a special case. Requiring sharing to be preserved still
allows loaders to build constants bottom-up.
Proposal: CONSTANT-CIRCULAR-COMPILATION:FLAG
Add to the definition of Common Lisp a special variable:
*DUMP-CIRCLE* [Special variable]
State that if the (compile-time) value of *DUMP-CIRCLE* is NIL, it is
an error for an object containing a circular reference to appear as a
constant to be compiled. State that the compiler is required to
preserve EQness of substructures within a file compiled with
COMPILE-FILE when *DUMP-CIRCLE* is non-NIL. (Note that this differs
from *PRINT-CIRCLE*, which is not required to detect sharing.)
The initial value of *DUMP-CIRCLE* is implementation-dependent.
Rationale:
As with *PRINT-CIRCLE* for printing, writing representations of
objects to a stream is much faster if the implementation does not
attempt to support circular, self-recursive, mutually-referential,
etc. substructure.
Current Practice:
A-Lisp preserves EQness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant. PSL and Utah Common Lisp both
get stuck in an infinite loop if an attempt is made to compile a
reentrant structure. The TI Explorer compiler is able to reproduce
recursive lists and arrays, but currently hangs in a loop on a
circular list. Lucid and Symbolics can handle circular constants
correctly. Franz uses a flag to control whether or not to attempt to
detect circular constants.
Cost to implementors:
We know of no implementation that would have to change under proposal
NO. For proposal FLAG, some implementations would require sweeping
changes; in some cases a completely different dumper/loader strategy
would have to be implemented. The cost of proposal
PRESERVE-SHARING-ONLY would fall somewhere in between.
Cost to users:
The situation now is that programs which depend upon circularity or
sharing of substructure being preserved by the compiler are already
nonportable. Proposal NO simply formalizes the status quo. Proposal
FLAG would offer users functionality that is currently not portable.
Benefits:
An area of ambiguity in the language is removed.
Discussion:
JonL has argued against proposal CONSTANT-CIRCULAR-COMPILATION:NO, saying
I don't see any performance justification; and even if there were, I'd
look at it with a very jaundiced eye, favoring interpreter/compiler
consistency over nickle-and-dime issues of compiler speed.
Loosemore thinks PRESERVE-SHARING-ONLY is the "right" solution, but
would also support CONSTANT-CIRCULAR-COMPILATION:NO because it is the
most consistent with current practice -- no implementations would be
required to change and no currently portable programs would be
invalidated. While one could make an argument for this proposal on
the basis of improving compiler speed, the compatibility issue is seen
as far more important.
There was also quite a bit of discussion about how this proposal
relates to the requirement in CLtL (p. 69) about preserving the
EQLness of references to symbolic constants.
∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue CONSTANT-COLLAPSING
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:50:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20460; Sat, 7 Jan 89 11:48:54 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08925; Sat, 7 Jan 89 11:48:52 MST
Date: Sat, 7 Jan 89 11:48:52 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071848.AA08925@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-COLLAPSING
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-COLLAPSING
References: CLtL p. 78, 87
Issue CONSTANT-MODIFICATION
Issue CONSTANT-COMPILABLE-TYPES
Issue EQUAL-STRUCTURE
Issue QUOTE-MAY-COPY
Category: CHANGE
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
V3, 03 Jan 1989, Sandra Loosemore
V4, 06 Jan 1989, Sandra Loosemore
Status: **DRAFT**
Problem Description:
CLtL states that an implementation is permitted to "collapse" or
coalesce constants appearing in code to be compiled if they are EQUAL.
The definition of EQUAL does not permit coalescing of more general
isomorphic data structures (such as arrays and structures), which is
often desirable.
Issue QUOTE-MAY-COPY deals with whether coalescing may be performed
only by COMPILE-FILE, or by COMPILE and EVAL as well. CLtL says: "An
object is considered to be a constant in code to be compiled if it is
a self-evaluating form or contained in a QUOTE form".
Proposal CONSTANT-COLLAPSING:GENERALIZE:
State the an implementation is permitted to "collapse" constants
appearing in code to be compiled if they are equivalent under the
relationship specified in issue CONSTANT-COMPILABLE-TYPES.
Rationale:
There is little reason why implementations should not be allowed to
perform more general collapsing of structures, since the arguments
against doing so also apply to collapsing of EQUAL structures, which
is already permitted.
Current Practice:
Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example). Lucid Common Lisp also uses a more
general coalescing predicate than EQUAL.
Cost to implementors:
None. This extends the range of permitted behavior for
implementations but does not require any implementation to change.
Cost to users:
It is hard to imagine a program that would break under this proposal.
Benefits:
Collapsing of isomorphic arrays and structures may lead to significant
memory savings in some applications.
Discussion:
This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
Some people believe that if the definition of EQUAL weren't "broken",
there wouldn't be any need for this proposal.
There is no inherent reason why the "coalescing predicate" must be the
same as the relationship used by the compiler/loader to construct
equivalent copies of objects of constants, but making the same rules
be applied in both situations simplifies the language somewhat.
∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue QUOTE-MAY-COPY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:50:37 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20465; Sat, 7 Jan 89 11:49:27 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08928; Sat, 7 Jan 89 11:49:24 MST
Date: Sat, 7 Jan 89 11:49:24 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071849.AA08928@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue QUOTE-MAY-COPY
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: QUOTE-MAY-COPY
References: CLtL p. 55, 78, 86, 143
Issue CONSTANT-COLLAPSING
Issue CONSTANT-COMPILABLE-TYPES
Issue CONSTANT-MODIFICATION
Category: CHANGE/CLARIFICATION
Edit History: V1, 5 Dec 1988, Sandra Loosemore
V2, 10 Dec 1988, Sandra Loosemore
(comments from Dalton, JonL)
V3, 3 Jan 1989, Sandra Loosemore
(comments from Pitman et al)
V4, 7 Jan 1989, Sandra Loosemore
(update discussion)
Status: **DRAFT**
Problem Description:
May QUOTE return a copy of its argument? In particular, is it
permissible for COMPILE to copy quoted constants to read-only
memory, or to coalesce equivalent constants?
In spite of the name of this issue, the question is not whether QUOTE
itself may copy objects, but whether the semantics of "quoted objects"
is such that it is permissible for the compiler or interpreter to
substitute a copy of the original object.
Background:
CLtL p. 86 states that (QUOTE <x>) simply returns <x>. On
p. 55 it is mentioned that the only self-evaluating forms that may
be copied are numbers or characters. It is also stated that an
implementation is permitted to collapse (or coalesce) EQUAL constants
appearing in code to be compiled.
Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded. In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced. Since it is
permissible for an implementation to implicitly compile even
"interpreted" code (p. 143), the semantics of constants seen by EVAL
may also be affected if the in-memory compiler (as well as the file
compiler) is allowed to copy or coalesce constants.
The arguments for allowing constants to be copied can be summarized
briefly as follows. Copying constants to read-only memory can result
in less work for garbage collectors. If there is hardware support for
write-protection of memory, this may also be used to cause an error to
be signalled if an attempt is made to modify the constant. Coalescing
equivalent constants can lead to significant memory savings in some
applications (although this savings is likely to be less for individual
functions compiled with COMPILE than entire programs compiled with
COMPILE-FILE).
The primary argument against allowing constants to be copied or
coalesced is that doing so causes information to be lost, and in the
case of COMPILE and EVAL, there is no inherent reason why this
information must be discarded. Some people also feel that allowing
QUOTE not to return a value that is EQ (or even EQL) to its argument
would be a substantial, incompatible change from its "traditional"
semantics.
Proposal QUOTE-MAY-COPY:ALWAYS:
Change the description of QUOTE to indicate that (QUOTE <x>) returns
an object equivalent to <x>, which may or may not be EQ to <x>.
Likewise, a self-evaluating form may also return an equivalent copy
of the object.
The equivalence relationship is defined in the writeup for issue
CONSTANT-COMPILABLE-TYPES, and only those objects for which this
relationship is defined may appear as quoted or self-evaluating
constants. The restrictions placed on compiled constants in
issue CONSTANT-CIRCULAR-COMPILATION apply to constants in code
processed by EVAL and COMPILE, as well as COMPILE-FILE. EVAL and
COMPILE may also coalesce constants, as described in issue
CONSTANT-COLLAPSING.
If an implementation chooses to copy constants, the copying may only
happen once each time the form containing the constant is processed
with COMPILE or EVAL (see examples below).
Rationale:
This proposal would make the treatment of constants uniform across
COMPILE-FILE, COMPILE, and EVAL.
Proposal QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE:
Clarify that self-evaluating forms and quoted constants always
evaluate to objects that are EQL to the original, except in the case
of code compiled with COMPILE-FILE (where an equivalent but possibly
non-EQL object is returned). The restrictions on compiling constants
in issues CONSTANT-COMPILABLE-TYPES and CONSTANT-CIRCULAR-COMPILATION
apply only to COMPILE-FILE. Only COMPILE-FILE may coalesce constants
(issue CONSTANT-COLLAPSING).
Rationale:
This proposal is the most consistent with the semantics described in
CLtL. It would make the treatment of constants uniform across
COMPILE and EVAL.
Proposal QUOTE-MAY-COPY:NOT-EVAL:
Clarify that quoted or self-evaluating constants appearing in code
processed by EVAL must return an object that is EQL to the original.
In functions that have been compiled with COMPILE or code that has
been compiled with COMPILE-FILE, an equivalent (but possibly
non-EQL) copy of the object may be returned instead.
The equivalence relationship is defined in the writeup for issue
CONSTANT-COMPILABLE-TYPES, and only those objects for which this
relationship is defined may appear as quoted or self-evaluating
constants in code to be compiled. The restrictions on constants
described in issue CONSTANT-CIRCULAR-COMPILATION apply to both
COMPILE-FILE and COMPILE, and both may coalesce constants as
described in issue CONSTANT-COLLAPSING. There are no restrictions
on what kinds of objects may appear in code processed with EVAL, and
EVAL may not coalesce equivalent constants.
If an implementation chooses to copy constants, the copying may only
happen once each time the form containing the constant is processed
with COMPILE (see examples below).
Rationale:
This proposal is the most consistent with current practice.
Test Cases/Examples:
#1: (Behavior of COMPILE)
Suppose the function FOO is defined:
(defun foo () '(a b c))
Under all three proposals, multiple calls to FOO must always return
EQ values, regardless of whether FOO is interpreted or compiled:
(eq (foo) (foo)) ==> true
Proposals ALWAYS and NOT-EVAL allow FOO to return a "different" EQ
value after it is compiled:
(setq old-foo (foo))
(compile 'foo)
(eq old-foo (foo)) ==> ??? under ALWAYS or NOT-EVAL
true under NOT-EVAL-OR-COMPILE
#2: (Behavior of EVAL)
(let ((x '(a b c)))
(eq x
(eval (list 'quote x))))
Under proposal ALWAYS, this may or may not return true. Proposals
NOT-EVAL-OR-COMPILE and NOT-EVAL guarantee this to return true.
(let ((x '(a b c)))
(eq (eval (list 'quote x))
(eval (list 'quote x))))
Under proposal ALWAYS, this may or may not return true (each call to
EVAL may construct its own copy of X). Proposals NOT-EVAL-OR-COMPILE
and NOT-EVAL guarantee this to return true.
Current Practice:
Implementations in which COMPILE copies constants include PSL/PCLS and
Kyoto Common Lisp. In Lucid Common Lisp, constants are not normally
copied by COMPILE, but since COMPILE does coalesce constants, it may
cause QUOTE to return an object which is not EQL to its original
argument.
There do not appear to be any implementations in which constants are
copied by EVAL.
Cost to implementors:
Proposal QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE would cause significant
problems for some implementations. For example, PSL/PCLS would
require major changes to its memory management scheme and garbage
collector as well as the compiler to bring it into compliance.
Proposal QUOTE-MAY-COPY:NOT-EVAL could potentially cause problems for
compiled-only implementations in which the in-memory compiler normally
coalesces or makes copies of constants. There does not appear to be
any existing implementation that would be affected.
Note that neither QUOTE-MAY-COPY:ALWAYS or QUOTE-MAY-COPY:NOT-EVAL
-require- constants to be copied or coalesced; neither proposal would
require changes to those implementations that currently don't touch
constants.
Cost to users:
Proposals QUOTE-MAY-COPY:ALWAYS and QUOTE-MAY-COPY:NOT-EVAL would have
the result of explicitly stating that programs which depend on COMPILE
preserving EQLness of constants are nonportable. (This is the de
facto situation now.) Such programs could continue to work in those
implementations in which COMPILE does not copy or coalesce constants.
The impact of allowing constants to be copied in interpreted code
(proposal QUOTE-MAY-COPY:ALWAYS) is unknown. It could be argued that
any code that depends on constants not being copied or coalesced is
broken, since it would not work when compiled in some implementations.
Benefits:
The semantics of QUOTE are clarified.
Discussion:
There has been some confusion about the names of the proposals. It's
been suggested that all of the proposals should be rewritten and
renamed to make it more clear that the issue is whether COMPILE or
EVAL may make copies of constants. Note that proposal
QUOTE-MAY-COPY:ALWAYS implies that copying is always *permitted*, but
is not required under any circumstances.
This issue has caused a very lengthy debate on the cl-compiler mailing
list, with no consensus arising yet. Following are comments
summarizing various people's positions.
Kent Pitman originally supported NOT-EVAL-OR-COMPILE, but now says:
I asked Moon about his feelings on this. He thinks pretty strongly that
the ALWAYS option is the only practical one to pursue. Partly, he says,
because it's maximally compatible with current practice and partly
because it avoids making COMPILE-FILE seem different.
In principle, I favor option ALWAYS, permitting copying of quoted
structure to a constants area in any of EVAL, COMPILE, or COMPILE-FILE
situations, as appropriate to the implementation.
It should not be concluded from this that I favor restrictions on the
kinds of data which may be quoted, however. The wording of option ALWAYS
should be ammended to say that such copying is permitted only when the
system can reliably deduce whether such copying is `appropriate,'
and avoid it in cases where it is not. The purpose of such wording would
be to avoid placing restrictions on what kinds of structures a user can
or cannot quote.
So, for example, if an implementor cannot in some context figure out how
to detect circularities in quoted structure in order to either decline
copying or correctly copy the circular form, then the implementation is
not permitted to attempt copying in such contexts.
Note however that because of special considerations forced by the external
representation of data in compiled files, I go along with (and encourage)
the establishment of a known subset of types which can be quoted (or used
as self-evaluating constants) in code to be reliably processed by the file
compiler. Coincidentally, such restrictions might make it easier for an
implementation to know whether copying was going to succeed in the case of
loading compiled code from a file, but technically these restrictions are
not motivated by any consideration of what kinds of structures might or
might not be possible to QUOTE.
My inclination is also to believe that copying should not be done
repeatedly, and we should find a way to express this. That is, repeated
execution of code in the same execution environment should return an EQL
result (or some such). This is important to guaranteeing efficiency. Even
in copying implementations, it is not necessary that such constants be
allocated in a read-only area or some such to achieve this effect. For
example, quoted structure could be placed in a special array and QUOTE
could be implemented using AREF. What is important is that any of these
permissions we give for copying not be taken for a license that QUOTE
should be implemented by COPY-TREE or some other operation which cannot
be done in constant time.
Dan Pierson says:
I also support QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE. In the absence of
overwhelming opposing reasons, we should not diminish traditional Lisp
functionality. While NOT-EVAL may be more in line with current
practice of a couple of implementations, the argument that these
implementations are already broken is at least as strong as the
argument that we shouldn't break them by pointing out that they don't
conform to the language standard.
However, my position on this is not unalterable.
Sandra Loosemore says:
I oppose NOT-EVAL-OR-COMPILE on the grounds that it differs from current
practice and would involve a substantial conversion cost for some
implementations; either of the other two alternatives would be acceptable
instead since they involve essentially no conversion cost for either
implementors or users. I am not convinced that the modifications to
proposal ALWAYS suggested by Pitman wouldn't cause just as much work
for some implementations as forbidding copying entirely. If the
modifications applied only to the behavior of EVAL and not COMPILE, that
would be OK.
Many people have referred to "tradition" in their arguments on this
issue. Different implementations have different traditions, and what
seems "broken" to one person may seem perfectly natural to another
person who comes from a different background.
JonL White says:
I favor giving as much leeway as possible to
the implementors for making memory-management optimizations. While one
implementor may choose not to do any such work, and another may even go
out of his way to assure EQLness over an unlikely set of circumstances,
this should not constrain the third from doing the "classic" thing. In
short, I don't see the value of adding constraints that
(1) invalidate much existing practice, and
(2) appear to be purely of theortical value.
Making "compiled code" (read: compile-file) work as closely as possible to
interpreted code is _not_ "purely of theortical value."
QUOTE-MAY-COPY:ALWAYS is the only proposal that both recognizes the
prevalent practice and pays (at least) lip service to the question of
compiled/interpreted consistency.
Cris Perdue says:
I am opposed to all of the proposals offered in their current
form.
CLtL takes a simple, useful approach to this problem. The idea
that QUOTE cannot reasonably operate as defined in CLtL is incorrect,
though it appears desirable to explain somewhere the "copying"
effects that compile-file may have on constants.
To say that QUOTE copies in existing implementations is to
imply that a lot of copying might happen that never actually
happens. COMPILE-FILE followed by LOAD effectively copies,
and in KCL, COMPILE effectively makes a copy, but not QUOTE.
I object strongly to suggestions that QUOTE copies in existing
practice, at least existing practice as I know it. Among other things,
this skews the entire discussion. It also limits the set of datatypes
that can be QUOTEd, because the equivalence defined in
CONSTANT-COMPILABLE-TYPES does not support all datatypes.
It is possible for QUOTE or a garbage collector to copy
constants into readonly storage, but I think that rationale is
different from supporting existing practice. With that rationale
I might support something like QUOTE-MAY-COPY:ALWAYS, but I think
it would be questionable whether the equivalence defined in
CONSTANT-COMPILABLE-TYPES is sufficient. A version
that applies to all objects might be advisable as the equivalence
maintained by QUOTE.
∂07-Jan-89 1048 X3J13-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:48:44 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20422; Sat, 7 Jan 89 11:47:34 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08919; Sat, 7 Jan 89 11:47:31 MST
Date: Sat, 7 Jan 89 11:47:31 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071847.AA08919@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-COMPILABLE-TYPES
References: CLtL pp. 56, 77-80, 324
Issue CONSTANT-MODIFICATION
Issue CONSTANT-CIRCULAR-COMPILATION
Issue CONSTANT-ARRAY-ATTRIBUTES
Issue QUOTE-MAY-COPY
Issue LOAD-OBJECTS
Category: CLARIFICATION, ADDITION
Edit history: 11/07/88, V1 by Cris Perdue
11/14/88, V2 by Cris Perdue
11/22/88, V3 by Cris Perdue
12/20/88, V4 by Cris Perdue
01/06/89, V5 by Sandra Loosemore (minor editorial
clarifications, expand discussion)
Status: **DRAFT**
Problem description:
CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there can or must be between the
constant passed to the compiler and the one that is established by
compiling and then loading its file. Relevant remarks in CLtL
concerning file compilation and the definition of QUOTE suggest that
the compiler handles constants in ways that are not actually possible.
Introduction to the proposal:
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear. Unless stated otherwise, in this proposal where the term
"constant" is used, it means a quoted or self-evaluating constant, not
a named (defconstant) constant.
The key is a definition of a form of equivalence between Lisp objects,
"similarity as constants". Code passed through the file compiler must
behave as though quoted constants in it are equivalent to quoted
constants in the corresponding interpreted "source" code. This
proposal only concerns quoted constants to be processed by
COMPILE-FILE.
For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle. It
also attempts to leave room for implementations to differ. Some
implementations have made opposing choices because the language
doesn't specify one over the other. Some implementations already
handle constants that this proposal defines as not legal in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.
We try to set up a framework where some controversies can be defined
clearly and resolved as separate issues.
One of these is the question of when, if ever, to permit "coalescing"
of constants. Some implementations already take advantage of the
license given on page 78 of CLtL to gain some efficiencies. This
proposal provides definitions that make it possible to broaden the
conditions where coalescing is permitted (see related issue
CONSTANT-COLLAPSING).
Another question is whether "circular" constants are compilable (issue
CONSTANT-CIRCULAR-COMPILATION). Most implementations are capable of
supporting circular constants. Still, this proposal avoids requiring
all implementations to handle circular constants. Implementations
that do not handle circular constants presumably also do not make sure
that shared structure remains shared, sort of the opposite of
coalescing. This proposal avoids requiring shared structure to remain
shared across compilation.
Some implementations "lose information" about some constants during
compilation. We try to limit this proposal enough to reduce the
number of unhappy implementors to a bare minimum.
In this version, the question of immutability of some attributes of
objects in compiled constants is not addressed. Cris has taken that
material out of this proposal and is constructing a new proposal
covering just that issue. This proposal does define the concept of
"basic attributes" of various types of objects, and the other proposal
will refer to it, stating that most basic attributes of most types of
objects may be treated as immutable when the object appears in a
compiled constant.
Proposal: CONSTANT-COMPILABLE-TYPES:SPECIFY
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original, plus a few other restrictions.
A few types, such as streams, are not supported in constants. In
other words, an object containing one of these is not considered
similar as a constant to any other object. We say that it is an error
for these objects to appear in a (compiled) constant. Still some
implementations may support them and define how they are treated.
Some types of objects are treated as aggregate objects. For these
types, being similar as constants is defined recursively. We say that
an object of these types has certain attributes, and to be similar as
a constant to another object, the values of the corresponding
attributes of the two objects must also be similar as constants.
This kind of definition has problems with circular or "infinitely
recursive" objects such as a list that is an element of itself. We
consider the idea of depth-limited comparison, and say that two
objects are similar as constants if they are similar at all finite
levels. This idea is implicit in the definitions below, and applies
in all the places where attributes of two objects are required to be
similar as constants.
The rest of this proposal consists of a definition of the notion of
two objects being "similar as constants", organized by type, with some
notes about the additional constraints that the compiler must meet:
Number, Character
If either of two objects is a number or character, the two objects
are similar as constants if and only if they are EQL.
(Note that for cross-compilers it is not always possible to satisfy
this requirement for floating point numbers and complex numbers with
floating point parts. If it is necessary to choose two different
floating point values due to cross-compilation, each value chosen must
be one of the two adjacent, exactly representable numbers such that
the interval between them contains the other number. Other numbers
and characters are represented exactly, so they can be compared if
they are representable on both architecture, an issue for some
characters.)
Random-state
Only the operations PRINT, MAKE-RANDOM, and RANDOM apply to
random-states. Let us say that two random-states are functionally
equivalent if applying RANDOM to them repeatedly always produces the
same pseudo-random numbers in the same order.
Two random-states are similar as constants exactly if copies of them
made via MAKE-RANDOM-STATE are functionally equivalent.
Symbol
A symbol can only be similar to a symbol. References to symbols are
permitted in any constant. References to interned symbols are "by
name". If the symbol is interned, its name and the name of its home
package identify it.
A symbol with a home package is similar as a constant to a symbol when
the names of the symbols and the names of the home packages of the
symbols are similar as constants. (Both symbols must have home
packages.) Within a Common Lisp "address space", this implies that
the symbols are EQ.
If a symbol is not interned, i.e. its home package is NIL, it is
treated in a rather special way. To be similar as a constant to
another symbol, both symbols must be uninterned and have the same
name.
Constants that contain uninterned symbols have to satisfy an extra
constraint. The compiler must arrange that, within a file being
compiled with COMPILE-FILE, references to uninterned symbols that
are EQ in the source code must remain EQ in the compiled code.
Likewise, uninterned symbols that are not EQ must remain non-EQ after
compilation.
Package
A package can only be similar as a constant to a package. References
to packages are permitted in any constant. References to packages are
"by name": two packages are similar as constants when their names are
similar as constants. Within a Lisp "address space", packages with
the same name are EQ.
At load time, the package becomes the same as returned by
FIND-PACKAGE, given the package name. An error is signalled if no
package of that name exists at load time.
OTHER TYPES
-----------
For each of the types listed below, if either object is of the given
type, the two objects are similar as constants exactly if the other is
of that type and the values of all of the specified attributes are
similar as constants.
The attributes listed here can be called the "Basic Attributes" of
objects of each of these types.
Cons CAR, CDR.
Array For 1-dimensional arrays:
LENGTH and ELT for all legal indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
Note that array constants in a compiled file may lack
displacement, fill pointers, or adjustability, where the
constants in the source had them, but the compiler may
not produce constant arrays that have these features from
ones that do not. The point is to make sure that
declarations are not violated as a result of compilation.
Structure Slot values, name of structure type (a symbol reference).
Hash-table Keys and values. The table's test is of course unchanged
also. It is an error to compile a constant containing a
a hash table that has keys that are similar as
constants.
Readtable Character syntax type for each character in the table;
function for each readmacro character, mappings for
dispatch macros; whether terminating or nonterminating
for each readmacro.
Pathname Each pathname component
Stream, Compiled-Function
It is an error for a stream or compiled-function
to appear in a compiled constant, but the
language may be extended in the future to support certain
cases.
Function Function constants that are not compiled-functions and do
not close over any (lexical) variables are permitted in
compiled constants. Two functions are similar as
constants when they are operationally equivalent. Use of
global function bindings, global macro bindings, and
special variables must be considered external
dependencies for this purpose, and constants appearing in
the functions need only be similar as constants (at level
n-1?).
Generic-function, Method
Help is needed from the CLOS committee to determine what
to do here. (Presumably they would be treated in the same
way as ordinary functions?)
Standard-object
Help is needed from the CLOS committee to determine what
to do here. (There is a cl-cleanup issue, LOAD-OBJECTS,
pending which proposes a mechanism for dealing with
objects.)
Rationale:
This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.
Current practice:
This is believed to be very close to compatible with the Franz, Lucid,
Coral, and Texas Instruments implementations. It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.
Adoption cost:
Not known. Probably moderate or low -- for most implementations. The
cost would be to implementors rather than users since this part of the
language is currently underspecified. The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
Comparing functions is hard. One could define an operation that
converts an interpreted function into a lambda expression. One could
say that interpreted functions are similar as constants when their
associated lambda expressions are similar in the appropriate sense.
This similarity of lambda expressions would be syntactic, but would
have to allow for possible inline macro expansion. Other
transformations would have to be prohibited, or the functions would
have to report themselves as compiled.
This proposal seems to deal with the question of how to test whether
constants in different Lisp address spaces are similar as constants.
That appears to be important.
We need someone expert with floating-point computation to review the
discussion of similarity of floating point numbers as constants.
The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.
Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances. The cleanup issue LOAD-OBJECTS deals with this.
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
Most of the recent discussion on this proposal has centered around the
handling of functions and readtables, and on aspects relating to CLOS.
Sandra Loosemore notes:
Dumping a constant readtable is not likely to be particularly useful
in an implementation that cannot dump compiled function constants.
(In particular, readtables derived from the standard Common Lisp
readtable are likely to "contain" mostly compiled functions.) I'm
also not convinced that requiring non-compiled, non-closed function
constants buys anything for the user, since an implementation is
always free to make all functions compiled. It seems like it would be
simpler just not to require any function constants to be dumpable.
Jeff Dalton responds:
Although I didn't say anything about it before, I was always bothered
by the idea that functions would be dumped in readtables. Since it's
pretty clear that not all implementations can dump all functions, users
can't rely on it at all; and then the whole idea of dumping a readtable
begins to seem suspect.
JonL White notes:
The analogy between FIND-PACKAGE and FIND-CLASS suggests that class
objects are in the same "database" category as packages. Shouldn't
they be referenced "by name" in compiled file?
Moon responds:
In Flavors we generate metaobjects at compile time, but we never put
them (to speak loosely) into the compiled-code file; instead macros
like DEFFLAVOR and DEFMETHOD expand into Lisp code that obtains new
metaobjects at load time, based on the class name and generic function
name. I don't see how any other way could work, actually, since two
distinct compiled files that refer to a class by the same name must
end up referring to the same metaobject after loading. In Flavors we
don't have anonymous classes nor anonymous generic functions, so we
don't have to solve those issues.
[Issue LOAD-OBJECTS proposes] that the way to load an instance of a
standard-class from a compiled file is for a method of the instance
to return a form which is then evaluated at load time. The semantics
of loading an instance of a standard-class from a compiled file can be
entirely understood in terms of MAKE-INSTANCE or whatever other
function is called by the form returned by MAKE-LOAD-FORM; no new
concepts need be introduced. If the programmer of a given class wants
to use the class redefinition protocol, that class's MAKE-LOAD-FORM
method can output something that uses that protocol, and if he
doesn't, it can output something that doesn't.
∂07-Jan-89 1316 X3J13-mailer **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 13:12:18 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA23191; Sat, 7 Jan 89 14:11:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08985; Sat, 7 Jan 89 14:11:06 MST
Date: Sat, 7 Jan 89 14:11:06 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901072111.AA08985@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue COMPILER-LET-CONFUSION
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
16-Dec-88, V5 by Sandra Loosemore (major restructuring)
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
07-Jan-89, V7 by Sandra Loosemore (add example)
Status: **DRAFT**
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.
On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context. Compilers, for example, may not recognize these forms
properly in other than top-level contexts". At least one implementation
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.
Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations. However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.
(2) Remove the language on p. 145 of CLtL, which states that macro
functions are always defined in the null lexical environment. Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
(3) Define a ``top-level form'' as follows:
- Each form read by COMPILE-FILE from the input file is a top-level
form.
- Forms within the body of a top-level PROGN, EVAL-WHEN, or
COMPILER-LET are also top-level forms.
- The expansion of a top-level macro call is also a top-level form.
Top-level forms would be evaluated by the interpreter in a null
lexical environment, but evaluation in a null lexical environment does
not necessarily imply that the form is top-level.
(4) Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, including forms within the
body of a top-level PROGN, EVAL-WHEN, or COMPILER-LET. The order in
which non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
Rationale:
The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').
There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there. However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether.
Item (4) serves two purposes. First, it guarantees users that
compile-time side-effects from top-level EVAL-WHEN forms or defining
macros will happen in the correct order. Second, it allows compilers
to perform certain kinds of source-to-source transformations that
change the order of subforms.
For instance, the following example from CLtL
(let ((old-count *access-count*))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(setq *access-count* old-count)))
is entirely equivalent to:
(let ((old-count *access-count*))
(let ((thunk #'(lambda () (setq *access-count* old-count))))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(funcall thunk))))
(This is a real example from the A-Lisp compiler, which implements
UNWIND-PROTECT by having it push a "thunk" to perform the cleanup
actions onto the catch stack before executing the protected form.)
Current Practice:
CLtL mentions only that forms within a top-level PROGN, and not
COMPILER-LET, are treated as top-level. However, COMPILER-LET is
also treated specially in implementations derived from the MIT Lisp
Machine (TI and Symbolics), as well as Lucid and Coral (but not
VaxLisp).
Cost to implementors:
Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special when they
appear at top-level is removed. Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.
Discussion:
This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:IGNORE-COMPILE. In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
The issue of whether the bodies of top-level EVAL-WHENs should also be
considered top-level is controversial, as it effects the nesting
behavior of EVAL-WHEN. See issue EVAL-WHEN-NON-TOP-LEVEL for details.
There has also been a suggestion that MACROLET bodies should be
considered top-level. IIM Common Lisp implements this.
Note that proposal COMPILER-LET-CONFUSION:ELIMINATE would remove
COMPILER-LET from the language entirely.
∂07-Jan-89 1311 X3J13-mailer **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 13:11:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA23183; Sat, 7 Jan 89 14:10:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08982; Sat, 7 Jan 89 14:10:22 MST
Date: Sat, 7 Jan 89 14:10:22 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901072110.AA08982@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: EVAL-WHEN-NON-TOP-LEVEL
References: CLtL p. 69-70
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CHANGE, CLARIFICATION
Edit History: 6-May-88, V1 by Sandra Loosemore
16 Dec 1988, V2 by Sandra Loosemore (alternate direction)
30 Dec 1988, V3 by Sandra Loosemore (minor wording changes)
07 Jan 1989, V4 by Sandra Loosemore (update discussion)
Status: **DRAFT**
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
locations? What does it mean in such places?
Proposal EVAL-WHEN-NON-TOP-LEVEL:IGNORE-COMPILE:
Clarify that EVAL-WHEN may appear both at top-level and at
non-top-level. In non-top-level locations, however, the COMPILE
situation is effectively ignored.
More specifically, when an EVAL-WHEN form is processed by the
interpreter (that is, by the function EVAL), the presence of the EVAL
situation indicates that the body of the EVAL-WHEN should be evaluated
as an implicit PROGN. Otherwise, EVAL-WHEN returns NIL without
evaluating the body. The interpreter ignores the COMPILE and LOAD
situations.
When an EVAL-WHEN form is processed by the compiler:
First, if the situation COMPILE is specified:
- If the EVAL-WHEN form appears at top level (as defined in
proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW), then each of
the forms within the body of the EVAL-WHEN are evaluated by
the compiler in the null lexical environment using the
function EVAL.
- Otherwise, no compile-time evaluation takes place. An
implementation is permitted to signal a warning to indicate
that the compile-time evaluation is being ignored.
Then, if the situation LOAD is specified, then the compiler treats
the body of the EVAL-WHEN form as if it were an implicit PROGN.
If the situation LOAD is not specified, then the compiler should
treat the EVAL-WHEN form as if it were a constant value of NIL.
The compiler ignores the EVAL situation.
Rationale:
Restricting compile-time evaluation to top-level locations prevents
complications resulting from performing the evaluation in the wrong
lexical environment.
This definition of how EVAL-WHEN behaves is much simpler than that
given in CLtL, and makes it easier to explain its nesting behavior.
Allowing implementations to signal a warning when ignoring a
non-top-level EVAL-WHEN allows users to be informed that something
unusual is going on.
Current Practice:
IIM Common Lisp implements this proposal. Kim Barrett contributed the
following code that illustrates their implementation:
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
Cost to implementors:
Probably fairly minor in most implementations.
Cost to users:
Except for the change relating to possible multiple evaluation of
nested EVAL-WHENs, this proposal is a compatible extension.
Benefits:
The behavior of EVAL-WHEN is easier to understand. Making EVAL-WHEN
meaningful at non-top-level locations makes it more generally useful,
for example in the expansion of defining macros.
Discussion:
The behavior specified for top-level EVAL-WHENs in this proposal
differs slightly from that described in CLtL. In the case where both
COMPILE and LOAD are specified, CLtL indicates that the compile-time
evaluation should be interleaved with normal compiler processing of
each of the forms in the body, while this proposal specifies that the
evaluation of all of the body forms should take place before any of
the normal compiler processing. However, it is unlikely that this
would cause serious problems for any user programs.
The nesting behavior of EVAL-WHEN as described in CLtL has been
criticized as overly complicated and hard to understand, while this
proposal is much less complicated. However, the behavior of nested
EVAL-WHENs in this proposal is strongly tied to the definition of the
term "top-level"; see proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW.
If the bodies of top-level EVAL-WHENs are also considered to be
top-level, this leaves open the possibility that nested EVAL-WHENs may
cause multiple compile-time evaluations. For example,
(eval-when (eval compile load)
(eval-when (eval compile load)
(punch-paper-tape)))
would cause PUNCH-PAPER-TAPE to be called twice at compile time (once when
the outer EVAL-WHEN is processed, and again when the inner EVAL-WHEN is
processed). Some people think this behavior would be unacceptable.
This problem could be "fixed" by not considering the bodies of top-level
EVAL-WHENs to be top-level forms. In this case, outer EVAL-WHENs would
always override any nested EVAL-WHENs. For example,
(eval-when (eval load)
(eval-when (eval compile load)
(punch-paper-tape)))
would not cause *any* compile-time call to PUNCH-PAPER-TAPE. This
represents an incompatible change from the behavior of EVAL-WHEN
described in CLtL, where wrapping a form with (EVAL-WHEN (EVAL LOAD)
...) is essentially a no-op. Some people think the change would be a
good idea, others are uncertain whether the resulting cleaner
semantics would justify it.
As a compromise position, we could say that EVAL-WHEN passes
top-level-ness on to its body only if the COMPILE situation is not
specified.
Some people are not comfortable with messing with the definition of
top-level at all. On the other hand, others think it is important
that EVAL-WHEN and the various defining macros should apply consistent
rules for deciding when it is appropriate to perform compile-time
magic.
A final alternative is to go back to describing EVAL-WHEN the way it
was in CLtL, with a compile-time-too state variable.
∂08-Jan-89 2342 CL-Compiler-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 23:41:53 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Mon, 9 Jan 89 02:35:59 EST
Received: by kulla.think.com; Mon, 9 Jan 89 02:38:15 EST
Date: Mon, 9 Jan 89 02:38:15 EST
From: barmar@Think.COM
Message-Id: <8901090738.AA09372@kulla.think.com>
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 7 Jan 89 11:47:31 MST <8901071847.AA08919@defun.utah.edu>
Subject: **DRAFT** issue CONSTANT-COMPILABLE-TYPES
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
I guess my last message can be thought of as endorsing this idea.
barmar
∂09-Jan-89 0848 X3J13-mailer Editorial committee issues
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:48:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15007; Mon, 9 Jan 89 08:46:48 PST
Message-Id: <8901091646.AA15007@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:44
To: x3j13@sail.stanford.edu
Subject: Editorial committee issues
The editorial committee has completed discussion of 5 issues and
would like to bring them to vote, if possible, in Hawaii. Although
there will be copies available in Hawaii, please review these issues
and send comments to cl-editorial.
Thanks for your time.
kathy chapman
∂09-Jan-89 0849 X3J13-mailer Issue:DEPRECATION-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:49:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15093; Mon, 9 Jan 89 08:48:13 PST
Message-Id: <8901091648.AA15093@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:47
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:DEPRECATION-POSITION
Issue: DEPRECATION-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
When features of a language become outdated due to technology advances,
or unnecessary due to the addition of better features, should the old
features be deprecated from the language, or deleted outright?
Since there has never been a Common Lisp standard before, deprecation
is against a de-facto standard, which may or may not be appropriate.
Deletion, on the other hand, is cleaner, but may generate never-ending
discussion when the standard goes for public review (and even in the
X3J13 meeting).
In summary, there are two levels:
1) features in CLtL that are not present in ANSI Common Lisp 1989,
2) features in ANSI Common Lisp 1989 that will likely not be present in
future standards;
and the issues are:
a) what features fit into which category
b) how should implementations deal with such features? how can programs be
written to avoid problems with such features?
Proposal (DEPRECATION-POSITION:LIMITED)
Since Common Lisp has been used industrially, it is reasonable to
assume that any level 1 feature will be a cause for
at least some controversy. Therefore, this proposal suggests that
X3J13 put features categorized as level 1 in a separate package,
and retain features categorized as level 2 in the Lisp package, but
declare them deprecated in the standard.
The members of each level will be determined on a case-by-case basis by
the X3J13 committee.
Rationale:
The standard should contain information about deprecation since
the topic has been mentioned more than once in X3J13, and since
Common Lisp is such a large language.
It's not
unreasonable for a language the size of Lisp to get rid of the
never-used tools, but we don't want to generate years of discussion
over a relatively minor issue when the standard goes for public review.
Current Practice:
Fortran successfully deprecated one constant. However, a proposal
submitted during its latest standardization effort that
suggested deleting old features in favor of new ones was
opposed vehemently. The Pascal committee is currently opposed
to deprecation, and the SPARC proposal suggests that
deprecation should be dictated by the marketplace.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for future X3J13 decisions.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
"I personally would argue for not including "deprecated" features in
the standard at all, because including them now will make it harder to
remove them later. My perception is that ANSI Common Lisp is turning
out to be a much different language than what is described in CLtL,
particularly if CLOS becomes a required part of the language. If,
with the benefit of hindsight and experience, we now realize that some
"features" described in CLtL were really "bugs", the time to remove
them is *before* they become cast in stone as part of ANSI Common
Lisp. I suspect that most implementors will continue to provide these
features as extensions anyway, as long as a substantial number of
their customers are still using them."
Response:
Perhaps most implementors will continue to provide the deleted features,
but they will do that also if they are deprecated. Since the only real
difference between the two is the amount of discussion one will generate
over the other (I think that worrying about future difficulty of getting
rid of the features is not a "real" difference yet), it seems that choosing
the route of least resistance in this case is the wisest course.
Comment:
"For the most part, X3J13 hasn't been able to deal with
which features fit into which category until how the categories will
be divided has been resolved. In particular, there are a number of
features that we didn't want to remove from ANSI Common Lisp 1989 if
it would be awkward for implementations to continue to support them or
programs to continue to use them, but wanted to at least declare them
"obsolete". There's been some debate on whether CHAR-FONT, for
example , should be deleted before the standard is written, or declared
deprecated within the standard."
∂09-Jan-89 0851 X3J13-mailer Issue:SUBSETTING-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:51:25 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15185; Mon, 9 Jan 89 08:50:10 PST
Message-Id: <8901091650.AA15185@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:49
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:SUBSETTING-POSITION
Issue: SUBSETTING-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman (with discussion by Masinter)
Problem Description:
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and
still be a conforming implementation?
What subsets should be specified in the draft standard we submit to
ANSI?
What position should we take if someone should propose a subset?
Proposal (SUBSETTING-POSITION:NONE)
The draft standard we submit to ANSI
contains *no* subsets. In the section on "subsetting" it should be mentioned
that Lisp is a "small" language with a "big" library and that the conventional
mechanism for allowing small memory images is auto-load.
Rationale:
Current Practice:
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However,
the only two levels that were important were the minimum
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another.
The new Fortran language standards committee is
banning subsetting.
SPARC feels that
subsets aren't good for facilitating interchange, but serve the
purpose of allowing
timely implementation of the standard.
A suggestion that was made by most language committee representatives
was to group subsetted parts meaningfully, and to minimize the number
of levels.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for making decisions in X3J13.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
First of all, we should review the possible kinds of subsets one might
have: subsets might omit syntax, functions, admissable values or arguments
to functions, or data types. For example, a subset might disallow SPECIAL
declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
to work on proper lists, or might omit complex numbers. Each of these is a
"subset" in the sense that a subset of correct programs for the "full"
language would be correct for the "subset" language.
Subsets can have various levels of "determinability" for programs. The
issue is: how easy is it to tell whether a program written in the "full"
language would run in a "subset" implementation? Except for the
(non-trivial) issue of macro expansions, some subsets are "lexically"
determinable, e.g., if a function is omitted, you can tell if the program
uses it by scanning the program. Some subsets are "dynamically"
determinable, e.g, a subset might signal an error if the :TEST argument to
MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
dynamically determinable, e.g., if the subset implements dynamic extent for
rest lists, it may be impossible to tell even with run-type checks whether
the a program written in the "full" language would conform.
Some "subsets" might be merely restrictive interpretations, e.g., a
"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
BREAK halt the program execution rather than "enter the debugger"; since we
cannot define what "enter the debugger" means, we might want to define
explicitly this subset as a reasonable one for embedded systems.
∂09-Jan-89 0851 X3J13-mailer Issue:CUT-OFF-DATES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:50:53 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15165; Mon, 9 Jan 89 08:49:39 PST
Message-Id: <8901091649.AA15165@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:49
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:CUT-OFF-DATES
Issue: CUT-OFF-DATES
References: Working draft of the standard
Category: Policy
Edit history: 20-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
Problem Description:
The X3J13 committee has informally agreed that a 12/89 standard is
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.
Proposal (CUT-OFF-DATES:ESTABLISH)
Item Cut-off date for changes
________________________________________________(First day of the month)____
Format of tool descriptions 11/88
Meaning of each item in each tool description 11/88
Fonts 2/89
Changes to existing functions 4/89
Additional functions 4/89
Compliance 2/89
Error terms 2/89
Contents of Chapter 6 tool descriptions:
- Syntax section 2/89
- Arguments section 5/89
- Values section 5/89
- Description section 5/89
- Examples section 2/89
- Side Effects section 3/89
- Affected By section 3/89
- Conditions section 4/89
- See Also section 2/89
- Notes section 5/89
Changes to TOC 2/89
Contents of sections: 4/89
- 1.1 4/89
- 1.2 4/89
- 1.3 4/89
- 1.4 4/89
- 1.5 4/89
- 1.6 4/89
- 1.7 4/89
- 1.8 4/89
- 2.1 5/89
- 2.2 5/89
- 2.3 5/89
- 2.4 5/89
- 2.5 5/89
- 3.1 5/89
- 3.2 5/89
- 4.1 6/89
- 4.2 6/89
- 5.1 6/89
- 5.2 6/89
- 5.3 6/89
- 5.4 6/89
The way this breaks down is as follows:
Things that have already frozen: format of Chapter 6 tool descriptions,
meaning of each tool description category.
Things that will be frozen after the 1/88 meeting: fonts, compliance,
error terms, syntax section, examples section, see also section,
side effects section, affected by section, table of contents, and
this schedule of cut-off dates.
Things that will be frozen after the 3/88 meeting:
Contents of Chapters 1, 2, and 3, New issues that change existing functions
or add new functions, values section, arguments section, description
section, notes section, and conditions section.
Things that will be frozen by 6/1/89:
Chapters 4 and 5.
All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.
To change these dates, a 2/3 vote of the editorial committee
or a majority vote of X3J13 is required.
Rationale:
In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
Current Practice:
None.
Adoption Cost:
None.
Benefits:
Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
"There are a couple of areas where I expect some further work that might
impact these dates:
a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues
b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances.
c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left."
∂09-Jan-89 0852 X3J13-mailer Issue:CONFORMANCE-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:52:34 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15368; Mon, 9 Jan 89 08:51:17 PST
Message-Id: <8901091651.AA15368@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:50
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:CONFORMANCE-POSITION
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance?
Proposal (CONFORMANCE-POSITION:PROGRAM)
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
A conforming program is one that can be executed by a conforming
implementation with no unhandled exceptions and no unspecified
and potentially harmful consequences.
The basic test for conformance will be that a program written to the letter
of the standard will run in all "conforming" implementations.
The basic rules are as follows:
. Conforming programs use the syntax described in the standard.
. Conforming programs are written using the functions, macros,
special forms, variables, constants described in the standard.
. Conforming implementations provide the functions, macros, special
forms, variables, constants, and arrange that they behave in ways
that conform to the descriptions of them in the standard.
Rationale:
The standard must contain information about conformance. Including
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming programs.
Current Practice:
CLtL generally describes things in terms of what a correct program can
expect.
dpANS C is also in terms of programs. They have further defined
both "conforming" and "strictly conforming" programs; the
difference has something to do with how the program deals with features
that the standard says are implementation-defined.
Pascal defines
conformance in terms of both, PL/I defines conformance in terms of
conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
Adoption Cost:
None.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
I think we might want to introduce the notion of a "portable" program, as
well as a "conformal" one.
A "portable Common Lisp program" is a conformal Common Lisp program that
"works the same" in all conformal implementations.
Response:
There should be no difference, then between a portable program and a
conforming program. Why introduce new terms?
∂09-Jan-89 1155 X3J13-mailer Issue:EXTENSIONS-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:55:13 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA15119; Mon, 9 Jan 89 08:48:49 PST
Message-Id: <8901091648.AA15119@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:48
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:EXTENSIONS-POSITION
Issue: EXTENSIONS-POSITION
References: Chapter 1, Working draft of standard
Category: Clarification
Related Issues: CONFORMANCE-POSITION, IF-BODY
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
What is the definition of a language extension?
What effect does a language extension have on a conforming program?
What obligation does an implementation have to warn the user that an
extension is being used?
Is it OK to define Common Lisp functions with extra optional or
keyword parameters, with system dependent meanings? E.g. Lucid's
COMPILE-FILE has several keyword arguments not mentioned in CLtL.
Is it OK to return extra values from Common Lisp functions?
Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL? For example, suppose + is defined on
vectors to do component-wise addition on the elements? Arguments to +
"must" be numbers, meaning that it "is an error" to supply anything
other than numbers, meaning that anything can happen when you supply
arguments other than numbers.
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.
Extensions that are associated with symbols that are external in the LISP
package are reasonable. Extensions to existing functions
as far as additional optional or keyword arguments are disallowed,
except where explicitly allowed. Extensions to existing functions as far as
data types allowed, extra arguments, or extra return values are disallowed
except where explicitly allowed.
If the standard says that "the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
Rationale:
The standard should contain information about language extensions
since most implementations have extended the language.
Current Practice:
CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL. In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
Adoption Cost:
Vendors will have to improve their documentation
to list all their extensions. Vendors will have to go through their
implementation and determine what is or isn't an extension.
Benefits:
This definition will provide a basis for proper understanding of
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comments:
"The most commonly proposed solution to this kind of problem is to
require the implementation to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability. Whether this should be the default
mode is up for debate; I think most other standards that do this don't
require it to be the default."
Response:
Requiring an implementation to be able to disable extensions seems like
a more costly alternative than requiring an implementation to document
its extensions as extensions if it is to be conforming, since presumably
an implementation will document user-visible extension anyway.
Comment:
It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.
Response:
There are currently statements in the conformance section of the standard
that state what you have demonstrated here. They will be left in that
section.
∂09-Jan-89 1242 X3J13-mailer Re: Issue:SUBSETTING-POSITION
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89 12:41:24 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06734; 9 Jan 89 19:42 GMT
Date: Mon, 9 Jan 89 19:43:21 GMT
Message-Id: <11708.8901091943@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue:SUBSETTING-POSITION
To: chapman <@decwrl.dec.com:chapman@aitg.dec>, x3j13@sail.stanford.edu
In-Reply-To: chapman's message of 9 Jan 89 11:49
Subsetting has long been a somewhat controversial topic, but I think
it is fair to say that "no subsets" is the dominant position in X3J13.
It is possible that subsets might be helpful at the ISO level, but
so far the idea of a subset (without any other changes) has not attracted
too great a following.
> Proposal (SUBSETTING-POSITION:NONE)
>
> The draft standard we submit to ANSI contains *no* subsets. In the
> section on "subsetting" it should be mentioned that Lisp is a "small"
> language with a "big" library and that the conventional mechanism for
> allowing small memory images is auto-load.
I'd be happier if it were fairly easy for someone reading the standard
to determine which part was the "library" and which the core language.
For example, where do we find FUNCALL and APPLY?
The draft C standard has an explicit division. Section 3 is
"Language" and section 4 is "Library". It may not be necessary
to go that far for Common Lisp.
> Current Practice:
>
> The 1981 PL/I was subsetted and the results were a range of
> implementations between the subset and the full language; nobody wanted
> to use the subset so vendors were forced to implement the full language
> eventually anyway.
I'd be interested in knowing more of the PL/I story. As I recall, we
(Dartmouth) were quite happy with "Subset G".
I suppose you might want to add something about Basic. At one point,
there was an ANSI standard for "Minimal Basic". It was too minimal.
Later work on ANSI Basic involved a rather different-looking language
(think "structured control structures") and a number of optional
extensions for such things as real-time process control. I don't
know the details or what finally happened, but it looked fairly messy.
∂09-Jan-89 1303 X3J13-mailer revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 13:03:27 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00910g; Mon, 9 Jan 89 12:59:24 PST
Received: by challenger id AA16753g; Mon, 9 Jan 89 12:55:22 PST
Date: Mon, 9 Jan 89 12:55:22 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901092055.AA16753@challenger>
To: x3j13@sail.stanford.edu
Subject: revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
Guest Room 120 of the hotel has been reserved for Subcommittee meetings.
Please let me know how much time you need and what day and time you'll need.
I'll make up a scudule and post it.
---jan---
Monday, January 16
7:30am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports to the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Character Subcommittee Report, Thom Linden (2 hours)
7 Coffee Break 10:30
8 Character continuation
9 Chapter 3 CLOS, Gregor Kiczales (1 hour)
10 LUNCH 12:00 Voyage Room Restaurant
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
13 Recess 3:00
14 Call to Order, 8:00pm
15 Editorial Subcommittee Report, Kathy Chapman (1 hour)
16 Other Subcommittee Reports
16a Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Cleanup continuation
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
∂10-Jan-89 0905 X3J13-mailer FTP access to compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:05:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA03597; Tue, 10 Jan 89 10:04:18 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11488; Tue, 10 Jan 89 10:04:15 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901101704.AA11488@defun.utah.edu>
Date: Tue, 10 Jan 89 10:04:14 MST
Subject: FTP access to compiler issues
To: x3j13@sail.stanford.edu
Copies of the pending issues from the compiler committee are available
for anonymous FTP from cs.utah.edu (128.110.4.21). Look in directory
pub/cl-compiler/pending.
There are also copies of the issues that were passed at the last meeting
in directory pub/cl-compiler/passed.
-Sandra
-------
∂10-Jan-89 0935 X3J13-mailer **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:34:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA05135; Tue, 10 Jan 89 10:33:45 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11507; Tue, 10 Jan 89 10:33:41 MST
Date: Tue, 10 Jan 89 10:33:41 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901101733.AA11507@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue LOAD-TIME-EVAL
Category: CLARIFICATION
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
Status: **DRAFT**
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls within the function have already been expanded
and will not be expanded again when the function is called.
(See CLtL p. 143.)
- Nested COMPILER-LETs will not bind any variables when the function
is called (CLtL p. 112).
- If the function contains nested EVAL-WHENs, only the LOAD (and not
the EVAL) situation is applicable.
- If the function contains nested LOAD-TIME-VALUE forms, these have
already been pre-evaluated and will not be evaluated again when
the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for interpreted FUNCTIONs
to satisfy the above criteria but not be distinguished as
COMPILED-FUNCTIONs.
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify that when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal assigns some specific properties to compiled functions.
It also states what many people believe to be the minimum functionality
required of a compiler.
Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:
(1) Remove the type specifier COMPILED-FUNCTION and the predicate
COMPILED-FUNCTION-P from the language.
(2) Clarify that functions produced by COMPILE, or defined in a file
that is compiled with COMPILE-FILE and then LOADed must satisfy
the same requirements listed in section (1) of the previous proposal.
Rationale:
Distinguishing between compiled and non-compiled functions is of
little use to portable programs.
This proposal states what many people believe to be the minimum
functionality required of a compiler.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation, but it
seems unlikely that any existing implementation would have problems
with the requirements in item (1).
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
Cost to implementors:
Unknown, but probably small for either proposal. Under proposal
FLUSH, implementations could continue to do whatever they do now with
the COMPILED-FUNCTION type as an extension.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One possible use of the COMPILED-FUNCTION type is in declarations. Are
there any implementations which have a distinguished representation for
COMPILED-FUNCTIONs, that use type declarations to compile calls to these
functions more efficiently?
∂10-Jan-89 1238 X3J13-mailer summary of open cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 12:38:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA13596; Tue, 10 Jan 89 13:36:57 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11651; Tue, 10 Jan 89 13:36:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901102036.AA11651@defun.utah.edu>
Date: Tue, 10 Jan 89 13:36:50 MST
Subject: summary of open cl-compiler issues
To: x3j13@sail.stanford.edu
Here is a complete list of all open cl-compiler issues, as of today
(10 Jan 1989).
Non-draft issues distributed prior to January meeting:
ALLOW-LOCAL-INLINE (v4)
Interpretation of INLINE/NOTINLINE declarations.
COMPILE-ENVIRONMENT-CONSISTENCY (v3)
What kinds of things can/must the compiler "wire in" to the code
it compiles?
DEFCONSTANT-SPECIAL (v3)
Does DEFCONSTANT proclaim the variable SPECIAL?
LOAD-TIME-EVAL (v8)
Add a new special form similar to what #, does.
SHARP-COMMA-CONFUSION (v2)
Remove the #, read macro.
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (v8)
Clarify compile-time side effects of various defining macros.
CONSTANT-MODIFICATION (v2)
It's an error to destructively modify quoted constants.
Draft issues distributed prior to January meeting:
COMPILER-DIAGNOSTICS (v8)
Clarify status and handling of errors and warnings signalled during
compilation.
COMPILER-VERBOSITY (v5)
Mechanisms for controlling progress messages issued by the compiler.
CONSTANT-COMPILABLE-TYPES (v5)
What types of objects can appear as quoted or self-evaluating constants
in compiled code?
CONSTANT-CIRCULAR-COMPILATION (v5)
Must circular or recursive objects be compiled correctly? Must the
compiler preserve sharing of substructures?
CONSTANT-COLLAPSING (v5)
Should the compiler be allowed to "collapse" or coalesce constants
that satisfy a more general equivalence relationship than EQUAL?
QUOTE-MAY-COPY (v4)
May COMPILE and EVAL construct equivalent copies of quoted or
self-evaluating constants, or must constants share structure with
the source code for the program? Do the constraints on what objects
are valid constants also apply to COMPILE and EVAL, or only to
COMPILE-FILE?
EVAL-WHEN-NON-TOP-LEVEL (v4)
What does EVAL-WHEN mean when it appears in non-top-level locations?
DEFINING-MACROS-NON-TOP-LEVEL (v7)
Are defining macros such as DEFUN meaningful in non-top-level locations?
COMPILED-FUNCTION-REQUIREMENTS (v2)
What does the COMPILED-FUNCTION type imply? Do COMPILE and
COMPILE-FILE construct COMPILED-FUNCTIONs?
Other issues under discussion but not yet distributed:
COMPILER-LET-CONFUSION (v5)
The description of COMPILER-LET in CLtL is broken -- should we fix
it or eliminate it entirely?
MACRO-ENVIRONMENT-EXTENT (v1)
Do environment objects received as the &ENVIRONMENT argument to a
macro have dynamic or indefinite extent?
MACRO-ENVIRONMENT-CREATOR (v1)
How can code-walkers add the macro definitions in a MACROLET to
an environment object suitable for passing to MACROEXPAND?
DEFCONSTANT-NOT-WIRED (v5)
Add a way to declare a constant like DEFCONSTANT, but without giving
the compiler permission to "wire in" the value into compiled code.
Issues where proposals have been submitted but not followed up on:
CONSTANT-ARRAY-ATTRIBUTES
What attributes of constant arrays are preserved by compilation?
Probably subsumed by CONSTANT-COMPILABLE-TYPES.
COMPILE-FILE-ENVIRONMENT
Clarify that macro environment objects contain information about
whether it was built by the compiler or interpreter.
Superseded by issue SYNTACTIC-ENVIRONMENT-ACCESS, unless that issue
has died.
DEFCONSTANT-VALUE
When is the value form to DEFCONSTANT evaluated?
Subsumed by issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.
DEFINE-OPTIMIZER
Provide a macro-like way of specifying source-to-source transformations.
Waiting for revisions (Pitman)
FILE-COMPILATION
same issue as CONSTANT-COMPILABLE-TYPES?
PROCLAIM-ETC-IN-COMPILE-FILE
Are top-level calls to PROCLAIM handled specially by the compiler?
Waiting for resolution of related cleanup issues (DEFPACKAGE,
IN-PACKAGE-FUNCTIONALITY)
SYNTACTIC-ENVIRONMENT-ACCESS
Provide accessors and constructors for lexical environment objects.
Waiting for new writeup (Benson)
WITH-COMPILATION-UNIT
Provide a way to compile a group of files as a unit for the purposes
of error messages.
Waiting for revisions to existing proposal (Pitman)
-------
∂10-Jan-89 1543 X3J13-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:43:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:42:31 PST
Date: 10 Jan 89 15:42 PST
From: masinter.pa@Xerox.COM
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 2)
To: x3j13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
cc: masinter.pa@Xerox.COM
Message-ID: <890110-154231-6930@Xerox>
In addition to the many issues on the ballot, there are
a number of other issues that are in various states of
completion. If we have time, we may be able to consider
some of these.
!
Forum: Cleanup
Issue: APPLYHOOK-ENVIRONMENT
References: APPLYHOOK (CLtL p. 323)
Category: CHANGE
Edit history: Masinter, 6-Jan-89, Version 1
Masinter, 10-Jan-89, Version 2
Problem description:
The function APPLYHOOK is documented to take an optional environment
argument. CLtL says "Furthermore, the env argument is used as the lexical
environment for the operation; env defaults to the null environment."
However, there is no way that the lexical environment can effect the way in
which APPLYHOOK processes its arguments; it merely calls the specified
function, and function call is not affected by lexical environments. (The
"function" argument to APPLYHOOK is a function object.)
This has been regularly a source of confusion for programmers encountering
APPLYHOOK.
The comments also apply to functions bound to *APPLYHOOK*, i.e., under the
description of *APPLYHOOK* on p.322, the following
"The non-NIL value of *APPLYHOOK* should be a function that takes
three arguments, a function, a list of arguments and an
environment..."
Proposal (APPLYHOOK-ENVIRONMENT:REMOVE-ENV):
Remove the optional "ENV" argument to APPLYHOOK. Specify
that the non-NIL value of *APPLYHOOK* should be a function that takes
two arguments, a function and a list of arguments.
Rationale:
Removes a very minor wart.
Current practice:
Most implementations accept an extra argument and then ignore it.
Cost to Implementors:
Remove optional ENV argument from APPLYHOOK and any code that passes one to
APPLYHOOK.
Cost to Users:
Remove any ENV argument passed to APPLYHOOK. Fix any *APPLYHOOK*
functions to only take two arguments (or to make the third argument optional.)
Cost of non-adoption:
Continued confusion.
Performance impact:
None
Benefits:
Removes a wart.
Esthetics:
Minor improvement.
Discussion:
This was discussed on the Common Lisp mailing list several years ago, but
slipped through the cracks.
∂10-Jan-89 1555 X3J13-mailer Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:55:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JAN 89 15:53:55 PST
Date: 10 Jan 89 15:53 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890110-155355-6963@Xerox>
!
Forum: Cleanup
Issue: COMPLEX-ATAN-BRANCH-CUT
References: CLtL p.208, 212
Related issues: IEEE-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Problem description:
The formula that defines ATAN results in a branch cut that is at
variance with the recommendations of Prof. W. Kahan and with the
implementations of that function in many computing systems and
calculators.
Proposal (COMPLEX-ATAN-BRANCH-CUT:TWEAK):
Replace the formula
arctan z = - i log ((1+iz) sqrt (1/(1+z↑2)))
with the formula
arctan z = (log (1+iz) - log (1-iz)) / (2i)
This leaves the branch cuts pretty much in place; the only change is
that the upper branch cut (on the positive imaginary axis above i)
is continuous with quadrant I, where the old formula has it continuous
with quadrant II.
Examples:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Current
(atan #c(0 2)) => #c(1.57... -0.549...) ;Proposed
Note: 1.57... = pi/2, and 0.549... = (log 3)/2.
Rationale:
Compatibility with what seems to be becoming standard practice.
Current practice:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Symbolics CL
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Allegro CL 1.1 (Macintosh)
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Sun-4 CL 2.1.3 of 10-Nov-88
(atan #c(0 2)) => #c(1.57... -0.549...) ;Sun CL 2.0.3 of 30-Jun-87
(atan #c(0 2)) => #c(1.57... 0.549...) ;KCL of 3-Jun-87
Note that in KCL the upper branch cut is thus continuous with
quadrant I, but its lower branch cut is continuous with quadrant III!
Cost to Implementors:
ATAN must be rewritten. It is not a very difficult fix.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Note that the proposed change invalidates the identities
arctan i z = i arctanh z
and arctanh i z = i arctan z
on the upper branch cut.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Incompatibility with HP calculators.
Benefits:
Numerical analystsmay find the new definition easier to use.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
Paul Penfield of MIT, after whose article the Common Lisp branch
cuts were originally patterned, endorses this change.
∂10-Jan-89 1710 X3J13-mailer Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 17:09:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JAN 89 17:08:39 PST
Date: 10 Jan 89 17:08 PST
Sender: masinter.pa@Xerox.COM
Forum: Cleanup
Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890110-170839-7158@Xerox>
!
Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
References: DEFSTRUCT (p. 308)
Category: CHANGE
Edit history: 5-Oct-88, Version 1 by Chapman
6-Jan-89, Version 2 by Masinter
Problem Description:
It is left up to the implementation whether or not the DEFSTRUCT access
function is declared inline. Thus, some programmers write:
(PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
(DEFSTRUCT FOO A B C)
in portable code in case the code is run in an implementation where
the INLINE proclaimation is meaningful but not the default for
DEFSTRUCT accessors.
Proposal (DEFSTRUCT-ACCESS-FUNCTIONS-INLINE:YES)
Make it mandatory that implementations declare access functions inline.
Of course the declaration may or may not mean anything within the
particular implementation.
Rationale:
This requirement resolves user ambiguity.
Current Practice:
We've not surveyed many implementations, but apparently they
differ as to whether INLINE for defstruct accessors is the default.
Cost to implementors:
Minimal.
Cost to users:
Minimal.
Benefits:
This clarification will give users insurance that the inline declaration
has been made for the access function.
Aesthetics:
Specified is simpler than not-specified.
Performance Impact:
Small. Some programs might have different size/space characteristics.
Discussion:
We know of no implementation where such automatic inlining would
be inappropriate, even in cases where INLINE is recognized. Certainly
implementations are free to ignore INLINE proclaimations even
selectively, i.e., ignore INLINE proclaimations only for DEFSTRUCT
accessors. The major impact of this proposal is just to make it clear
that a separate (PROCLAIM '(INLINE ...)) is not necessary.
∂11-Jan-89 1433 X3J13-mailer Another DRAFT Agenda
Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:33:01 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03447g; Wed, 11 Jan 89 08:58:23 PST
Received: by challenger id AA02160g; Wed, 11 Jan 89 08:54:16 PST
Date: Wed, 11 Jan 89 08:54:16 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901111654.AA02160@challenger>
To: x3j13@sail.stanford.edu
Subject: Another DRAFT Agenda
After a flurry of mail we have an updated DRAFT Agenda
Monday, January 16
7:30am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports to the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Chapter 3 CLOS, Gregor Kiczales (1 hour)
7 Coffee Break 10:30
8 Chapter 3 CLOS, Gregor Kiczales (1 hour)
9 LUNCH 12:00 Voyage Room Restaurant
10 Editorial Subcommittee Report, Kathy Chapman (1 hour)
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Recess 3:00
13 Call to Order, 8:00pm
14 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
15 Other Subcommittee Reports
16 Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Character Subcommittee Report, Thom Linden (1 hour)
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
∂11-Jan-89 1649 X3J13-mailer Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 16:49:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 16:43:33 PST
Date: 11 Jan 89 16:43 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-164333-11134@Xerox>
!
Forum: Cleanup
Issue: IEEE-ATAN-BRANCH-CUT
References: CLtL p.203-214
Related issues: COMPLEX-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Version 2, 11-Jan-89, Masinter (1st => 3rd person)
Problem description:
If an implementation provides a floating-point minus zero as well as a
floating-point plus zero, most notably as in IEEE 754 floating-point
arithmetic, then slight adjustments in the branch cuts of transcendental
functions are appropriate.
If there is a minus zero and a plus zero, then *no* complex number
is actually "on the axis" whether real or imaginary. Instead,
numbers of the form x+0i and x-0i straddle the real axis, and those
of the form 0+xi and -0+xi straddle the imginary axis. Branch cuts
that lie on the axes therefore run between such numbers, and directions
of continuity are not an issue.
Proposal (IEEE-ATAN-BRANCH-CUT:SPLIT):
Redefine the branch cut for two-argument ATAN, covering
the cases where there is or is not a minus zero, and then redefine *all*
other functions that have branch cuts in terms of two-argument ATAN.
Specifically, first define PHASE in terms of two-argument ATAN,
and complex ABS in terms of real SQRT (which has no branch cut problems);
then define complex LOG in terms of PHASE, ABS, and real LOG; then define
complex SQRT in terms of LOG; and then define all others in terms of these.
In this propoal Lisp expressions should be taken as mathematical
formulas that actually are implemented in other ways for improved accuracy.
(1) If there is no minus zero, two-argument ATAN behaves as in CLtL.
If there is a minus zero, then some cases are modified:
Condition result
y=+0 x>0 +0
y=-0 x>0 -0
y=+0 x<0 +pi
y=-0 x<0 -pi
y=+0 x=+0 +0
y=-0 x=+0 -0
y=+0 x=-0 +pi
y=-0 x=-0 -pi
The range of two-argument atan therefore includes -pi in this case.
Note that the case y=0 x=0 is an error in the absence of minus zero,
but is defined in the presence of minus zero.
(2) (PHASE X) = (ATAN (IMAGPART X) (REALPART X)), as before, but now
the range of PHASE may include -PI if there is a minus zero.
(3) (ABS X) = (SQRT (+ (* (REALPART X) (REALPART X))
(* (IMAGPART X) (IMAGPART X)))), as before
(4) (LOG X) = (COMPLEX (LOG (ABS X)) (PHASE X))
(5) (SQRT X) = (EXP (/ (LOG X) 2))
(6) For EXPT, ASIN, ACOS, ATAN, ASINH, ACOSH, ATANH use the formulas
in CLtL pp. 211-213, but use the formulas (1-5) above as the
definitions of LOG and SQRT in order to determine the branch cuts
properly.
Examples:
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 -0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Proposed (= current)
(LOG #c(-1.0 -0.0)) => #c(0.0 -3.14159...) ;Proposed (conjugate)
Rationale:
The current specification ignores some natural consequences of IEEE
floating-point arithmetic. The proposed specification produces results
more natural to that arithmetic.
Current practice:
Of implementations that support a minus zero that I have checked,
such as Sun-4 CL 2.1.3 of 10-Nov-88 and Symbolics CL, all follow
the current CLtL specification.
The IEEE trig library atan2 routine written by K.C. Ng (with the advice
or supervision of W. Kahan, I believe), and distributed with BSD UNIX
(it is file /usr/src/usr.lib/libm/IEEE/atan2.c on my machine) follows
this proposal for treatment of minus zero.
Cost to Implementors:
Some of the trig routines will require some rewriting. Probably certain
tests that are now written using ZEROP need to be rewritten to use
FLOAT-SIGN instead.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Probably there is no cost.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Unnatural treatment of some functions on machines supporting IEEE
floating-point arithmetic.
Benefits:
Natural treatment, etc.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
∂11-Jan-89 1703 X3J13-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 17:03:01 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 16:52:58 PST
Date: 11 Jan 89 16:52 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: LISP-PACKAGE-NAME, (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-165258-11168@Xerox>
!
Issue: LISP-PACKAGE-NAME
References: 11.6 Built-in Packages (pp181-182)
Category: CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Problem Description:
Since ANSI Common Lisp will differ from the Common Lisp described by CLtL,
it will not be possible to have support for both in the same Lisp image
if ANSI Common Lisp insists on placing its functionality in the package
named LISP.
Further, use of the name unqualified name LISP by the ANSI Common Lisp
community is inconsistent with ANSI's expressed position to ISO that
the term "LISP" names a language family rather than a specific dialect
within that family.
Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
Define that the COMMON-LISP package has nickname CL.
Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
between COMMON-LISP and LISP in implementations simultaneously supporting
both, clarify that the initial symbols specified by ANSI Common Lisp as
belonging in the COMMON-LISP package need not have a home package of
Common-Lisp.
Test Case:
In an implementation supporting CLtL's LISP package and
the ANSI Common Lisp CL package proposed here:
(EQ 'LISP:T 'CL:T)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:CAR 'CL:CAR)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:FUNCTIONP 'CL:FUNCTIONP)
=> not specified, due to this proposal, but since FUNCTIONP is
changed incompatibly between CLtL (LISP) and CL (ANSI), there
are good reasons why this might return NIL.
(SYMBOL-PACKAGE 'CL:T)
=> not specified, due to this proposal. Perhaps #<Package CL>,
perhaps #<Package LISP>, or perhaps something implementation-specific.
(SYMBOL-PACKAGE 'LISP:T)
=> not specified, not due to this proposal, but because CLtL didn't
specify this explicitly.
Rationale:
In practice, some implementations will have very legitimate reasons for
wanting to Lisp dialects to be coresident. As it stands, they will have
little other choice than to make the two use different packages, and so
will be forced to be incompatible with one or the other dialect unless
we choose a different package name for the one dialect for which there
is currently no existing code.
Not only is this important the CLtL and ANSI Common Lisp communities, but
also, if we continue to use the name LISP, it sends a signal to the ISO
Lisp community that the "latest and greatest" Lisp should use the generic
name LISP, and they may try to use it as well. If ISO Lisp turns out to
be very different than ANSI Common Lisp, there may be motivation down the
line for having ISO Lisp and ANSI Common Lisp co-resident, and conflicts
will inevitably arise if both want to use the name LISP. This will almost
certainly lead to a confrontation where one Lisp dialect tries to force
the other out by the artificial means of asserting its right to this
generic name. Choosing a name which compatibly admits the option of
introducing other dialects into the environment at a later date without
conflict is a good way to avoid a class of potential problems.
Although there are a few problems which could come up due to the symbol
package of initial symbols being unspecified, experience with
implementations that do this suggests that they are very few.
Problems occur only in the rare circumstance that all of the following
conditions are met:
- A symbol S on the LISP package but with home package H (that is not "LISP")
is shadowed in some package P of implementation A.
- A program F in package P uses the shadowed symbol H:S by an explicit
LISP: or H: package qualification. (Only the case of using "LISP:" is
interesting, of course, since if H were named explicitly, we would be
outside the bounds of portable code).
- The program F, referring to H:S, is printed out in implementation A
while using package P (or some other package that shadows S, so that
the H package qualifier appears explicitly) and an attempt is made to
re-read it in implementation B.
- Implementation B has no package named H, has a package named H but no
external symbol named S, or has a package named H with external symbol
S but the symbol H:S has different semantics in implementation B than
it did in implementation A.
In practice, this hardly ever happens. It would happen even less if
programmers were explicitly alerted that it was a potential problem they
needed to guard against.
Current Practice:
Symbolics Genera already has a package named COMMON-LISP with nicknames
CL and LISP. As such, this would be an incompatible change for Genera.
Cost to Implementors:
Small.
In some cases, this may even have `negative cost' because it will provide
implementors a way of avoiding incompatible changes to released operators.
Cost to Users:
Small.
In some cases, this may even have `negative cost' because existing code
would be able to continue to run in implementations which chose to support
both CLtL's LISP and ANSI Common Lisp's CL packages, thereby allowing
developers to put off a massover changeover, perhaps doing the transition
more incrementally.
Cost of Non-Adoption:
Implementations trying to support multiple dialects in the same environment
would be forced to violate one or the other spec.
Worse, different implementations faced with the same set of hard choices
about which spec to violate in order to concurrently support two dialects
might not make the same choices, leading to even more gratuitous
incompatibility.
ANSI's position in ISO that we are not trying to legislate the meaning of
-the- LISP dialect would be weakened.
Benefits:
Needless incompatibility would be avoided in a variety of situations.
Aesthetics:
Failing to specify the home package of symbols in the LISP and CL packages
seems unaesthetic because it appears to diminish print/read invertability,
but as observed above, that case is rare.
Failiing to specify a way in which lisp dialects can be co-resident is also
unaesthetic because in practice implementors with a need to do this will do
so whether the standard allows them or not, and it will be a source of
severe divergence among implementations.
Discussion:
Symbolics Genera offers two co-resident dialects of Lisp: Zetalisp and
Symbolics Common Lisp. The Symbolics Cloe development environment adds
a third co-resident dialect, making an environment in which two differing
Common Lisp dialects (Symbolics Common Lisp and Cloe) must cooperate.
Already in Cloe it is not possible for the home package to contain
package "LISP" since Cloe's concept of what the "LISP" package is differs
from Genera's concept of what the "LISP" package is, yet they are forced
by efficiency constraints to share the same symbol. It is Pitman's belief,
based on extensive experience with Cloe, that failure to pass this proposal
(or something very like it) will lead to all sorts of trouble for Common
Lisp users and implementors down the road.
Pitman strongly supports this proposal.
Additional comments:
Is it permissible for implementations to define
"LISP" as a nickname for this package, for the
sake of backward compatibility?
Anyone wanting to make LISP a nickname could just as well create a LISP
package which simply imported the appropriate symbols from the CL package.
With only modest additional effort, they could try to make new symbols where
feasable (especially for most functions) and put borrowed functions plopped
in their function cells. The amount of additional storage is small (compared
to implementing a whole new lisp), but it would leave open the possibility for
users upgrading the level of compatibility without hurting the core
system. eg, if I wanted APPEND to signal an error on dotted lists, I
would not consider redefining the system's APPEND for fear of breaking
the world, but if they told me that nothing depended on LISP other than
compatibility code, I might feel ok about redefining (or doing
SHADOWING-IMPORT of LISP:APPEND on a per-implementation basis (with
appropriate sharp conditionals)) in order to up the level of
compatibility.
In fact, though, my guess is that implementations which are not going to
do a serious compatibility effort are better off leaving the package
missing. My experience has been that customers are often happier growing
their own compatibility [or getting it from a public library] than being
stuck with something which really doesn't do what they want but which
seals off the place in the namespace which they needed in order to do
their own thing.
∂11-Jan-89 2008 X3J13-mailer Ballot (finally)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jan 89 20:04:05 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa01484; 12 Jan 89 3:54 GMT
Date: Thu, 12 Jan 89 03:57:03 GMT
Message-Id: <18811.8901120357@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Ballot (finally)
To: masinter.pa@xerox.com, x3J13@sail.stanford.edu
In-Reply-To: masinter.pa@com.xerox's message of 12 Dec 88 18:16 PST
Cc: richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
rhr%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
This is the official vote for the University of Edinburgh.
Y ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Y ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Y CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Y CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Y DECLARATION-SCOPE:NO-HOISTING
N DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
NO brings LET closer to application of LAMBDA-expressions.
The "en passant" capture in LIMITED is a bit too stange.
A DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
N DECLARE-TYPE-FREE:ALLOW
Y DECLARE-TYPE-FREE:LEXICAL (v 9)
Version 8, 7-Dec-88, Mailed 9-Dec-88
LEXICAL is consistent with SYMBOL-MACROLET-DECLARE:ALLOW.
A DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Y DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
I DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
If ammended as suggested by Kim Barrett.
Y DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Y DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
A DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Y DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
I voted yes beacuse subforms can be dotted, but I don't really like it.
I EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
If the EQUALP problems are cleared up.
N EXIT-EXTENT:MINIMAL
Y EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
Y EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
Y FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
I prefer to retain a name for the non-fixnums.
I favor retaining FIXNUM because it allows me to do a useful thing
(request integers that can be handled with a certain degree of
efficiency) in the same way in all implementations that provide it.
Note that there is a large class of implementations in which fixnums
are large enough to contain the address part of a pointer and so
can be used in every case where I count objects or index structures.
Again, I prefer to be able to use the same declaration in all of these
implementations.
Not all code is meant to be portable to all Common Lisps.
Moreover, if efficiency is my concern, an explicit subrange is
actually less portable, because I cannot specify its representation.
Y FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Y FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
Y FUNCTION-COMPOSITION:NEW-FUNCTIONS
I FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
C-AND-A if NEW-FUNCTIONS fails.
Y FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Y FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
I think the explanation of exactly what changes could be clearer,
and I am not completely sure I understand it.
Y FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Y GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
I agree with the remark that the tests imply EQ will hold
when that is not actually guaranteed.
N HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
I might be convinced to change my mind, but right now I think this
proposal is premature. There is nothing very like it in the rest
of CL, and it would make more sense to wait until the need for it
has been more firmly established. I am also bothered by the use
of MACROLET. Is it really the case that functions declared INLINE
would not be enough for optimization?
Y HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
I think this is an important clarification even though it may
not lead to extensive changes in practice. I disagree with the
suggestions that the proposal be shortened; but if it cannot
gather enought support as-is, it might be rearranged so as to
stress issues of correct use, such as the effects of destructive
operations on keys.
Moreover, an explanation at this level of detail removes one of
the most common objections to allowing :test arguments outside
the standard set, if accompanied by appropriate key transformation
functions, namely that the necessary constraints must first be
understood. It may therefore encourage implementors to provide
that extension, something I would like to see.
Y HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
It seems to me that SXHASH is not quite suitable for use with
EQUALP, and so I would like the key transformation function that
is used with EQUALP to made available to the user.
Y IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
At first I thought I'd make this conditional on DEFPACKAGE passing;
then I decided MAKE-PACKAGE would suffice.
Y LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
Y LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
Y LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
N MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
I would like any dependency on implementation-specific extensions
to be explicit.
Y MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
A NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
NTH-VALUE does not complete the set of operations on multiple values
because it extracts only one value, so I do not think it is needed
for the sake of completeness.
Y PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
A PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Y PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
I can understand why someone might find the need for :UNSPECIFIC
in Unix unclear, but I think that is because it is not clear what
filenames would be parsed as pathnames with :UNSPECIFIC type [*];
:UNSPECIFIC is nonetheless useful for building pathnames directly
when you know which case you want and need a way to specify it.
[*] Does a name without "." parse as type NIL or :UNSPECIFIC?
Different Unix programs use different conventions. Some are
willing to merge in a type field, others, such as the C compiler,
leave names as-is. So the "right" answer may vary.
Y PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
Y PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
Y PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
Under this proposal, special proclamations establish a default for
a name but, because of the lexical declaration, no longer force it
to be special everywhere. It also allows the programmer to say
that a global name is intended as a variable (i.e., references to
it are not spelling mistakes) without proclaiming it special. I
think these are important changes that should be preserved even if
this proposal fails. Another important feature is that LG references
to global variables can be fast in deep-bound implementations (since
L "searches" can be compiled away) while DG references (the only
global variables we have now) first have to look in D. Finally,
the current semantics are subtly confusing, because the specialness
of global variables occasionally shows through. For all of these
reasons, I support this proposal.
I think the most controversial change is the introduction of a
separate global environment, where before the only globals were
effectively just the global end of the dynamic env. Most of the
implementation complexity stems from this change, and it is likely
that it lies behind most objections.
A reasonable fallback, if this proposal does not pass, would be
to say that variables that are proclaimed lexical can never by
given dynamic bindings. That is, the global value would be taken
after searching L or D but not both and so would effectively be
an extension of the L or D env, case by case. This would be
somewhat unfortunate, because local lexical bindings for names
proclaimed special would still make sense (because they could be
declared lexical) but we wouldn't allow local special declarations
for names proclaimed lexical. The full proposal is better.
Y RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Y RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
A REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
N REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y REST-LIST-ALLOCATION:MAY-SHARE
N REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
NEWLY-ALLOCATED is cleanest, but may be too disruptive.
Y RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
Y ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
I suppose we might, instead, allow anything other than T or NIL.
That has a bit of a ternary feel to it.
[The following are mutually exclusive]
N SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
N SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
I am not yet happy with either proposal. The first seems nicer
but complicates the semantics of CL at a rather central point
and introduces nonorthogonality by allowing (SETF name) in
FUNCTION but not as the car of a form. The second looks like
a rather desperate attempt to avoid the first. Is there some
way to avoid writing names like setf:3.bar.middle.ref in the
"local function" example? (It's the 3 that looks worst.)
Y SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Y STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Y STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T ="true")
How many type names do not have corresponding predicates?
Y STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==STREAM-LINE-WIDTH
LINE-POSITION ==STREAM-LINE-POSITION
PRINTED-WIDTH ==STREAM-STRING-WIDTH
Y SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
If MEMBER, AND, OR, and NOT can be handled, I'd be happier if they
were handled. This proposal is nonetheless better than the status quo.
Y SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Goes best with DECLARE-TYPE-FREE:LEXICAL (rather than no DECLARE-
TYPE-FREE or :ALLOW). It would be unreasonable to pass this and
reject the other.
Y SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
I TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
Contents should be valid forms (including self-evaluating) or valid
tags. Duplicate tags should be an error (as in the proposal).
Y TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
Y TEST-NOT-IF-NOT:FLUSH-ALL
Y TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
I don't oppose "depreciation" instead of deletion.
The functionality of REMOVE-IF-NOT should be preserved under
another name. Perhaps DELETE-IF-NOT too.
Y TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Y UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Y VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂11-Jan-89 2237 X3J13-mailer Issue: SPECIAL-TYPE-SHADOWING (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 22:37:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:36:27 PST
Date: 11 Jan 89 22:35 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: SPECIAL-TYPE-SHADOWING (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-223627-11614@Xerox>
!
Issue: SPECIAL-TYPE-SHADOWING
References: CLtL pages 156, 158
Related issues: DECLARE-TYPE-FREE
Category: CLARIFICATION
Edit history: Version 1, 04-Nov-88 by David Gray
Problem description:
A Common Lisp user raised the question of whether something like the
following is legal:
(PROCLAIM '(TYPE NUMBER *X*))
(DEFVAR *X*)
(DEFUN FOO ()
(LET ((*X* T))
(DECLARE (TYPE SYMBOL *X*))
(BAR)))
Page 156 of CLtL says that a proclamation is "always in force unless
locally shadowed" and page 158 says type declarations "only affect
variable bindings", which might be interpreted to mean that the DECLARE
locally shadows the PROCLAIM. However, that interpretation would make
the global type proclamation useless because it could not be relied on
when compiling a function such as BAR.
Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
Clarify that if there is a local type declaration for a special
variable, and there is also a global type proclamation for that same
variable, then the value of the variable within the scope of the local
declaration must be a member of the intersection of the two declared
types.
Rationale:
Some restriction on local type declarations for special variables is
needed in order for type proclamations to be meaningful. The wording
used here was chosen for consistency with proposal DECLARE-TYPE-FREE.
Current practice:
The TI, Symbolics, and Lucid implementations do not report any error
on the example above, but it isn't clear that they really do anything
with type declarations for special variables anyway.
Cost to Implementors:
This is unlikely to require a change in any current implementation.
Cost to Users:
Anyone who has written code like the example above would have to
modify it if compilers started enforcing this restriction.
Cost of non-adoption:
A minor ambiguity in the language specification that could confuse
users.
Performance impact:
None.
Benefits:
A clearer definition of the meaning of type declarations for special
variables.
Discussion:
This is obviously very closely related to issue DECLARE-TYPE-FREE, but
this is an ambiguity in the existing language that should be resolved
even if the language extension of proposal DECLARE-TYPE-FREE is not
accepted. Note also that DECLARE-TYPE-FREE makes no mention of type
proclamations.
Other possible resolutions of the ambiguity would be to either rule
out use of local type declarations for special variables, or to say
that the local type must be a subtype of the global type.
∂11-Jan-89 2233 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 22:33:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:32:40 PST
Date: 11 Jan 89 22:30 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-223240-11606@Xerox>
A more general version of this was introduced by Touretzky but
it was rejected by X3J13. This has much more restricted proposal.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky (option GENERALIZED)
28-Apr-87, Version 2 by Pitman (add option MODIFIED)
26-Oct-87, Version 3 by Masinter (remove MODIFIED)
11-Nov-87, Version 4 by Masinter (respond to comments)
05-Feb-88, Version 5 by Masinter
06-Oct-88, Version 6 by Pitman
(revert to version 2, flush GENERALIZED option
-- which was rejected by X3J13 -- and resurrect MODIFIED)
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on certain arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Extend the definitions of sequence functions that either return their
argument sequences, return sequences which are the same shape as their
argument, or return non-sequences so that they also allow arrays iff
their action is conceptually independent of the shape of the array.
The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions.
These other functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, etc., or else they can build displaced vectors by hand and
pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting
ways without committing us to a theory of how arrays and sequences
relate that everyone may not be happy with right now.
Cost to Implementors:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Cost to Users:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This extends certain existing sequence functions to allow arrays
as arguments in a fairly non-controversial way, leaving aside the
larger issue of whether and how to generalize the other sequence
functions.
Current Practice:
Probably no one implements this now.
Discussion:
A more general version of this was introduced by Touretzky but
it was rejected by X3J13.
The members of the Cleanup committee expressed interest in the ideas
behind this proposal but weren't sure they could accept it in the
proposed form. A rewrite to separate some of the issues more clearly
was solicited. Rees suggested this subset of Tourtezky's proposal
might be interesting.
Note that the function REDUCE is in a gray area. Many of its uses
are not position-dependent, but some are. The same argument might
be made about FIND. If people felt strongly, these too could be
extended either by fudging the conservative rule or by explicit
special case(s), but they have been omitted to be conservative.
∂11-Jan-89 2316 X3J13-mailer Issue: THE-AMBIGUITY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:16:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 23:14:58 PST
Date: 11 Jan 89 23:14 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: THE-AMBIGUITY (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-231458-11647@Xerox>
This issue has two proposals.
!
Forum: cleanup
Issue: THE-AMBIGUITY
References: THE (page 161)
Category: CLARIFICATION
Edit history: 21-Oct-88, version 1 by Rees
11-Jan-89, version 2 by Masinter (fix typos)
Problem description:
CLtL does not explicitly say whether the type specifier in a THE
form may be any type specifier or must be a type specifier suitable
for discrimination. Although THE is decsribed as a "declaration"
form, some CL implementations have assumed that the specifier must
be for discrimination, and disallow e.g.,
(THE (FUNCTION (T T) CONS) #'CONS)
We should either say that the implementations are right, or
explicitly say that they are wrong, since this case is easily
overlooked.
Proposal (THE-AMBIGUITY:FOR-DECLARATION):
Clarify that the type specifier in
(THE type exp)
may be any valid type specifier. In the case that exp returns one
value and type is not a VALUES type specifier, (THE type exp) is
equivalent to
(LET ((g exp))
(DECLARE (TYPE type g))
g)
where "g" is a gensym.
Proposal (THE-AMBIGUITY:FOR-DISCRIMINATION):
Clarify that the type specifier in
(THE type exp)
must be a valid type for discrimination, as for TYPEP, or it must
be of the form (VALUES type*) where type* are all valid for discrimination.
Current practice:
The Symbolics Genera and VAX LISP V2.2 interpreters signal errors for
(THE (FUNCTION (T T) CONS) #'CONS),
but this may not be intentional. CLtL would seem to allow it.
Test case:
(THE (FUNCTION (T T) CONS) #'CONS),
should return the CONS function under FOR-DECLARATION,
and should be an error under FOR-DISCRIMINATION.
Cost to implementors:
Trivial cost for THE-AMBIGUITY:FOR-DISCRIMINATION; this is a compatible
restriction.
For THE-AMBIGUITY:FOR-DECLARATION, implementations that do not
already allow arbitrary type specifiers but which want to check that
the type in a THE is satisfied would have to create an internal
version of TYPEP which could manage not to signal invalid-type-specifier
errors in those situations where TYPEP would because the type is a
declaration-only one.
Cost to users:
Users of implementations that support THE-AMBIGUITY:FOR-DECLARATION
might have to remove or change some uses of THE in their code if the
opposing alternative is adopted.
Benefits:
Either way, an ambiguity in the language specification would be clarified.
Aesthetics:
THE-AMBIGUITY:FOR-DECLARATION would seem to be more consistent with
DECLARE and with the intent of THE, which is supposed to be a way to
provide information for documentation and for the benefit of compilation.
Discussion:
Rees supports THE-AMBIGUITY:FOR-DECLARATION.
Appropriate error situation terminology must be chosen for the
situation that a THE declaration (or other declaration) is
unsatisfied, but that must be done regardless of this proposal.
This proposal would suggest that a function should be added to CL to
do the checking that THE would want to do:
(PROBABLY-TYPEP object type-spec)
[terrible name of course] returns multiple values a la SUBTYPEP: T T
if the object definitely has the type, NIL T if it definitely
doesn't, and T NIL (or NIL NIL?) otherwise. Assuming that an
interpreted THE-expression actually checks types, you could almost
define this function using the condition system and EVAL. (Ugh!)
Without PROBABLY-TYPEP, a meta-circular interpreter is more
difficult to write.
If a suitable name was found for this function, the additional
functionality could be suggested as an independent proposal, since
regardless of the outcome of this issue, the functionality is still
useful for checking DECLARE's.
Various implementation mechanisms were discussed for dealing
with THE checking.
Are there any remaining type specifiers beyond the list form
of the FUNCTION type that differ between "declaration" and
"discrimination"?
"I support FOR-DECLARATION. Lucid CL has the same bug in
the interpreter as the others (a "bug" assuming FOR-DECLARATION).
TYPEP is used to check the legality of the type specifier in THE."
In considering possible ways in which the type-checking logic
for THE and DECLARE might work, don't forget things like
(the (not (function (t t) integer)) 7),
which you would want to signal an error. I don't think this can be
done with only TYPEP and conditions.
∂11-Jan-89 2346 X3J13-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:46:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 23:45:32 PST
Date: 11 Jan 89 23:45 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-234532-11838@Xerox>
It was believed that this issue might be controversial.
!
Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
References: 5.1.2 Variables (CLtL pp55-56),
Slots (88-002R, p1-10)
Category: CHANGE
Edit history: 29-Nov-88, Version 1 by Pitman
Problem Description:
CLtL does not specify what happens if you attempt to call a named function
which is in fact undefined. In most implementations, it would be devastating to
actually jump to code which you had not verified to be a function, so this error
should be easily caught -- yet, CLtL does not guarantee that an error will be
signalled even in the safest, least fast OPTIMIZE settings.
CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."
CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
signals an error."
CLOS and CLtL are not in agreement on their treatment of unbound variables.
CLtL is very weak in that it guarantees no support for reliably detecting
and signalling an error when the error situation occurs, even in the safest,
least fast OPTIMIZE setting.
CLOS is very strong in that it forces detection of the error in all
situations -- even in the fastest, least safe OPTIMIZE setting.
The disparate positions for treatment of variables and slots should be
reconciled, either by finding a compromise or by justifying the apparent
inconsistency. The final story should explain function references as well.
Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):
Define that reading an undefined function, an unbound variable, or
an unbound slot must be detected in the highest safety setting,
but the effect is undefined in any other safety setting. That is,
- Reading an undefined function should signal an error.
- Reading an an unbound variable should signal an error.
- Reading an unbound slot should invoke the function SLOT-UNBOUND.
By ``reading an undefined function'' in the above, we mean to
include both references to the function using the FUNCTION
special form, such as F in (FUNCTION F) and references to the
function in a call, such as F in (F X).
For the case of INLINE functions (in implementations where they are
supported), it is permissible to consider that performing the inlining
constitutes the read, so that an FBOUNDP check need not be done at
execution time. Put another way, the effect of FMAKUNBOUND of a function
on potentially inlined references to that function is undefined.
Specify that the type of error signalled when an undefined function
is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
UNDEFINED-FUNCTION condition is initialized to the name of the
offending function.
Specify that the type of error signalled when a unbound variable
is detected is UNBOUND-VARIABLE, and that the NAME slot of the
UNBOUND-VARIABLE condition is initialized to the name of the
offending variable.
Introduce a new condition type, UNBOUND-SLOT, which inherits from
CELL-ERROR. This new type has an additional slot, INSTANCE, which
can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.
Specify that the type of error signalled by the default primary
method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
and that the NAME slot of the UNBOUND-SLOT condition is initialized
to the name of the offending variable, and that the INSTANCE slot
of the UNBOUND-SLOT condition is initialized to the offending instance.
Test Case:
(PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
(DEFUN FOO () X)
(FOO)
>>Error: The variable X is not bound.
...
Rationale:
This makes it easier to treat slots like variables.
This makes it possible to better rely on an unbound variable error being
signalled when one has occurred.
This makes it possible to compile out useless error checking in CLOS
code where the code is debugged and the checking is redundant.
For the case of undefined functions, blindly jumping to an undefined
function is an incredibly dangerous thing to do. Every implementation
should guarantee at least some way to get error checking of undefined
functions.
Current Practice:
Until recently, Symbolics Cloe did not ever signal an error on unbound
variable, even in the safest case. The excuse was that this was a CLtL
didn't require it, but it was sometimes an impediment to debugging.
Some benchmarks for Symbolics Cloe (which currently only claims to
implement New Flavors, not CLOS) could be faster if checking for unbound
instance variables could be optimized away.
Symbolics Genera doesn't care about safety issues in variable access
because the check can be done by microcode.
Cost to Implementors:
This change does not force a change to any current implementation, except
those which do not yet signal unbound variable or undefined function errors
even in the safest setting.
Cost to Users:
This checking might slow down some code which is written for the safest
setting yet does not need this check.
Any implementation-specific code which depended on these references not
signalling would be broken. Such code was not portable, of course.
Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
settings would be broken. The amount of such code at this point is likely
to be little or none. If such cases did exist, local or global changes to
safety settings would correct the problem (at some cost in speed).
Cost of Non-Adoption:
Some important error checking would not occur.
Some important optimizations could not be done.
The language would seem internally less consistent.
Benefits:
The costs of non-adoption would be avoided.
Aesthetics:
This would regularize things a little.
Discussion:
Pitman thinks this would be a good idea.
∂11-Jan-89 2357 X3J13-mailer Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:57:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 23:55:59 PST
Date: 11 Jan 89 23:55 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-235559-11843@Xerox>
Several people endorsed a proposed change from Kim Barrett
to add &ALLOW-OTHER-KEY.
This version does that, and also adds a possibly controversial
feature of allowing arguments that don't name slots but
are only used in the computation of other (default or &AUX)
values.
For discussion.
!
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
8-Jan-89, Version 3, Masinter
Problem description:
Currently, DEFSTRUCT constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs
and the &ALLOW-OTHER-KEYS token in addition to the &OPTIONAL,
&REST and &AUX arguments already allowed. Keyword arguments default
in a manner similar to that of &OPTIONAL arguments: if no default
is supplied in the lambda-list then the slot initform is used;
otherwise the slot is not initialized -- its initial value is
undefined.
If keyword arguments of the form ((key var) [default [svar]])
are specified, the "slot name" is matched with VAR (and not KEY).
Additional arguments that do not correspond to slot names but
are merely present to supply values used in subsequent initialization
computations are allowed.
Examples:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
In the definition:
(defstruct (frob (:constructor create-frob
(a &key (b 3 have-b) (c-token 'c)
(c (list c-token (if have-b 7 2))))))
a b c)
the c-token argument is used merely to supply a value used in the
initialization of the c slot. The "supplied-p" arguments of
keyword arguments might be of this form.
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Many implementations signal an error if given &KEY arguments or
arguments that are not slot names. The latest version of IIM Common
Lisp allows &KEY arguments in this manner. Envos Medley
(Xerox Common Lisp) implements the proposal.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
Version 2 of this proposal was on the January 1989 ballot.
----- End Forwarded Messages -----
∂12-Jan-89 0015 X3J13-mailer Issue: EQUAL-STRUCTURE, (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 00:14:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:12:56 PST
Date: 12 Jan 89 00:12 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE, (Version 6)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-001256-11866@Xerox>
Please see the Additional Comments at the end. Several people
noted problems with Version 5.
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
11-Jan-89, Version 6 by Pitman (attempt EQUALP correction)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:MAYBE-STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or data types
other than the ones explicitly specified in CLtL.
Type EQUAL Behavior EQUALP Behavior
Number uses EQL uses =
Character uses EQL uses CHAR-EQUAL
Cons descends descends
Bit-Vector descends descends
String descends descends
Pathname magic per CLtL same as EQUAL
Structure uses EQ descends
other Array uses EQ descends
Instance (Standard-Object) uses EQ descends
Hash-Table uses EQ uses EQ
Other uses EQ uses EQ
Note that the order of this table is in some cases important, with upper
entries taking priority over lower ones.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
!
Additional Comments to Version 6:
Version 6 attempts to fix some of the problems noted in Version 5.
There are still some open questions. Only the "Proposal"
part has been changed since Version 5; some of the costs,
benefits & other discussion is now incorrect.
Kent says:
Please read this very carefully before voting in favor of it.
There were a lot of Yes votes for the last version, which I think
had some serious bugs in it. This would be a very bad issue for
us to screw up.
Things that might need special attention:
- Moon contends that standard practice in Symbolics Lisp is
for instances to be compared using EQ under EQUALP, not by
descending. There may be performance issues involved here.
Some agreement needs to be reached.
- Neither the previous version of the proposal nor CLtL was
clear on what happens to pathnames under EQUALP. This showed
up when I converted the presentation below. That issue should
be addressed as well.
Hopefully if this version of the proposal isn't something you want to
vote yes for, at least it's in a suitable form for easy line-item
changes interactively in the meeting.
∂12-Jan-89 0104 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:04:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 01:02:45 PST
Date: 12 Jan 89 01:02 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-010245-11915@Xerox>
There was debate over the meaning of the phrase
"status quo" an whether this proposal reflected it.
It wasn't a very useful debate. I hope we can avoid more
of it.
!
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289)
Category: CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
Some of the original Common Lisp designers assert that the
:ADJUSTABLE option exists in order to allow a user to select
between getting adjustable and non-adjustable arrays.
Others of the original Common Lisp designers assert that the
:ADJUSTABLE option existed to permit implementations in which
making all arrays adjustable was very expensive to make some
arrays not adjustable.
The former camp therefore believes that :ADJUSTABLE NIL means
that the array MUST be non-adjustable. The latter camp believes
that :ADJUSTABLE NIL means that the array MIGHT be non-adjustable.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' Although this sentence
is slightly ambiguous (one might argue that :ADJUSTABLE NIL
involves supplying the :ADJUSTABLE option), it is generally
interpreted to mean that ``... with :ADJUSTABLE T.''
One problem is that since ADJUSTABLE-ARRAY-P does not predicate
whether the :ADJUSTABLE option was provided, then
ADJUSTABLE-ARRAY-P is not an appropriate predicate in all
implementations to determine whether an array is adjustable.
Technically, :ADJUSTABLE NIL could create and adjustable array
(one for which ADJUSTABLE-ARRAY-P returns true), and yet
ADJUST-ARRAY might refuse to adjust it (if it had recorded a
separate bit saying whether :ADJUSTABLE T had been specified
and used that bit for ADJUST-ARRAY). Fortunately, this problem
has not been observed to occur in practice, but it is present
in principle.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY. That expectation is violated by
legitimate implementations, since it is permissible for an
implementation to create an adjustable array even though it has
not been asked for, and since calling adjust array on such an
array "is an error" (and hence the behavior can be extended).
This perceived lack of error checking may become a legitimate
portability error to someone who has debugged his code in a
an implementation where :ADJUSTABLE NIL arrays might still be
adjustable and then tried ported his code to an implementation
which is more conservative in its interpretation.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY):
Define that omitting the :ADJUSTABLE option to MAKE-ARRAY or
explicitly supplying :ADJUSTABLE NIL may not guarantee a
non-adjustable array.
Define that ADJUSTABLE-ARRAY-P -must- be true of an array created
using :ADJUSTABLE T.
Define that ADJUSTABLE-ARRAY-P -might- be true of an array created
with no :ADJUSTABLE option or with :ADJUSTABLE NIL, but that it
-might- return false.
Clarify that the implication of the above is that saying that an
array A "is adjustable" means that (ADJUSTABLE-ARRAY-P A) => true.
Further clarify that the adjustability of an array has no necessary
relation to any value was given (or not given) as the :ADJUSTABLE
option in the call to MAKE-ARRAY which created the array A.
Clarify that there is no portable way to create a non-adjustable
array (that is, an array for which ADJUSTABLE-ARRAY-P is
guaranteed to return false).
Change the description of ADJUST-ARRAY to say that if an attempt
is made to adjust an array which is not adjustable (that is, an
array for which ADJUSTABLE-ARRAY-P would return false), an error
will be signalled.
Clarify that this legitimizes ADJUSTABLE-ARRAY-P as an appropriate
predicate to determine whether ADJUST-ARRAY will reliably succeed.
Rationale:
This effectively makes the status quo explicit.
While changing this to a tighter interpretation would be desirable, some
implementations have suggested that such a change might be very expensive
or impossible given their existing data storage layouts.
Although technically the changes to ADJUST-ARRAY are incompatible changes
from the spec, it's not believed that there are any implementations which
deviate, so we're still categorizing this as a clarification.
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic.
Discussion:
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂12-Jan-89 0117 X3J13-mailer Issue: APPEND-ATOM (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:16:56 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 01:15:28 PST
Date: 12 Jan 89 01:09 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: APPEND-ATOM (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-011528-11925@Xerox>
!
Issue: APPEND-ATOM
References: APPEND (p268)
Issue APPEND-DOTTED
Category: CHANGE/CLARIFICATION
Edit history: Version 1 06-Dec-88 by Steele
Problem Description:
The issue APPEND-DOTTED, as passed by X3J13, contains a minor technical
flaw: it can be construed as leaving undefined the case where an argument
to APPEND other than the last is an atom. The relevant paragraph of that
issue proposal is:
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Here is the nit: the use of "i.e." leads one to believe that the
only degenerate case defined is that where the argument is NIL.
I suspect that "e.g." was intended, so as to make all atomic objects
ignored in other than the last argument.
Proposal (APPEND-ATOM:IGNORE):
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be
a non-list.
Proposal (APPEND-ATOM:ERROR)
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that a value of
NIL is treated as an empty list and therefore effectively ignored, and
any other atom is an error. Point out that in this situation, if the
last argument is a non-list, the result of APPEND or NCONC can be a
non-list.
Examples:
Under APPEND-ATOM:IGNORE:
(APPEND '(a b) 'MOOSE '(c . d)) => (a b c . d) ;Proposed
(NCONC '(a b) 'MOUSSE '(c . d)) => (a b c . d) ;Proposed
(APPEND 'GUACAMOLE 17) => 17 ;Proposed
(NCONC 'SAUERKRAUT 17) => 17 ;Proposed
Under APPEND-ATOM:ERROR these cases would all be errors.
Rationale:
APPEND-ATOM:IGNORE makes a boundary case (a "zero-length dotted list")
consistent with other cases handled by the proposal APPEND-DOTTED:REPLACE.
APPEND-ATOM:ERROR would at least resolve a possible ambiguity.
Current Practice:
Lucid Lisp, KCL, and Symbolics Common Lisp all signal an error in both
interpreted and compiled code.
Cost to implementors:
Technically, the change for APPEND-ATOM:IGNORE should be relatively
small for those implementations which don't already implement it.
However, implementations which have microcoded APPEND or NCONC
incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only
NIL when SAFETY is 0. In this case, depending on implementation details,
requiring an ATOM check rather than a NULL check may slow things down.
Cost to users:
Each proposal is upward compatible.
Benefits:
Since dotted lists are allowed as a non-last argument, readers will
probably assume that the boundary case of a zero-length dotted list
(that is, an atom) also works, something that doesn't appear to be
guaranteed by a strict reading. Proposal APPEND-ATOM:IGNORE would
happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
The downside of APPEND-ATOM:IGNORE is that APPEND is supposed to
operate on lists, and it is mildly offensive to let it accept atoms,
and worse yet to ignore them. Furthermore, a certain amount of useful
error checking may be lost.
Discussion:
Guy Steele supports proposal APPEND-ATOM:IGNORE, but with some qualms.
He raises it mainly because of the possibility that
APPEND-DOTTED:REPLACE was not worded exactly as intended.
∂12-Jan-89 0121 X3J13-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:21:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 01:20:02 PST
Date: 12 Jan 89 01:19 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-012002-11939@Xerox>
There has been discussion on this issue not reflected in the
writeup. Some of the cost/benefit analysis misses some of the
Costs to Users, for example.
!
Status: DRAFT
Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
Forum: Cleanup
References: Back quote (pp349-351)
Category: CLARIFICATION/CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Problem Description:
The consistent description of backquote has been disrupted by
recent changes in the semantics of APPEND.
The description at the bottom of p350 suggests that
`(foo ,@bar) can be legitimately interpreted as any of
#1: (list* 'foo bar)
#2: (append (list 'foo) bar)
#3: (append (list 'foo) bar '())
Unfortunately, issue APPEND-DOTTED has disrupted the equivalences
here because if BAR holds a dotted list, #1 and #2 are the same (they
preserve the `dotted cdr'), but #3 is different (it replaces the
`dotted cdr' with NIL). Under CLtL, a dotted list given to APPEND was
an error, so this case did not come up. But since ANSI CL will not make
this an error, this ambiguity must be resolved.
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:DIVERGENT):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN '()).
Any top-level list structure of the object xN will be copied in the
result, replacing (CDR (LAST xN)) with NIL (or replacing xN itself
with NIL if xN is an atom and issue APPEND-ATOM passes).
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Notes:
Note well that this has implications which go beyond dotted lists.
Currently, `(FOO ,@X) may be implemented by either
(LIST* 'FOO X)
or (APPEND (LIST 'FOO) X '())
or (APPEND (LIST 'FOO) X)
A consequence of the proposals above is to distinguish between
the two APPEND cases, forcing changes in the side-effect behavior
of backquoted structures currently exhibited by some implementations.
Test Cases:
;; Issue #1: Non-side-effect treatment of dotted lists.
(LET ((DOTTED (LIST* 'A 'B 'C)))
(VALUES `(FOO ,@DOTTED)
`(FOO . ,DOTTED)))
=> (FOO A B), (FOO A B . C) ;under proposal DIVERGENT
=> (FOO A B . C), (FOO A B . C) ;under proposal INTERCHANGEABLE
;; Issue #2a: Side-effects
;; Sometimes called the ``Standard Backquote Screw''
;; Structure is unintentionally shared.
(LET ((TAIL1 (LIST 'A 'B 'C))
(TAIL2 (LIST 'A 'B 'C)))
(FLET ((GET-XABC-COMMA-ATSIGN () `(X ,@TAIL1))
(GET-XABC-DOT-COMMA () `(X . ,TAIL2)))
(LET ((TEMP1 (GET-XABC-COMMA-ATSIGN))
(TEMP2 (GET-XABC-DOT-COMMA)))
(SETF (CADDR TEMP1) 'Z)
(SETF (CADDR TEMP2) 'Z)
(VALUES TEMP1 (GET-XABC-COMMA-ATSIGN)
TEMP2 (GET-XABC-DOT-COMMA)))))
=> (X A Z C), (X A B C), (X A Z C), (X A Z C) ;under proposal DIVERGENT
=> (X A Z C), (X A Z C), (X A Z C), (X A Z C) ;under proposal INTERCHANGEABLE
;; Issue #2b: Side-effects
;; Sometimes called ``Inverse Backquote Screw''
;; Structure is unintentionally copied.
(LET ((VAR 'X)
(VAL '7)
(THE-SETQ-TAIL (LIST NIL NIL)))
(LET ((COMMA-ATSIGN `(SETQ ,@THE-SETQ-TAIL))
(DOT-COMMA `(SETQ . ,THE-SETQ-TAIL)))
(SETF (CAR SETQ-TAIL) VAR)
(SETF (CADR SETQ-TAIL) VAL)
(VALUES COMMA-ATSIGN DOT-COMMA)
=> (SETQ NIL NIL), (SETQ X 7) ; under proposal DIVERGENT
=> (SETQ X 7), (SETQ X 7) ; under proposal INTERCHANGEABLE
Rationale:
This clarifies an ambiguity in the description of the language which was caused
by issue APPEND-DOTTED and APPEND-ATOM.
Although CLtL tries not to specify the sharing and side-effect implications
of backquote, there is no really principled reason for its failure to do so.
In practice, the failure to do so leads to gratuitous portability barriers.
Current Practice:
Currently, the definition of APPEND is such that it would be an error
to pass it a dotted list, so there is no possibility of discrepancy
because the interesting case is an "is an error" case.
Cost to Implementors:
Very small. Some implementations would need to change how they implement
backquote. Presumably this is a very isolated change.
Cost to Users:
Technically, none. Existing code is not supposed to rely on the distinctions
discussed here. The distinction will only be meaningful when ANSI CL goes into
effect.
In practice, since some implementations will have to change incompatibly,
some code which accidentally relies on the current behavior will break.
However, once such code is fixed, it will be more portable because
implementations will not gratuitously diverge.
Cost of Non-Adoption:
An ambiguity would exist in the language, confusing both users and
implementors.
Benefits:
An ambiguity would be removed.
Some gratuitous barriers to portability would be removed.
Aesthetics:
Proposal DIVERGENT makes things slightly harder to learn.
Both proposals make things more predictably portable, which presumably
has some aesthetic appeal.
Discussion:
Pitman thinks that either of these choices will be better than the status quo.
Given that some people already think of ., and ,@ as interchangeable and merely
a matter of personal style, it would be better to go with option INTERCHANGEABLE.
∂12-Jan-89 1413 X3J13-mailer Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 14:13:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 13:58:56 PST
Date: 12 Jan 89 13:58 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-135856-13358@Xerox>
This Issue has too many Proposals. We've not had the
time to narrow them down.
!
Status: DRAFT
Forum: Cleanup
Issue: CLOSE-CONSTRUCTED-STREAM
References: Close (CLtL p. 332), WITH-OPEN-STREAM
(CLtL p 330), make-synonym-stream, make-broadcast-stream,
make-concatenated-stream, make-two-way-stream,
make-echo-stream, make-string-input-stream,
make-string-output-stream, with-input-from-string,
with-output-from-string
Related issues: CLOSED-STREAM-OPERATIONS
Category: Clarification/Change
Edit history: Masinter, 6-Jan-89, Version 1
Masinter, 12-Jan-89, Version 2
Problem description:
First some terminology:
A "composite" stream is one created with MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM,
MAKE-ECHO-STREAM.
The "constituents" of a composite stream are the streams it points to:
the SYMBOL-VALUE of the symbol given to MAKE-SYNONYM-STREAM
the streams given to MAKE-BROADCAST-STREAM or MAKE-CONCATENATED-STREAM
the input-stream and output-stream given to MAKE-TWO-WAY-STREAM or MAKE-ECHO-STREAM.
A "constructed" stream is either a composite stream or one created with
MAKE-STRING-INPUT-STREAM, MAKE-STRING-OUTPUT-STREAM, WITH-INPUT-FROM-STRING,
WITH-OUTPUT-FROM-STRING.
The function "CLOSE" is currently described in 21.3, which starts "This
section contains discussion of only those operations that are common to all
streams." This would seem to imply that they apply to constructed streams.
The definition of CLOSE "The argument must be a stream. No further input/output
operations may be performed on it. ... " It further states "... and it is
permissible to close an already closed stream."
However, the behavior on the constructed streams is not well defined, and
implementations (apparently) differ.
Proposal (CLOSE-CONSTRUCTED-STREAM:IS-ERROR):
It "is an error" to call CLOSE on a constructed stream. CLOSE might signal an
error, or the result of CLOSE could cause the constituent streams to be closed,
etc, but the effect is implementation-dependent.
Proposal: (CLOSE-CONSTRUCTED-STREAM:SIGNALS-ERROR)
Calling CLOSE on a constructed stream signals an error.
Proposal (CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY):
The effect of CLOSE on a constructed stream is to close the "argument" stream
only. No i/o operations are permitted after the call to CLOSE on the stream
given to CLOSE; There is no effect on the constituents of composite streams.
For streams created with MAKE-STRING-OUTPUT-STREAM, the result of
GET-OUTPUT-STREAM-STRING is unspecified after CLOS. For composite streams,
the call to CLOSE has no effect on any of the constituent streams.
The "links" to the constituents may be broken; if the proposal in STREAM-ACCESS
passes, the results of the accessor functions there are unspecified after the
call to CLOSE.)
Proposal: (CLOSE-CONSTRUCTED-STREAM:CLOSE-CONSTITUENTS)
CLOSE first closes its argument; it then operates recursively on the constituents
of composite streams.
Examples:
>>not written; sorry<<
Rationale:
Specifying seems better than not saying what happens, even if it is
"implementation-dependent".
Current practice:
Implementations seem to vary widely.
Cost to Implementors:
Varying, depending on the current level of conformance. Making the changes
themselves is probably trivial (to the "close" method for each kind of
constructed stream type) but it is possible that system code might depend
on the behavior.
Cost to Users:
Likely small; we've not found any good uses for CLOSE on composite streams.
Cost of non-adoption:
Continued minor ambiguity
Performance impact:
near zero
Benefits:
The language would be more well specified.
Esthetics:
Well-specified languages are usually easier to deal with.
Discussion:
Signalling an error is reasonable if no Common Lisp program ever needs to
call CLOSE on a composite stream. We could not come up with a legitimate
case where you wouldn't instead close the underlying stream if that's what
you wanted.
Allowing the result to be implementation dependent is the "status quo".
ARGUMENT-STREAM-ONLY is probably the "safest" in that it makes it
harder to accidentally close a stream that wasn't intended. It
seems counterintuitive and yet it probably wouldn't be harmful
if it were well-defined that this was what it did.
CLOSE-CONSTITUENTS could be an incompatible change for some
implementations. It makes more sense for things like broadcast streams
(which are usually non-interactive) than it does for echo streams
(which are sometimes interactive).
∂12-Jan-89 1526 X3J13-mailer Issue: REMF-MULTIPLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 15:24:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 15:11:46 PST
Date: 12 Jan 89 15:05 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: REMF-MULTIPLE (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-151146-1173@Xerox>
!
Status: DRAFT
Issue: REMF-MULTIPLE
References: REMPROP (p166), REMF (p167)
Category: CLARIFICATION/CHANGE
Edit history: 26-Jan-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add IS-ERROR per Moon)
Problem Description:
The descriptions of REMF and REMPROP are not explicit about what happens in
the case that a duplicated indicator occurs on the plist. One or both indicators
might be removed.
Proposal (REMF-MULITPLE:REMOVE-ONE):
Clarify that REMF and REMPROP at most one indicator/value pair from the designated plist.
Rationale:
In a property list maintained by the normal property list operations, there will
only be one property by each name. This approach won't waste time trying to remove
other properties which are not present in the first place.
Proposal (REMF-MULTIPLE:REMOVE-ALL):
Clarify that REMF and REMPROP remove all matching indicator/value pairs from the
designated plist.
Rationale:
In a property list maintained by other operations than the standard ones,
this might be useful. Also, since the return value of REMF and REMPROP is
not well-defined, iterating to remove more than one property is expensive
because you have to start over from the head of the list.
Proposal (REMF-MULTIPLE:IS-AN-ERROR):
Clarify that it "is an error" to pass a list with a duplicated
indicator to REMF or any other function that takes a
property list (including GETF); it "is an error" for a
symbol to have duplicated properties on its property list.
Rationale:
The only thing that CLtL pp 163-167 says about
duplicated indicators on plists is that there aren't any
(first line on page 164). It does not even gurantee
that GETF returns the first occurrence.
Test Case:
;; Case #1 - removing symbol properties,etc. using REMPROP
(DEFUN REMF-MULTIPLE-TEST-1 ()
(LET ((SYMBOL (GENSYM)))
(SETF (SYMBOL-PLIST SYMBOL) (LIST 'A 'B 'C 'D 'A 'B 'C 'D))
(FORMAT T "~&Before: ~S~%" (SYMBOL-PLIST SYMBOL))
(REMPROP SYMBOL 'A)
(FORMAT T "~&After: ~S~%" (SYMBOL-PLIST SYMBOL))
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMPROP.~%"
(GET SYMBOL 'A))))
;; Case #2 - removing keywords,etc. using REMF
(DEFUN REMF-MULTIPLE-TEST-2 ()
(LABELS ((HELPER (&REST ARGUMENTS &KEY (A 1) (B 2))
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(LIST A B))
(DRIVER (&REST ARGUMENTS)
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(SETQ ARGUMENTS (COPY-LIST ARGUMENTS))
(REMF ARGUMENTS ':A)
(APPLY #'HELPER ARGUMENTS)))
(LET ((RESULT (DRIVER :A 3 :B 4 :A 5 :B 6)))
(FORMAT T "~&Returned: ~S~%" RESULT)
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMF.~%"
(= (CAR RESULT) 5)))))
Current Practice:
Symbolics implements REMF-MULTIPLE:REMOVE-ONE.
Cost to Implementors:
For implementations needing to change, the cost of a change is probably very
small in most cases. Implementations needing change which do REMPROP and/or REMF
in microcode might have a slightly harder time, but any change should still be
very localized.
Cost to Users:
None. Users must tread lightly on this issue right now because it is not well-defined.
Cost of Non-Adoption:
The language description would continue to be vague for no particularly good reason.
Benefits:
IS-ERROR at least makes the situation more explicit. For the other proposals,
users who want to use REMPROP or REMF in situations which involve lists that might
have duplicated elements would be able to do so more reliably.
Aesthetics:
There is probably no particular aesthetic reason to think one of these solutions
is better than the other, but having the issue nailed down is probably an aesthetic
improvement.
Discussion:
This issue, first brought up in Cleanup almost a year ago, got lost.
Pitman is agnostic on this for now. There are advantages to both.
If everybody already implements REMOVE-ONE, that would seem the way to go.
"If we're going to extend Common Lisp to allow duplicated indicators on
plists, we should do it for all the property list functions, not
just REMF and REMPROP."
∂12-Jan-89 1642 X3J13-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 16:42:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 16:27:25 PST
Date: 12 Jan 89 16:26 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-162725-1374@Xerox>
This issue has a number of additional comments at the end.
!
Status: DRAFT
Forum: Cleanup
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE):
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
Current Practice:
All valid implementations are believed to comply.
Cost to Implementors:
None. This is the status quo for implementors.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre support this proposal.
!
Additional Comments:
"...I'd like to see a section in the spec that concerns these
"destructive" operations to say explicity that it is perfectly
all right for them _not_ to destroy anything but instead to
"cons" new results. ...
Change "the destructive behavior of the operators" to say
"if any".
Change the proposal by...
- striking the three or so places that it explicitly reminds you
to use SETQ in case a side-effect doesn't occur
- adding some general purpose verbiage that says something like
that the purpose of these operators is to provide you the most
efficient algorithm, and that in some situations or some
implementations, there may be some reasons why the most
efficient thing is to copy rather than to side-effect. As such
none of these operators are actually required to side-effect,
but the user should assume that, whatever the implementation, it
will have speed competitive with or surpassing a side-effecting
implementation.
SORT, STABLE-SORT, and MERGE are conspicuously
absent from the list. They should be added in as well.
Should NCONC and NBUTLAST be explicitly vague?
Whereas it seems less
useful to maintain the actual list substructure in (SETF (GETF ...) ...),
DELETE, NREVERSE, NSUBSTITUTE, etc, I can see a very useful role for the
specific semantics of these few -- that they change the cdr of a particular
cons cell -- and would question very highly the value of striving for speed
at the cost of correct semantics.
NSUBLIS seems to be missing; but I would classify it in with NSUBST,
NCONC and NBUTLAST of the previous paragraph.
- - - - -
SETF of GETF, REMF should be specified.
NCONC, NBUTLAST, NSUBLIS, NSUBST, NSUBST-IF, NSUBST-IF-NOT
should be specified.
Since the argument for explicitly-defined is portability and the utility of
reliable definitions, and the argument for explicitly-vague is performance,
we should leave things explicitly vague only where
a) it matters for performance and
b) reasonable programs would not rely on the
"defined" behavior
I believe the things I say should be explicitly-vague are the ones where
good style would avoid depending on side-effect behavior and where
performance matters, while the ones I say should be explicitly-defined,
there are reasonable applications which might rely on the explicit
definition, and no strong claims that "explicitly-vague" can make a
difference in performance.
- - - - - - - - -
The NSUBSTITUTE functions seem so "obvious" in implementation that it
seems hard to justify not explicitly specifying them. Seems to me
thatclassifying the sequence functions as a group is not of any
significance. There really are only three basic sequence functions
listed there and they are all quite different, and for different
reasons: NREVERSE wants to be explicitly-vague primarily because of the
list reversal, and for that primarily because of optimizations needed
for cdr-coded implementations; DELETE because of
cdr-deleted-element-off-front-of-list for lists and
we've-got-to-copy-the-non-adjustable-array for vectors; NSUBSTITUTE I
can only imagine so that an implementation could "cheat" and use
SUBSTITUTE, or just because it is a destructive sequence function.
- - - - - - - - - - -
Where you say
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
you also need to say that it is an error after this operation to
reference any CONS that was formerly part of the top-level list
structure and is no longer part of it. Of course this applies not
just to REMF, but also to SETF of GETF, NREVERSE, DELETE,
DELETE-DUPLICATES, NCONC, NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR,
SORT, STABLE-SORT, and MERGE and to the ones that are defined to be
equivalent to these; these are all the ones that might change
list structure rather than just replacing CAR elements.
You see, not only are these destructive functions allowed to change
the components of the conses that make up the top-level list structure
of the argument, they are also allowed to reuse the storage of those
conses for something else that isn't a cons at all. You may recall
that this was DLA's original motivation for bringing up the issue.
I strongly disagree with Larry's contention that SETF of GETF, REMF,
SETF of GET, and REMPROP are not reasonable to include in this proposal.
If anything, the property list operators have less justification for the
user to depend on the representation than (for example) DELETE, not more
justification.
I disagree with JonL's and Larry's contention that NBUTLAST is not
reasonable to include in this proposal. I think it would be reasonable
to implement NBUTLAST by sliding all the list elements to the right n
positions and then returning NTHCDR n of the original list. However,
CLtL p.271 could be interpreted as -requiring- NBUTLAST to be
implemented in terms of RPLACD of a specific cons, rather than just
mentioning that as an example; if so, I would change my mind and
agree that NBUTLAST should be excluded from this proposal.
I also believe that NCONC (and hence by implication NRECONC) is
reasonable to optimize, but on that point I could easily be swayed to
change my mind since I can't think of any really plausible
optimizations. However, CLtL doesn't offer much evidence that a
specific implementation of NCONC is required.
For the others Larry listed (NSUBST, NSUBST-IF, and NSUBST-IF-NOT), what
the proposal actually says ("is permitted to SETF any part of the TREE
of conses which must be replaced by NEW-OBJECT.") is not proposing to
allow an implementation to modify any portion of a cons other than what
CLtL requires it to modify. Perhaps that means there is no reason to
include these in the proposal because the proposal says exactly the same
thing about these that CLtL says. BTW CLtL appears to -require- a
side-effect for these rather than merely -allowing- a side-effect.
∂12-Jan-89 1711 X3J13-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 17:11:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 17:04:55 PST
Date: 12 Jan 89 17:04 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-170455-1498@Xerox>
This issue is a generalization of PATHNAME-TYPE-UNSPECIFIC,
which it subsumes.
!
Forum: Cleanup
Issue: PATHNAME-UNSPECIFIC-COMPONENT
Forum: Cleanup
References: File System Interface (pp409-427)
Category: CHANGE
Edit history: 27-Dec-88, Version 1 by Pitman
Subsumes: Issue PATHNAME-TYPE-UNSPECIFIC
Problem Description:
In some file systems, it is inappropriate to represent particular
pathname components, either all the time or in some specialized
circumstance.
- Unix pathnames never have a version field.
- In some file systems, specifying a device and a directory means
something very different than specifying the device alone,
particularly when the device is a "logical device" that may
already imply a directory.
- Some Unix pathnames have types and others do not. For example,
it is possible to make files named "foo." and "foo" which are
distinct. CLtL (p412) specifies that the type is ``always a
string, NIL, or :WILD.'' This description is too restrictive
to be practical in this case. One of these (usually the former)
can get a type of "" but it is not clear how to represent the
other. If NIL is used, merging primitives cannot detect that the
field is filled and should not be merged against.
- ITS pathnames have either a version or a type, but never both.
"JOE;FILE 32" has a directory, a name, and a version.
"JOE;FILE TEXT" has a directory, a name, and a type.
"JOE;FILE TEXT 32" is not a possible ITS filename.
Proposal (PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the DEVICE, DIRECTORY, TYPE, or
VERSION field of a pathname for file systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
are treated as if the field were empty. That is, they both cause the
component not to appear in the string.
When merging, however, only a NIL value for a component will be
replaced with the default for that component, while :UNSPECIFIC
will be left alone as if the field were filled.
Portable programs should expect to find :UNSPECIFIC in the device,
directory, type, or version field in some implementations.
Portable programs should not explicitly place :UNSPECIFIC in any
field, since that it might not be permitted in some situations,
but portable programs may sometimes do so implicitly.
Test Case:
;; #1: Non-portable code. This may signal an error in some
;; implementations where an unspecific type makes no sense.
(MAKE-PATHNAME :TYPE :UNSPECIFIC) ;not portable
;; #2: In this example, assume a Unix file system.
(PATHNAME-TYPE (PARSE-NAMESTRING "foo."))
=> ""
(PATHNAME-TYPE (PARSE-NAMESTRING "foo"))
=> :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo")
(MAKE-PATHNAME :TYPE "BAR")))
=> :UNSPECIFIC
;; #3: In this example, assume an ITS file system.
(LET ((P (PARSE-NAMESTRING "FOO 32")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
(LET ((P (PARSE-NAMESTRING "FOO TEXT")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> ("TEXT" :UNSPECIFIC)
(LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
(PARSE-NAMESTRING "FOO TEXT"))))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
;; Note: It is not the intent of this proposal to actually legislate
;; the canonical representation of Unix pathnames "foo." and "foo",
;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably
;; be done, but under separate cover. The above examples are intended
;; only to demonstrate how this proposal will permit the representation
;; of pathnames not usefully representable under CLtL.
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file types and versions of :UNSPECIFIC on
Unix and ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which already do this are legitimized.
Some implementations which use a non-standard token other than
:UNSPECIFIC to implement this functionality would want to switch
to use :UNSPECIFIC so that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible
pathnames in a rational way and at the same time to conform to the
standard. Such an inability would seriously jeopardize the usefulness
of Common Lisp in the design of serious programs.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed (for types) in the Colander draft edition of
CLtL, but was removed for the Laser edition. The following text is
excerpted from the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
"The stuff about generic pathnames in the discussion section
was brain damage and may have lead to the confusion that caused
:unspecific to be dropped from Common Lisp. Only the stuff about
components not supported by a file system makes sense."
∂12-Jan-89 1731 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 17:31:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 17:20:59 PST
Date: 12 Jan 89 17:20 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-172059-1554@Xerox>
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, and RENAME-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
If IN-PACKAGE is given a package object as an argument, that package
is selected. It is an error if, when a package object is given as a
first argument to IN-PACKAGE, a :USE list is explicitly specified and
does not exactly match the package or :NICKNAMES is explicitly supplied
and does not exactly match the package.
Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
accessors to package data structures and permit only package objects
as arguments.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
Proposal: (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE)
In addition, require that PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST to accept names,
too.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
Under MORE-PERMISSIVE,
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
MORE-PERMISSIVE adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permits strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small. A tiny bit more for MORE-PERMISSIVE.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
Since the pathname accessors all take namestrings or streams, one might
easily argue that it would be more consistent for PACKAGE-NAME,
PACKAGE-NICKNAMES, etc. to also take arguments of package names. After
all,
(PACKAGE-NAME "FOO") => "FOO"
is no stranger than
(NAMESTRING "JOE:fred.lisp") => "JOE:fred.lisp".
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occassions, but mostly seemed too far out in left
field to bother suggesting it.
∂23-Jan-89 1051 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jan 89 10:51:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 525301; Mon 23-Jan-89 13:49:15 EST
Date: Mon, 23 Jan 89 13:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
To: sandra%defun@cs.utah.edu, X3J13@sail.stanford.edu
Message-ID: <19890123184939.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Since the X3J13 meeting last week passed DECLARATION-SCOPE:NO-HOISTING
(instead of LIMITED-HOISTING), it is no longer possible to make a declaration
that applies to an entire DEFUN, DEFMACRO, or DEFMETHOD by placing a DECLARE
at the head of the body. Such declarations have been incompatibly changed
to apply only to the body.
The problem is that (LOCALLY (DECLARE ...) (DEFUN ...)) cannot be used as
the new way to say what used to be said as (DEFUN ... (DECLARE ...) ...),
even though side-discussion at the meeting indicated that some people
thought that was a valid workaround. DEFINING-MACROS-NON-TOP-LEVEL
does not list LOCALLY as one of the forms whose body is handled at top
level. CLtL says LOCALLY is a macro, but doesn't say what it macroexpands
into. Presumably it macroexpands into a LET that doesn't bind any variables,
which DEFINING-MACROS-NON-TOP-LEVEL says (or implies) does not have a body
that is handled at top level.
Assuming the vote on DECLARATION-SCOPE is not likely to be reversed, I
think DEFINING-MACROS-NON-TOP-LEVEL needs to be modified to treat the
body of LOCALLY as top-level. If this requires changing LOCALLY from a
macro to a special form, so be it.
∂23-Jan-89 1409 X3J13-mailer Second edition of "Common Lisp: The Language"
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89 14:09:07 PST
Received: from fafnir.think.com by Think.COM; Mon, 23 Jan 89 16:45:35 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Jan 89 17:05:55 EST
Received: by verdi.think.com; Mon, 23 Jan 89 17:04:42 EST
Date: Mon, 23 Jan 89 17:04:42 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901232204.AA14004@verdi.think.com>
To: x3j13@sail.stanford.edu
Subject: Second edition of "Common Lisp: The Language"
The following is a paraphrase of what I announced at the last X3J13
meeting in Hawaii.
I am now working fairly full steam on a second edition of CLtL. Digital
Press would like to have it out this summer, and I think that would be the
optimal timing for it. The purpose of a second edition is to provide the
implementation and user community with feedback on what X3J13 has done so
far, in a manner that links the committee's decisions with the current
structure of CLtL. (The eventual standard will be organized in a
completely different manner.) This will provide a bridge between the first
edition of five years ago and the eventual standard (which may be another
two or more years away). In addition, I will be adding commentary of my
own about difficult places in the language, more examples, etc. For
example, I am attempting to explain nested backquotes so you can understand
them. I also promise that the second edition will have a better index.
The second edition will contain the entire contents of the first edition.
New material will be distinguished from the old, and clearly marked as to
whether it is the result of an X3J13 vote, an informal comment that came up
in X3J13 meetings, or my own commentary. The preface will contain
appropriate disclaimers, including that additional meetings and a public
review period are yet to come, that X3J13 may reverse any decision at any
time, that X3J13 does not officially endorse the second edition, that
no member of X3J13 necessarily endorses what I write, and that where new
examples conflict with old material or with X3J13 votes, the new examples
have lesser priority (I hope this doesn't occur!).
I plan to include material on cleanups and compiler cleanups so far. I
would like to include the condition system and LOOP. Dick Waters also once
spoke to me about including an appendix on OSS in order to publicize this
alternative approach to iteration; now that OSS and generators seem to be
converging, I'm not sure what would be appropriate, but am open to
suggestions.
I do *not* plan to include any material about CLOS beyond a short overview
of five to ten pages, plus a few inserts describing such general features
as PRINT-OBJECT and SYMBOL-MACROLET that impinge on the rest of the
language. I will include pointers to CLOS chapters 1 and 2 as published
in LASC and SIGPLAN Notices, and to Sonya Keene's book (I certainly
couldn't do any better than she did).
I will be relying on work done by a lot of people, and I will be asking
some of you for very specific help in the next few weeks. It seems to me
that these many people ought to benefit from the royalties generated.
I looked into various methods of compensation, but it became extremely
complicated, both procedurally and legally, and there was always th
danger of overlooking someone. I have turned instead to the notion of
donating royalties toward some worthy cause(s) that would benefit the
Lisp community at large. (This idea met with general informal approval
at the last X3J13 meeting when I announced it.) I first looked into
financing travel so that students could attend the coming Lisp and
History of Lisp (LISPHOL) Conference; SIGPLAN has a fund for that purpose.
It turns out that this fund is undersubscribed; SIGPLAN has more funds
than applications, and David Wise urged me to look for some other project.
Two more promising possibilities are underwriting some of the costs
of making good historical records at LISPHOL, and donating funds to
The Computer Museum to establish a collection and perhaps exhibits
on the History of Lisp. I would be glad to receive other suggestions
for appropriate projects.
I hope to have a complete draft ready within several weeks. I will be
sending a copy of this draft to every member of X3J13. To be useful,
feedback would be needed within a few weeks. (Note that the new material
will be distinguished by some typographical device such as lines in the
margins, so you shouldn't have to read an entire 500-page draft!) I will
also send a copy of the finished, published book to every member of X3J13
once it is available, as well as to certain other persons who have made
contributions.
--Guy
∂23-Jan-89 1423 X3J13-mailer cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jan 89 14:23:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA11470; Mon, 23 Jan 89 15:21:37 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA19082; Mon, 23 Jan 89 15:21:33 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901232221.AA19082@defun.utah.edu>
Date: Mon, 23 Jan 89 15:21:32 MST
Subject: cl-compiler issues
To: x3j13@sail.stanford.edu
At the Hawaii meeting, the following cl-compiler issues were passed:
ALLOW-LOCAL-INLINE
DEFCONSTANT-SPECIAL (amended)
LOAD-TIME-EVAL (amended)
SHARP-COMMA-CONFUSION
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (amended)
CONSTANT-MODIFICATION
Copies of these proposals (incorporating the amendments) are available
for anonymous FTP from cs.utah.edu (that's 128.110.4.21), in directory
cl-compiler/passed. There are also copies of the proposals that were
passed at the October meeting in this directory.
Also, I want to remind you all that we are still soliciting comments
on the remaining issues that were distributed earlier this month. In
particular, issue COMPILE-ENVIRONMENT-CONSISTENCY was tabled because
some people at the meeting indicated they wanted to see some changes
to the writeup, and I need to know what those changes are.
E-mail on compiler issues should be sent to cl-compiler@sail.stanford.edu.
We appreciate it if you send a separate message for each issue, and
include the issue name in the message subject line.
-Sandra
-------
∂24-Jan-89 1231 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 24 Jan 89 12:31:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 263137; Tue 24-Jan-89 14:46:01 EST
Date: Tue, 24 Jan 89 14:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
To: Thom Linden <Baggins@IBM.COM>
cc: CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Palter@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890124194625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Please acknowledge receipt of this mail so I can be sure it was
not lost in the network. The reply needn't be CC'ed to any of
the other recipients.
Page 6 -- *all-registry-names* should be renamed to
*all-character-registry-names*; the word "registry" by itself
is too general.
Page 9 -- the fourth bullet requires a defined total ordering of all
characters. This seems unnecessary, and is impossible to implement in any
system (such as Symbolics Genera) that allows dynamic addition of character
registries by third-party software vendors and by users; in such a system
character codes have to be allocated dynamically and therefore their order
cannot be fixed ahead of time.
Page 9 -- This says an implementation must define the result of
standard-char-p on the characters it supports. I think that is incorrect.
Common Lisp fully defines the result of standard-char-p, which is NIL
for all characters added by an implementation.
Page 14 -- This EXTERNAL-WIDTH function probably should be part of a
database facility or a terminal screen template facility; I'm not sure it
is useful by itself. Also note that its result is only meaningful with
respect to a specific state of the stream. To give two examples, with the
SO/SI encoding the answer can vary by 1 depending on whether the stream is
already shifted into the correct state for the first character; with the
universal encoding Symbolics uses, the answer can vary by a lot depending on
whether the character repertoires appearing in the string have been used
earlier on the same stream (and hence have been assigned encoding numbers).
Because of this dependence on the state of the stream, I cannot think of
any correct use of EXTERNAL-WIDTH that does not involve immediately
outputting the string to the stream. Therefore I believe the same effect
can be achieved without adding any new functions, by calling FILE-POSITION,
outputting to the stream, calling FILE-POSITION again, and subtracting. If
you still want to propose this feature, you should change the name: use
"length" instead of "width", since that's the word Common Lisp always uses,
and use a name that relates to the :EXTERNAL-CODE-FORMAT option to OPEN;
for example, STRING-LENGTH-IN-EXTERNAL-CODE-FORMAT or
EXTERNAL-CODED-STRING-LENGTH.
Page 24 -- I can't figure out what you intend the meaning of SIMPLE-STRING
to be. Your report mostly does not mention it, but it doesn't say to
remove it either. If I have correctly correlated page 24 back to CLtL, you
are defining SIMPLE-STRING to be synonymous with SIMPLE-GENERAL-STRING.
Maybe what you really meant, though, was what you said in November you
would do, which was to make SIMPLE-STRING mean (AND STRING SIMPLE-ARRAY),
in other words a union of several subtypes. This is particular confusing
because Common Lisp uses the name SIMPLE-VECTOR to mean what you might call
a simple general vector, that is, (SIMPLE-ARRAY T 1) rather than
(SIMPLE-ARRAY * 1). Here are my suggestions for what to do with the
various names for string subtypes:
STRING As a union of all strings, this is fine.
GENERAL-STRING I think (VECTOR CHARACTER) is just as good.
BASE-STRING I think (VECTOR BASE-CHARACTER) is just as good.
SIMPLE-STRING Should mean (SIMPLE-ARRAY CHARACTER 1).
SIMPLE-BASE-STRING This is fine.
SIMPLE-GENERAL-STRING This name is horrible, use SIMPLE-STRING.
My rationale for these suggestions largely comes from thinking about
which of these names would ever be used in type declarations and about
how these names relate to the other names already in Common Lisp. To
repeat older comments:
Pages 19 and 20 introduce a new type named simple-base-string, in addition
to simple-string. If you think about how simple-string would be used for
compiler optimization, it makes sense for simple-string to be the name for
the single simplest representation, rather than a name for a whole family
of representations that would have to be discriminated at run time. Thus
what you call simple-base-string should be called simple-string, and what
you call simple-string should just be called (simple-array character (*)).
This would not be an incompatible change in the meaning of simple-string.
Simple-string would be analogous to simple-vector.
I changed my mind slightly on that and now claim that while SIMPLE-STRING
should still be a single representation, not a union, it should be the
representation that can hold all characters. This is both because of the
principle that correct programs should be easier to write than
extra-efficient programs, and because of the powerful analogy with the name
SIMPLE-VECTOR. Then the name SIMPLE-BASE-STRING is also needed for
convenient type declarations of the more efficient but less functional
string representation. That name is good, by analogy to BASE-CHARACTER.
Adopting the above suggestions helps you decide what to do about the
SCHAR, SBCHAR, and SGCHAR mess. First of all, you only need two functions,
not three, because there are only two specified specialized representations.
SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
for SIMPLE-BASE-STRING, and SGCHAR is not needed. (In fact I would prefer
to remove all of the specialized versions of AREF from the language, in
favor of THE or type declarations, but I know that would only pass over
some peoples' dead bodies so I won't push it.)
In case you are wondering, I have no quarrel with the name BASE-CHARACTER
and would not want to see it removed. I guess I differ from Larry here,
unless I erred when I wrote down his comments during the meeting.
Page 25 -- The discussion of STRING and SIMPLE-STRING thinks that there
is a distinction between declaration and discrimination, but Common Lisp
no longer has such a distinction. Even when Common Lisp did have such
a distinction, the meanings for declaration stated here were incorrect.
Page 29 -- *all-character-registry-names* has to be a variable, not a
constant, to accomodate systems (such as Symbolics Genera) that allows
dynamic addition of character registries by third-party software vendors
and by users.
Page 35 -- CHAR-REGISTRY should be renamed to CHAR-REGISTRY-NAME, so that
if at some later time character registry objects are added, there is no
possibility of confusion about whether this function returns a name or
an object.
Page 40 -- the default :ELEMENT-TYPE for OPEN cannot be BASE-CHARACTER. I
think this was discussed at the X3J13 meeting. The report suffers from a
confusion between two meanings of BASE-CHARACTER: the character type
implemented most efficiently by the Lisp, and the character type most
natural to the file system. These are not always the same. Furthermore,
in a network-based system that supports multiple file systems equally
(Symbolics Genera is an example), each file system might have a different
natural character type. BASE-CHARACTER should just mean the character type
implemented most efficiently by the Lisp. The default for :ELEMENT-TYPE
has two viable choices that I can see, and maybe you should just propose
both and let people vote:
(1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
adheres to the principle that writing correct programs should be easier
than writing extra-efficient programs (since making a program correct
requires making every part of it correct, while making a program
efficient only requires improving the bottlenecks), and doesn't cost
anything in implementations that don't have extended characters.
(2) The most natural type for the particular pathname being opened.
In some systems this would be a constant, and in a subset of those
systems this would be BASE-CHARACTER, however in general this might
depend on the host, device, or even type fields of the pathname,
and might also depend on information stored in the file system.
In general this would always be an (improper) supertype of
BASE-CHARACTER, but it's probably a bad idea to make that a requirement,
as some file systems might not be able to implement it conveniently.
Again this doesn't cost anything in implementations that don't have
extended characters.
The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
already exists in Common Lisp) needs to be clarified. Perhaps they
are the same.
Also the following promise from 14 November did not show up in the report:
>> There should be a name for the "natural" encoding and there should be a
>> specification of the properties of the natural encoding that a programmer
>> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> :INTERCHANGE. The definition probably involves the concept of data
>> interchange with non-Lisp programs on the same system.
This will be added to the revision.
Appendix B -- I disagree with the way you've used deprecation. I'll
comment on each individual point:
- I see no justification for deprecating STANDARD-CHAR.
- I agree that STRING-CHAR should be deprecated, not deleted nor kept.
- I think fonts and bits should be removed outright, not deprecated,
because no portable program could possibly be using them.
- I think the CHAR-INT function needs to be kept, although the INT-CHAR
function should go away. This is for hashing. See comments below
on character attributes.
No particular page -- the use of strings for naming registries, labelling
characters, and naming external code formats is objectionable. Nothing
else in Common Lisp is named by strings. Use of strings might lead to
efficiency problems. We feel that keyword symbols are the appropriate
objects to use for these three kinds of names.
No particular page -- We agree with the deprecation or deletion of the two
particular character attributes defined by CLtL, but not with the
deprecation of the whole concept of character attributes. In fact on page
20 you say "characters are uniquely distinguished by their codes," which
makes it impossible to have character attributes at all. The language must
define how conforming programs should be written so that they will work
both in implementations with character attributes and in implementations
without them. For example, the value of (eql x (code-char (char-code x)))
is unspecified. Another thing that needs to be said is that the exact
character operations (char=, string=, etc.) respect all character
attributes, while the inexact character operations (char-equal,
string-equal, etc.) respect or ignore each character attribute in an
implementation-defined but consistent fashion. Some of what you say on
page 44 about attributes in general needs to be part of the spec, not
deprecated. I would retain everything on that page except for INT-CHAR and
the last bullet (referring to bits and fonts), and I would add a remark
that FIND-SYMBOL and INTERN respect character attributes. If you want,
perhaps I or someone else at Symbolics can provide exact text for what
to say about character attributes that you could insert into your report.
No particular page -- On the subject of defining character registries in a
separate document, and relating them to ISO standards for character
encoding: I think that's fine. I don't see anything wrong with introducing
the concept of character registry and the requirement that each character
object relates to exactly one registry. However, I think the somewhat
random list of character registries on pages 7-8 and again on page 21 does
not belong in the language specification. Even the names of the
standardized character registries belong in the character registry
standard, not in the Common Lisp language standard. I'm confused about the
meaning of BASE, STANDARD, and CONTROL as character registry names; these
are mentioned in your report but not explained very well. If these are
character registries that are required to exist in all Common Lisp
implementations, then unlike the others they do belong in the Common Lisp
language standard, not in the character registry standard.
At the meeting there was some discussion about the issue of enumerating all
characters in a character registry. People claimed incorrectly that it was
impossible. In fact it's possible to do this, with questionable
efficiency, by the following program:
(dotimes (code char-code-limit)
(let ((char (code-char code)))
(when char
(when (eq (char-registry-name char) desired-registry-name)
... process this char ...))))
Of course you have to change the EQ to EQUALP if you continue to use
strings to name character registries. For more efficiency, you could add
a way to iterate over all the codes in one character registry, but I think
that is unnecessary.
TYPOS:
25 -- base-string is missing from the Table 4-1 amendment.
26 -- general-string is not an array of BASE characters, also the first
two paragraphs under A.4.8 are garbled (the two separate sentences for
strings for symbols got smushed together).
37 -- This says the default for the :ELEMENT-TYPE option to MAKE-STRING
is SIMPLE-STRING. Actually it's CHARACTER.
VOTING:
You asked for suggestions on how to modularize the voting. Here is a
possible breakdown into separate issues, admittedly not very well thought
out. In general, I feel that breaking down the voting into separate issues
is a good idea even if some of the issues are interdependent. If people
don't understand the interdependencies well enough to vote properly, then I
would claim that the subcommittee report hasn't explained things well
enough.
Concept of character registries and character labels
Functions and variables for character registries and character labels
Page 9 rules for implementation-defined character registries
New syntax for #\
New syntax for the CHARACTER type specifier, new argument to CHARACTERP
New rules for names of symbols
Deprecation of STRING-CHAR
Deprecation of STANDARD-CHAR
BASE-CHARACTER type
New meaning of STRING type, and its subtypes
SCHAR
SBCHAR
SGCHAR
Type returned by (CONCATENATE 'STRING ...) and similar forms
Extensions to COERCE
EXTERNAL-WIDTH function
:ELEMENT-TYPE option to OPEN
:EXTERNAL-CODE-FORMAT option to OPEN
CHAR-CODED-CHARACTER-SET-VALUE function
Rules for implementation-defined character attributes
Removal or deprecation of bits and fonts, and implied arglist changes
Removal or deprecation of the semi-standard format effector characters
Support of extended characters in the readtable
Removal or deprecation of CHAR-INT
Removal or deprecation of INT-CHAR
Miscellaneous other and editorial changes
Wow, 26 ballot items! Democracy on the march! I think the complexity of
the issues amply justifies having about that many separate issues, though.
∂24-Jan-89 1312 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Jan 89 13:12:07 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 24 Jan 89 15:47:56 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 24 Jan 89 16:08:30 EST
Date: Tue, 24 Jan 89 16:09 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Comments on the Character proposal dated January 1, 1989
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Thom Linden <Baggins@ibm.com>, CL-Characters@sail.stanford.edu,
X3J13@sail.stanford.edu,
Common-Lisp-Implementors@stony-brook.scrc.symbolics.com,
KMP@stony-brook.scrc.symbolics.com,
Palter@stony-brook.scrc.symbolics.com
In-Reply-To: <19890124194625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890124210921.6.BARMAR@OCCAM.THINK.COM>
Date: Tue, 24 Jan 89 14:46 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
No particular page -- the use of strings for naming registries, labelling
characters, and naming external code formats is objectionable. Nothing
else in Common Lisp is named by strings. Use of strings might lead to
efficiency problems. We feel that keyword symbols are the appropriate
objects to use for these three kinds of names.
I agree with your suggestion. However, there is at least one global
database in CL that is named by strings: the package name database.
barmar
∂25-Jan-89 0613 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Jan 89 06:13:30 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00927g; Wed, 25 Jan 89 06:07:03 PST
Received: by bhopal id AA08310g; Wed, 25 Jan 89 06:09:24 PST
Date: Wed, 25 Jan 89 06:09:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901251409.AA08310@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, X3J13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 23 Jan 89 13:49 EST <19890123184939.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
re: The problem is that (LOCALLY (DECLARE ...) (DEFUN ...)) cannot be used as
the new way to say what used to be said as (DEFUN ... (DECLARE ...) ...),
even though side-discussion at the meeting indicated that some people
I didn't hear any of this "side discussion", but I can imagine it
happening. Actually, there might be less need for declarations that
apply to the whole defun than one might expect (but of course
there would some extreme cases where it is very cumbersome not
to have it). A "cumbersome" workaround is to wrap LOCALLY's
around all the defaulted computations in the &optional and &key
parameters, as well as having a regular declare in the DEFUN.
This style of "cumbersome" workaround _was_ mentioned in the
discussion section of the proposal:
One idiom which will be adversely affected by both of these proposals is:
(let ((*a* *a*))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
where *a* has not been proclaimed special. This idiom would likely
have to be written as:
(let ((*a* (locally (declare (special *a*)) *a*)))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
or [preferably!] *a* should be proclaimed special. Similar idiots
like this may be in use for LAMBDA-Expressions, or DEFUNs etc.
[sic. Hopefully, someone will correct the typo before it gets into
the standard]
This problem *was* discussed at some length about a year ago --
I recall KMP bringing it up, and I explicitly mentioned it to
you (maybe in that series of private interchanges we had on
the issue). Your reply to me looked as though you didn't
appreciate the problem back then. [If you are concerned about
the exact wordings, I could probably rummage around in old mail
files . . . ]
One problem with trying to say that LOCALLY "passes through"
top-level is that in fact it carries a non-null (syntatical)
lexical environment. If we remember Walter van Roggen's proposal
from long ago to say that "toplevel" merely means null lexical
environment, then LOCALLY won't make it. Consider for example
how the following functions work interpretively:
(defun bar (x) (macrolet ((flower (z) `(quote ,z)))
#'(lambda (y) (if y (flower x) 5))))
(defun baz (x) (locally (declare (special x ))
#'(lambda (y) (if y (flower x) 5))))
Several implementations I've tried BAR on seem to do it right;
maybe not so many will do BAZ right.
Now, I don't mind saying that the "special attention" paid
to top-level forms should also be paid to certain forms
in embedded places. It just seems that the notion "toplevel"
is becoming more and more artificial, and less related to
what the intuitive notion implies. It's possible that the
very complicated notion that Rob McLaughlin once tried to
espouse may be necessary to explain all this.
-- JonL --
∂25-Jan-89 0850 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jan 89 08:50:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 526603; Wed 25-Jan-89 11:48:00 EST
Date: Wed, 25 Jan 89 11:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
To: Jon L White <jonl@lucid.com>
cc: sandra%defun@cs.utah.edu, X3J13@SAIL.STANFORD.EDU
In-Reply-To: <8901251409.AA08310@bhopal>
Message-ID: <19890125164831.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 25 Jan 89 06:09:24 PST
From: Jon L White <jonl@lucid.com>
If we remember Walter van Roggen's proposal
from long ago to say that "toplevel" merely means null lexical
environment, then LOCALLY won't make it.
But (when (oddp (random))
(defmacro frob ...))
clearly evaluates the defmacro in a null lexical environment, and just
as clearly does not have the defmacro in a top-level position.
∂25-Jan-89 0936 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 25 Jan 89 09:36:00 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 25 Jan 89 12:11:19 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 25 Jan 89 12:31:53 EST
Date: Wed, 25 Jan 89 12:32 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Jon L White <jonl@lucid.com>, sandra%defun@cs.utah.edu,
X3J13@sail.stanford.edu
In-Reply-To: <19890125164831.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890125173236.0.BARMAR@OCCAM.THINK.COM>
Date: Wed, 25 Jan 89 11:48 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Wed, 25 Jan 89 06:09:24 PST
From: Jon L White <jonl@lucid.com>
If we remember Walter van Roggen's proposal
from long ago to say that "toplevel" merely means null lexical
environment, then LOCALLY won't make it.
But (when (oddp (random))
(defmacro frob ...))
clearly evaluates the defmacro in a null lexical environment, and just
as clearly does not have the defmacro in a top-level position.
I think JonL meant that toplevel implies null lexical environment, not
the other way around.
barmar
∂26-Jan-89 0002 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Jan 89 00:02:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 25 JAN 89 23:59:20 PST
Date: 25 Jan 89 23:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: Comments on the Character proposal dated January 1, 1989
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 24 Jan 89 14:46 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Palter@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890125-235920-8229@Xerox>
David,
I thought there were fewer than 26 "issues". I thought they might be split
up into issues as follows; I think these issues 'cover' the current
proposal with some exceptions. I've enclosed David's characterization of
the issues in <brackets>; as you see, I've lumped some of them together.
Exceptions:
<New rules for names of symbols.> What new rules?
<:ELEMENT-TYPE option to OPEN.> I thought this was removed from the
proposal.
<Removal or deprecation of the semi-standard format effector characters.> I
guess I don't understand this.
<Support of extended characters in the readtable.> I thought this falls out
of character type?
<Miscellaneous other and editorial changes> not sure what they are...
Sorry that the following are telegraphic. I'd guess they would need to be
fleshed out more.
!
Issue: CHAR-FONT-UNUSED
Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
Proposal: eliminate of CHAR-FONT and CHAR-BITS, related parameters, and the
STRING-CHAR type. (I.e., identification of STRING-CHAR with CHARACTER).
<Removal or deprecation of bits and fonts, and implied arglist changes.
Deprecation of STRING-CHAR. Removal or deprecation of CHAR-INT. Removal or
deprecation of INT-CHAR. Rules for implementation-defined character
attributes.>
If this fails, or if people only wanted to eliminate CHAR-FONT and not
CHAR-BITS, most of the rest of the proposals get more complicated.
Issue: STRING-TYPE-RESTRICTIVE
Problem: STRING type doesn't allow thin & fat strings.
Proposal: change to the STRING type to be "all vectors with element type a
subtype of CHARACTER" rather than (VECTOR CHARACTER). Specify the
(modified) behavior of various functions that take a type specifier when
given STRING.
<New meaning of STRING type, and its subtypes. Type returned by
(CONCATENATE 'STRING ...) and similar forms. Extensions to COERCE.>
Issue: STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal: add convenient abbreviations for string types & accessors. Define
BASE-CHARACTER = (UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR). Add SCHAR
SBCHAR SGCHAR BASE-STRING MOST-GENERAL-STRING SIMPLE-GENERAL-STRING
SIMPLE-BASE-STRING etc.
<SCHAR. SBCHAR. SGCHAR. BASE-CHARACTER type. Deprecation of STANDARD-CHAR.>
Issue: FILE-EXTERNAL-REPRESENTATION
Problem: can't specify external encoding even when there are lots
Proposal: add standard :EXTERNAL-CODE-FORMAT keyword to OPEN, with
unspecified range.
<:EXTERNAL-CODE-FORMAT option to OPEN>
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Problem: Can't portably talk about non-standard characters
Proposal: introduce the notion of Registries, require a fixed set of
registries, standardize on #\registry:id, add all-implemented-registries
and find-character.
This part deals with the mechanism by which characters can be identified
portably between implementations that do not share the same coded character
set.
<Concept of character registries and character labels
Functions and variables for character registries and character labels
Page 9 rules for implementation-defined character registries
New syntax for #\
New syntax for the CHARACTER type specifier, new argument to CHARACTERP
>
Issue: CHARACTER-FUNCTIONS-UNDERSPECIFIED
Problem: how ALPHA-CHAR-P, LOWER-CASE-P work on Kanji, characters with
accents, etc. is not specified.
Proposal: Current proposal is to leave unspecified.
I'd rather specify the 'intent' of the behavior of ALPHA-CHAR-P,
LOWER-CASE-P etc for alphabetic and non-alphabetic scripts (e.g., works for
Greek, no-op for Hangul, etc.)
< Not in current list >
Issue: STRING-BINARY-WIDTH
Problem: Can't find out how many bytes a string will take when written as
text
Proposal: <EXTERNAL-WIDTH function>
Issue: CHAR-CODE-NON-PORTABLE
Problem: no way to talk about well-known external coding methods, only
internal codes
Proposal: Add CHAR-CODED-CHARACTER-SET-VALUE
<CHAR-CODED-CHARACTER-SET-VALUE function.>
∂26-Jan-89 1803 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 89 18:03:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 527962; Thu 26-Jan-89 21:00:31 EST
Date: Thu, 26 Jan 89 21:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Comments on the Character proposal dated January 1, 1989
To: masinter.pa@Xerox.COM
cc: X3J13@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <890125-235920-8229@Xerox>
Message-ID: <19890127020101.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 25 Jan 89 23:57 PST
From: masinter.pa@Xerox.COM
<New rules for names of symbols.> What new rules?
There are several mentions of symbol names in the report, but maybe
those are just wording changes and nothing new. I think I was referring
mainly to the 8th and 9th bullets on p.44, relating to READ's handling
of implementation-defined character attributes.
<:ELEMENT-TYPE option to OPEN.> I thought this was removed from the
proposal.
Bottom of p.40, top of p.41. The terrible format of the proposal makes
it difficult to tell that these sections are referring to :element-type,
but they are.
You're probably thinking of the :character-set option to OPEN, which was
removed.
<Removal or deprecation of the semi-standard format effector characters.> I
guess I don't understand this.
Pages 19,37, 38 of the report and I think a couple of other pages as
well. CLtL p.21.
<Support of extended characters in the readtable.> I thought this falls out
of character type?
Top of p.39 of the report. I don't know what you mean by "falls out", except
perhaps that with the issues divided up, there are some combinations of votes
that only a lunatic would vote. True.
<Miscellaneous other and editorial changes> not sure what they are...
Pages 15 through 44 of the report, except for the 20% or so of that material
covered by explicit ballot items. I'm not sure what they are either.
Your bundlings of issues seem okay to me, although I suspect that if someone
wrote them up properly, they would discover that some of them had been
bundled too tightly and needed to be split. For instance, putting the
removal or deprecation of CHAR-INT and INT-CHAR into CHAR-FONT-UNUSED
doesn't entirely make sense. The others seem good.
If CHAR-FONT-UNUSED fails, or if people only wanted to eliminate CHAR-FONT and not
CHAR-BITS, most of the rest of the proposals get more complicated.
If that's really true, there is something wrong, as it must mean that
the other proposals wouldn't work in the face of implementation-defined
character attributes.
∂27-Jan-89 0307 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Jan 89 03:07:49 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA13678g; Fri, 27 Jan 89 03:02:12 PST
Received: by bhopal id AA17641g; Fri, 27 Jan 89 03:04:33 PST
Date: Fri, 27 Jan 89 03:04:33 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901271104.AA17641@bhopal>
To: barmar@Think.COM
Cc: Moon@stony-brook.scrc.symbolics.com, sandra%defun@cs.utah.edu,
X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Wed, 25 Jan 89 12:32 EST <19890125173236.0.BARMAR@OCCAM.THINK.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
re: I think JonL meant that toplevel implies null lexical environment, not
the other way around.
You're quite right. The context of the two examples I gave was to make
very clear that LOCALLY implies a non-null lexical environment, and that
you can't simply "fake it" at toplevel. As Bacher points out, it is
rather unsettling to have "toplevel" pass through this construct with
lexical appendages, but be blocked by the straightforward EVAL-WHEN.
[However, it's not clear to me whether Walters original suggestion really
did have the implication that moon inferred. I found Rob MacLaughlin's
"early-eval/late-eval" semantics for compilation processing a bit hard
to follow; but it's entirely possible that he *would* have processed
the defmacro in moon's oddp example.]
Still waiting for someone to suggest that the term "toplevel" be
abandoned for this purpose, and some more agressive term taken on.
-- JonL --
∂31-Jan-89 0132 X3J13-mailer Comments on the Character proposal dated January 1, 1989
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Jan 89 01:31:58 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03960g; Tue, 31 Jan 89 01:21:13 PST
Received: by bhopal id AA14594g; Tue, 31 Jan 89 01:23:28 PST
Date: Tue, 31 Jan 89 01:23:28 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901310923.AA14594@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM,
Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David A. Moon's message of Tue, 24 Jan 89 14:46 EST <19890124194625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
re:
Date: Tue, 24 Jan 89 14:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
. . . what to do about the
SCHAR, SBCHAR, and SGCHAR mess. First of all, you only need two functions,
not three, because there are only two specified specialized representations.
SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
for SIMPLE-BASE-STRING, and SGCHAR is not needed. (In fact I would prefer
to remove all of the specialized versions of AREF from the language, in
favor of THE or type declarations, but I know that would only pass over
some peoples' dead bodies so I won't push it.)
. . .
You might be surprised at the kinds of people who really don't care
about whether or not names for the specialized versions of AREF are
defined in the portable languages. Me, for one.
But what I am very leary about is a definition of an important data
type that is too wishy-washy to be portable. SIMPLE-BASE-STRING may be
in this category. By way of explanation, let me draw the parallel with
some numeric types.
Ostensibly, FIXNUM is in this non-portable category, since up until the
Hawaii meeting, there wasn't even any requirement in the language the
type FIXNUM mean anything at all (i.e., it could be the null subset of
INTEGER). At least now (TYPEP x 'FIXNUM) will imply that <x> is useful
for array/vector indices. For example, the following very reasonable
program might work in implementation A, but fail in implementation B,
*** merely because of the variance of the FIXNUM datatype between the
two implementations ***:
(defun fills-out-p (i b)
;; Ascertain whether bit 'i' of the bit vector 'b' is the same as
;; all the remaining bits (in the higher bit positions).
(check-type i fixnum)
(check-type b simple-bit-vector)
(locally (declare (fixnum i) (simple-bit-vector b))
;; Declarations for "fast, open-coding"
(or (>= i (length b))
(null (position (logxor 1 (aref b i)) ;bit 'i', "inverted"
b
:start (the fixnum (1+ i)))))))
(setq i (position 1 <long-bit-vector>)) ==> say, 100000
(fills-out-p <long-bit-vector> i)
Given our resolution passed in Hawaii about "tightening" the definition
of the type FIXNUM, the above program is now fully portable. True,
there are still some areas of the type FIXNUM that aren't portable;
but the situation isn't nearly as bad as it was before.
Contrast this with the situation regarding the type FLOAT. Although
there are many aspects of non-portability regarding the _use_ of
floating point numbers, there is no permitted variance in the definition
of the type FLOAT. It is never permissible, for example, for one
implementation to implement the FLOAT datatype as lists of integers,
and another to implement it as some low-level primitive datatype.
Thus if a user's "declaration" (CHECK-TYPE X FLOAT) fails in one
implementation, but works in another, it is not due to an inherent
weakness in the specification of the type FLOAT.
As I pointed out during the Hawaii meeting, the types SIMPLE-BASE-STRING
and SIMPLE-GENERAL-STRING contain all the seeds of disaster that the
original definition of FIXNUM did. I would almost rather not see them
put into the language at all if there isn't some minimal statement of
portability about them. The question is: "Is it worth it to make these
types be part of the portable language?". The answer to that will depend
on whether or not there are serious contenders for "optimization". It
is my current belief that Lucid's optimization strategies for STRINGs are
_not_ particularly dependent on having a distinction between SIMPLE-STRING
and SIMPLE-BASE-STRING. I.e., we considered the problem some time ago,
and decided that we could "swallow" a union type, if necessary, for
SIMPLE-STRING, given that the union was only concerning one of two
primitive element types.
So, now, the question is: What implememtations -- current, or seriously
conceived -- would benefit greatly from a portable definition of the
type SIMPLE-BASE-STRING? Let them come forward now, or for the next
few years hold their peace.
-- JonL --
∂31-Jan-89 1357 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Jan 89 13:57:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 531105; Tue 31-Jan-89 16:53:00 EST
Date: Tue, 31 Jan 89 16:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
To: Jon L White <jonl@lucid.com>
cc: Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8901310923.AA14594@bhopal>
Message-ID: <19890131215325.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Maybe I shouldn't reply to this, since the content doesn't seem to be
directed to me, but on the other hand I was the only non-CC recipient.
Date: Tue, 31 Jan 89 01:23:28 PST
From: Jon L White <jonl@lucid.com>
....
But what I am very leary about is a definition of an important data
type that is too wishy-washy to be portable. SIMPLE-BASE-STRING may be
in this category....
As I pointed out during the Hawaii meeting, the types SIMPLE-BASE-STRING
and SIMPLE-GENERAL-STRING contain all the seeds of disaster that the
original definition of FIXNUM did.
I'm afraid I don't understand your comment. What's inadequately specified
about SIMPLE-BASE-STRING? Is the problem with the SIMPLE part or with
the BASE part, i.e. are you complaining that SIMPLE arrays aren't well
enough specified, or that the BASE-CHARACTER element-type isn't well
enough specified, or something else?
It
is my current belief that Lucid's optimization strategies for STRINGs are
_not_ particularly dependent on having a distinction between SIMPLE-STRING
and SIMPLE-BASE-STRING. I.e., we considered the problem some time ago,
and decided that we could "swallow" a union type, if necessary, for
SIMPLE-STRING, given that the union was only concerning one of two
primitive element types.
I find this rather surprising, although it's really not my place to question
it. You really don't generate just a move.b instruction followed by some kind
of instruction to add in the type bits, on 68000's, for aref of a simple
1-dimensional array of base characters, at highest speed optimization level
and lowest safety optimization level? Instead you generate some kind of type
check followed by branches to either a move.b or a move.l depending on the
string's element type?
Answering the first part is much more important than answering the second
part, in fact maybe I didn't really care about the second part anyway.
∂01-Feb-89 1353 X3J13-mailer Fairfax information and registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Feb 89 13:51:58 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01841g; Wed, 1 Feb 89 13:46:50 PST
Received: by challenger id AA07139g; Wed, 1 Feb 89 13:42:36 PST
Date: Wed, 1 Feb 89 13:42:36 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8902012142.AA07139@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax information and registration form
**PLEASE NOTE DATE CHANGE:
In order to include Subcommittee meetings prior to the Committee meeting, the
Committee meeting start date has been moved from 3/27 to 3/28.
Please let me know ASAP if you are planning to attend and whether you'll be
staying at the Marriott. On Monday I have to confirm the number rooms we
need.
Mailings should be completed by March 15 to avoid the ``two week rule''.
While we will have access to a copier, participants are encouraged to bring
their copies of subcommittee reports to the meeting.
---jan---
X3J13/ISO Meeting
X3J13: 3/27/89 - 3/30/89
ISO: 3/31/89 - 4/1/89
Fairfax, VA
SUBCOMMITTEE MEETINGS:
DATE: 3/27
PLACE: CONTEL (building is now shared with Lockheed and is so marked)
COMMITTEE MEETING:
DATES: 3/28 - 3/30
TIME: 9:00 - 5:00
CITY: Fairfax
PLACE: CONTEL
ADDRESS: 12015 Lee Jackson Highway (Route 50)
Note: We will not have to be escorted by secutity on the first floor,
but we will have to sign out and in again if we leave the building.
(THANKS BOB, for talking to security!)
DIRECTIONS FROM HOTEL: Route 50 West => Fair Oaks Shopping Center ramp
Turn right once in the complex and follow the circle half way around,
turning right into the CONTEL Parking area.
REGISTRATION FEE: $50 Payable to: LUCID, Inc.
HOTEL ACCOMODATIONS:
HOTEL: Marriott Courtyard
ADDRESS: 11220 Lee Jackson Highway, Fairfax, VA 22030 (Route 50)
PHONE: 800/447-7472, 703/273-6161
DIRECTIONS from airport:
Dullus Access Road => first exit, Route 28, turn right, heading south
Route 28 => Route 50 (Lee Jackson Highway) turn left, east towards Washington
Drive 8 1/2 - 9 miles (past Fair Oaks Shopping Center, on right)
The hotel is on the left just after Route 66.
RATE: $72/night
MENTION: "X3J13" for rate
ISO MEETING:
DATES: 3/31 - 4/1
TIME: 9:00 - 5:00
CITY: Fairfax
PLACE: CONTEL
ADDRESS: 12015 Lee Jackson Highway (Route 50)
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13 March 1989 Meeting Registration Form
Please include check for $50.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Phone: ____________________________________________________________
Lunch 3/28: _________ yes _______ no
Lunch 3/29: _________ yes _______ no
Lunch 3/30: _________ yes _______ no
If Subcommitte Room is Needed:
Subcommittee Name? ___________________________
How many people will attend? __________
Meeting time? __________
Length of meeting? __________
∂02-Feb-89 1307 X3J13-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Feb 89 13:07:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03279g; Thu, 2 Feb 89 13:02:01 PST
Received: by bhopal id AA29703g; Thu, 2 Feb 89 13:04:21 PST
Date: Thu, 2 Feb 89 13:04:21 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902022104.AA29703@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM,
Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David A. Moon's message of Tue, 31 Jan 89 16:53 EST <19890131215325.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
re: I'm afraid I don't understand your comment. What's inadequately
specified about SIMPLE-BASE-STRING?
Sorry, I wasn't clear enough here. The phrase used was "wishy-washy",
and it didn't mean that the specification was unclear or something;
rather, it called in question the enforcement of the specification. As
I understand it, it's entirely permissible for one implementation to
merge SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING into one type,
whereas another may make them type-disjoint.
This is a problem not specific to SIMPLE-BASE-STRING etc, but also applies
to any "wishy-washyness" about the disjointedness of types, where
there is good reason to believe that some implementations will truly
utilize that disjointnedness. Recall my comment about the situation
with the FLOAT datatype:
Contrast this with the situation regarding the type FLOAT. Although
there are many aspects of non-portability regarding the _use_ of
floating point numbers, there is no permitted variance in the definition
of the type FLOAT. It is never permissible, for example, for one
implementation to implement the FLOAT datatype as lists of integers,
and another to implement it as some low-level primitive datatype.
Thus if a user's "declaration" (CHECK-TYPE X FLOAT) fails in one
implementation, but works in another, it is not due to an inherent
weakness in the specification of the type FLOAT.
Suppose for the moment that one implementation merges the FLOAT and CONS
datatypes by implementing FLOATs as a list of three integers (such as the
the values returned by integer-decode-float), but another implementation
makes them disjoint as "primitive" types. At first blush, one might want
to dismiss this case as simply an "efficiency" concern for the second
implementation. But consider the problems for someone developing the
following program on the first implementation and delivering it on the
second:
(defun foo (x)
(if (typep x 'float)
(sin x)
(error "Must have a float")))
(foo (list 1 0 1)) ;; knowing that (float 1.0) is ...
This is a valid program in the first implementation, because the list
(1 0 1) is a valid FLOAT in that implementation. But when moving it to
the second implementation, you get a bug. Now, implementing FLOATs as
LISTs may look artificial, but this example exactly parallels one of the
more annoying porting problems that some 3600 users have when going into
virtually any of the stock hardare implementations. See footnote below.
Recall the recent cleanup proposal to "tighten up" the definition of
FIXNUM so that its use will more frequently be portable.
Recall also the recent cleanup issue to tighten the FUNCTION type so
that it is no longer ambiguous with SYMBOL.
Recall also the CLOS need to tighten up the disjointedness of the types
found on CLtL p.31 (along with others too); 88-002R, p.1-17.
Recall the trouble we've had with the ambiguity in the alternatives
for SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT.
Given this long history of misguided permissiveness, and our frequent
need to "tighten things up", don't you think it would a mistake to start
out with the types SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING ambiguous?
You also asked about how Lucid might implement open-coding of SGCHAR and
SBCHAR. This is immaterial. I only meant to say that *if* the character
proposal were to require (or suggest) that SIMPLE-STRING be a union of
two primitive types, we could "swallow" that (possible a little gulping
along the way). Dave Unietis of Lucid, who has been participating in the
Character subcommittees deliberations, will probably make a more detailed
commentary soon as to what we expect of the Character Proposal.
-- JonL --
Footnote:
Actually, the FLOATs-as-LISTs example is of more than passing interest,
because if you change the names appropriately, you will see exactly
the same problem that certain users have when porting code from the 3600
implementation to *any* stock hardware implementation that does serious
open-coding of AREF. Note that the only function I've mentioned is
TYPEP -- not hokey-pokey-adjust-array or whatever; that's why all the
thousands of lines of discussion about adjust-array etc on cl-cleanup are
not germane to the real problem. Focusing on adjust-array can, at best,
emasculate some of its mandated error checking; at worst, it can confuse
some would-be heros into thinking that the type disjointedness in question
is merely a matter of semantics that can cleared up by clever wording.
Make no mistake. The disjointedness is essential to the optimization
strategies of *all* the commercial stock hardware implementations
represented at the Hawaii meeting.
∂03-Feb-89 2333 X3J13-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 23:33:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 23:31:31 PST
Date: 3 Feb 89 23:31 PST
From: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
Line-fold: NO
Message-ID: <890203-233131-2862@Xerox>
This proposal was distributed and passed at the January X3J13 meeting.
Since it had not been emailed before, I am doing so now.
!
Status: Passed, Jan 89 X3J13
Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
References: Array type specifiers, pp. 45-46
Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE,
SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: Version 1, 7-Oct-88, Pierson
Version 2, 13-Jan-89, Pierson (Moon and JonL comments)
Version 3, 13-Jan-89, Pierson (Pitman comments)
Problem description:
In principle, array type specifiers could be used both for declaring
the storage format of the array and for implicitly declaring the types
of the elements held by those arrays. Unfortunately, the current
definition of the meaning of array type specifiers does not explicitly
specify that the latter use of these declarations is legitimate.
Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
Within the lexical scope of an array type declaration, all references
to array elements are assumed to satisfy the exact declared element
type. It is an error if this is ever violated. A compiler may treat
the code within the scope of the array type declaration as if each
access of an array element was surrounded by an appropriate THE form.
Examples:
(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (AREF AN-ARRAY 1) 31) ; OK
(SETF (AREF AN-ARRAY 2) 127) ; Should signal an error
(SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (AREF AN-ARRAY 0)))) ; Declared to be safe
(FROB *ONE-ARRAY*) ; Legal call, should signal an error
(FROM *ANOTHER-ARRAY*) ; Is probably an undetectable error
Note that the above definition of FROB is equivalent to:
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))
Given an implementation in which fixnums are 29 bits but fixnum arrays
are upgraded to signed 32-bit arrays, the following should be compiled
with all fixnum arithmetic:
(DEFUN BUMP-COUNTERS (COUNTERS)
(DECLARE (TYPE (ARRAY FIXNUM *) BUMP-COUNTERS))
(DOTIMES (I (LENGTH COUNTERS))
(INCF (AREF COUNTERS I))))
Test Cases:
TBS
Rationale:
This mandates a useful and commonly expected behavior. It complements
proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
type specifiers as they refer to arrays as a whole.
This proposal is consistent with SYMBOL-MACROLET-DECLARE:ALLOW and
DECLARATION-SCOPE:LEXICAL.
Current practice:
???
Cost to Implementors:
TBS
Cost to Users:
Probably none; while this is technically a change, code that declares
an array to contain one thing and depends on it containing something
else is blatantly buggy.
Cost of non-adoption:
Users will continue to expect declaration syntax to be more useful
than it really is.
Performance impact:
None.
Benefits:
Array type declarations will behave in a more useful and intuitive way.
Aesthetics:
Improved because the meaning of type declarations will coincide more
clearly with their appearance.
Discussion:
Pierson and Pitman support this proposal.
∂05-Feb-89 1020 X3J13-mailer Fairfax and Hotel badness
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 5 Feb 89 10:20:11 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02852; 5 Feb 89 15:45 GMT
Date: Sun, 5 Feb 89 16:02:41 GMT
Message-Id: <13804.8902051602@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Fairfax and Hotel badness
To: Jan Zubkoff <@sail.stanford.edu:jlz@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Wed, 1 Feb 89 13:42:36 PST
> Please let me know ASAP if you are planning to attend and whether you'll be
> staying at the Marriott. On Monday I have to confirm the number rooms we
> need.
I am planning to attend (both X3J13 and ISO) and to stay at the Marriott.
However, some people were saying that some hotel used for the last
Farifax meeting had been undesirable. Was that the Marriott, or was
the Marriott OK?
Is there any way to get around this area without a car?
∂07-Feb-89 1543 X3J13-mailer What-a-Guy!
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Feb 89 15:42:54 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 7 Feb 89 18:24:35 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 7 Feb 89 18:38:45 EST
Received: from godot.think.com by fafnir.think.com; Tue, 7 Feb 89 16:00:53 EST
Received: by godot.think.com; Tue, 7 Feb 89 16:00:48 EST
From: alison@Think.COM
Message-Id: <8902072100.AA18029@godot.think.com>
To: staff@Think.COM
Cc: alison@Think.COM
Subject: What-a-Guy!
Date: Tue, 07 Feb 89 16:00:46 EST
Resent-To: x3j13@sail.stanford.edu
Resent-From: Barry Margolin <barmar@Think.COM>
Resent-Date: Tue, 7 Feb 89 18:40 EST
Resent-Message-Id: <19890207234021.1.BARMAR@OCCAM.THINK.COM>
Congrats to Guy Steele for receiving the 1988 ACM Grace Murray Hopper
Award! Below is a press release written by Jim Adams of the ACM.
*******************************************************************
GUY L. STEELE JR.. RECEIVES 1988 ACM GRACE MURRAY HOPPER AWARD
Dr. Guy Steele Jr., Senior Scientist at the Thinking Machines
Corporation, is the recipient of the 1988 ACM Grace Murray Hopper Award.
The Award will be presented to Dr. Steele on Wednesday, February 22,
1989, at the ACM Computer Science Conference at Louisville, Kentucky, in
recognition of, "his general contributions to the development of Higher
Order Symbolic Programming, principally for his advancement of lexical
scoping in LISP".
Guy L. Steele Jr. has published more than two dozen technical papers on
the subject of the LISP language and its implementation, including a
series with Gerald Jay Sussman that defined the Scheme dialect of LISP.
He is author of co-author of three books: Common LISP: The Language,
(Digital Press, 1984); C: A Reference Manual, (Prentice-Hall, 1984 and
1987); and The Hacker's Dictionary, (Harper & Row, 1983). At Thinking
Machines Corporation, Dr. Steele is responsible for the design and
implementation of parallel programming languages and other systems
software for the Connection Machine computer systems.
Dr. Steele received his A.B. degree in applied mathematics from Harvard
College (1975) and his S.M. and Ph.D. in computer science and artificial
intelligence from M.I.T. in 1977 and 1980, respectively.
The award, named in honor of computer pioneer, Admiral Grace Murray
Hopper, has been given annually since 1971 to recognize young persons
who have made an outstanding technical contribution to the computer
industry while 30 years of age or younger.
*****************************************************************
∂09-Feb-89 0436 X3J13-mailer Preview of things to come from editorial committee
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:35:59 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17564; Thu, 9 Feb 89 04:34:21 PST
Message-Id: <8902091234.AA17564@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:31
To: x3j13@sail.stanford.edu
Subject: Preview of things to come from editorial committee
It's time to begin to come to closure on the standard. I propose we do
this in pieces first, and then finally vote on the document as a whole.
To do this we'll need several letter ballots and of course, votes
at X3J13 meetings. Following are lists of what will be included in the
first two votes. The issue CUT-OFF-DATES contains the complete list
of things we need to agree on, and a proposed segmenting of voting on
those things.
The next few messages you will receive are the issues that will be
included in the letter ballot. Next week I'll send the issues that
are to be voted on at the 3/89 meeting. To access the sections of the
standard that will be voted on: hudson.dec.com, ftp_user merrychristmas,
filenames: letter-ballot-feb-21.dvi, letter-ballot-feb-21.txt. If you
want to build your own .dvi file, you'll need the following files:
s1800.portability-issues, s2300.classes, s2400.slots, s2500.objects,
s6100.introduction, kcamfont.tex, kcmacros.tex, macros2a.tex,
letter-ballot-feb-21.tex (this is the top-level file, the one that
includes all the others).
These files are small enough to be mailed, so let me know if you can't
get FTP access and want to review them before you get them in the letter
ballot. Note that 2.3, 2.4, and 2.5 are just rearrangements of parts of
CLOS Chapter 1. That is why there is such a short review time for them,
presumably we've all just reviewed them.
Letter ballot (2/21/89)
CUT-OFF-DATES
FONTS
ERROR-TERMINOLOGY
TOC
1.8 Portability Issues
2.3 Classes
2.4 Slots
2.5 Objects
6.1 Intro to catalog of tools
3/89 meeting
EXTRA-SYNTAX
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
UNSPECIFIED-DATATYPES
EXTRA-RETURN-VALUES
UNSOLICITED-MESSAGES
MACRO-AS-FUNCTION
CONFORMANCE-POSITION
EXTENSIONS-POSITION
SUBSETTING-POSITION
Chapter 1 - all parts except 1.8 will be voted on separately, then
Chapter 1 as a whole will be voted on.
2.1 Introduction
2.2 Types
5.1 Errors
5.2 Input/Output
5.3 Interface with the Programming Environment
5.4 Generalized Reference
kc
∂09-Feb-89 0440 X3J13-mailer Issue: FONTS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:40:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17692; Thu, 9 Feb 89 04:38:47 PST
Message-Id: <8902091238.AA17692@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:37
To: x3j13@sail.stanford.edu
Subject: Issue: FONTS
Issue: FONTS
References: Working draft of the standard
Category: Clarifiaction
Edit history: 25-JAN-89, Version 1 by Chapman
7-FEB-89, Version 2 by Chapman (added discussion)
Problem Description:
The Common Lisp language description makes use of many commonly-used
English words for both their establish meanings and for special
purposes. Since the standard is required to be unambiguous,
a way was devised to distinguish an English word from special word of the same
name.
Proposal (FONTS:STANDARD)
Following is a list of the types of words that have been chosen for
special fonting and the name of the font used to represent each.
Word type Font name
Objects of type xxx (e.g. symbols) Slanted 10 point
Words in the glossary Italics
Tools in Chapters 6 and 7 Bold 9 point
Words in the keyword package defined by the standard Bold 9 point
Parameters supplied to functions/macros/special forms Sans serif 10 point
Rationale:
If the wording in the standard is unambiguous, users of the
standard will find it much easier to write portable code and
conforming implementations.
Current Practice:
CLtL uses fonting mainly for emphasis and for referring to
parameters in function descriptions.
Adoption Cost:
None.
Benefits:
The English descriptions in the standard will be less ambiguous.
Conversion Cost:
None.
Aesthetics:
The fonts have been reworked several times in order to improve
readability. It still requires some familiarity with the style
in order to discover its utility.
Discussion:
Steele says:
"Looks fine to me."
Rosenking says:
"Lets go with this proposal."
∂09-Feb-89 0444 X3J13-mailer Issue: TOC
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:44:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17758; Thu, 9 Feb 89 04:42:48 PST
Message-Id: <8902091242.AA17758@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:40
To: x3j13@sail.stanford.edu
Subject: Issue: TOC
Issue: TOC
References: Working draft of the standard
Category: Editorial
Edit history: 25-JAN-89, Version 1 by Chapman
Problem Description:
The Table of Contents of the standard has changed several times since
the first one was introduced in November, 1987. One step in finalizing
the standard is to agree on the TOC.
Proposal (TOC:STANDARD)
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions
1.8 Portability Issues
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction
2.2 Types
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation
Chapter 5. Other Topics
CONTENTS
5.1 Errors
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment
Top level loop
Environment inquiry
Time
5.4 Generalized Reference
Chapter 6. Catalog of Tools (A-M)
A-F plus non-alphabetics
G-M
Chapter 7. Catalog of Tools (N-Z)
N-S
T-Z
Rationale:
The current TOC is a result of a year's worth of meetings and many
discussions of the editorial committee. The organization loosely
follows the CLOS chapters 1 and 2 organization by putting the
concepts first, and followed by an alphabetic listing of the
functions/macros/special forms/variables/constants.
The information that deals with data types is organized according to
the Lisp type hierarchy, and a listing of each language element
that is associated with that data type is located at the end
of each data type description in Chapter 2. These listings are
derived from the contents of the chapters in CLtL.
If we come to the conclusion that the standard should be shortened,
Chapters 6 and 7 can be modified to include fewer tools, and section
6.1 can be modified to reflect movement of some of the non-essential
parts of each description to an appendix.
Current Practice:
CLtL, as well as many other Lisp language specifications,
are organized by data types. The Lucid reference manual's chapters
each deal with a data type, but within those chapters, the information
is organized by concepts followed by an alphabetic listing of
language elements.
CLOS chapters 1 and 2 are organized by concepts first and an
alphabetic listing of language elements next.
Adoption Cost:
None.
Benefits:
The data type organization is useful for describing Lisp, and is therefore
used in chapters 2 and 3. However, categorizing
language elements by the data types they are meant to be used with imposes
an unnecessary structure on the document.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂09-Feb-89 0437 X3J13-mailer Issue: CUT-OFF-DATES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:37:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17595; Thu, 9 Feb 89 04:35:56 PST
Message-Id: <8902091235.AA17595@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:33
To: x3j13@sail.stanford.edu
Subject: Issue: CUT-OFF-DATES
Issue: CUT-OFF-DATES
References: Working draft of the standard
Category: Policy
Edit history: 20-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
25-JAN-89, Version 3 by Chapman
7-FEB-89, Version 4 by Chapman
Problem Description:
The X3J13 committee has informally agreed that a 12/89 standard is
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.
Proposal (CUT-OFF-DATES:ESTABLISH)
Item Dates
________________________________________________Final Changes___Letter Ballot__
Format of tool descriptions 11/1/88 2/21/89
Meaning of each item in each tool description 11/1/88 2/21/89
Fonts 2/1/89 2/21/89
Changes via clean-up to existing functions 4/1/89
Adding functions via clean-up 3/15/89
Conformance issues 3/1/89 mtg
Error terms 2/19/89 2/21/89
Changes to TOC 2/19/89 2/21/89
Contents of sections:
Chapter 1. Introduction 4/1/89 mtg
CONTENTS
1.1 Scope, Purpose, and Application 3/1/89 mtg
1.2 Organization of the Document 3/1/89 mtg
1.3 Referenced Publications 3/1/89 mtg
1.4 Definitions 3/1/89 mtg
1.5 Compliance 3/1/89 mtg
1.6 Implementation-defined Features 3/15/89 mtg
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions 3/1/89 mtg
1.8 Portability Issues 2/19/89 2/21/89
Chapter 2. Objects and Types 4/1/89 4/14/89
CONTENTS
2.1 Introduction 3/15/89 mtg
2.2 Types 3/22/89 mtg
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes 2/19/89 2/21/89
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots 2/19/89 2/21/89
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects 2/19/89 2/21/89
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax 4/14/89 5/14/89
CONTENTS
3.1 Character Reader 4/1/89 4/14/89
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax 4/8/89 4/14/89
Chapter 4. Evaluation and Compilation 5/1/89 5/14/89
CONTENTS
4.1 Evaluation Model 4/14/89 5/14/89
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation 4/22/89 5/14/89
Chapter 5. Other Topics 4/1/89 4/14/89
CONTENTS
5.1 Errors 3/15/89 mtg
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output 3/8/89 mtg
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment 3/8/89 mtg
Top level loop
Environment inquiry
Time
5.4 Generalized Reference 3/8/89 mtg
The following sections in the standard:
Chapter 6. Catalog of Tools (A-M) 6/14/89
A-F plus non-alphabetics 4/1/89 4/14/89
G-M 5/1/89 5/14/89
Chapter 7. Catalog of Tools (N-Z) 6/30/89
N-S 6/1/89 6/14/89
T-Z 6/14/89 6/30/89
Glossary 4/1/89 4/14/89
The following will be decided by a letter ballot mailed on 2/21/89:
This list of cut-off-dates (issue CUT-OFF-DATES)
Format of tool descriptions (in Chapters 6 and 7)
Meaning of each item in each tool description (Section 6.1)
Fonts used for distinguishing special words and phrases (issue FONTS)
Error terms (issue ERROR-TERMINOLOGY)
Table of Contents of the standard (issue TOC)
The following sections in the standard:
1.8 Portability Issues
2.3 Classes
2.4 Slots
2.5 Objects
The following will be decided at the 3/89 meeting:
Conformance issues (the issues presented at the 1/89 meeting)
Chapter 1. Introduction (even though all parts have been voted on,
chapter 1 as a whole should be voted on)
The following sections in the standard:
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
1.7 Language Extensions
2.1 Introduction
2.2 Types
5.1 Errors
5.2 Input/Output
5.3 Interface with the Programming Environment
5.4 Generalized Reference
The following will be decided by a letter ballot mailed on 4/14/89:
Chapter 2. Objects and Types (ditto, chapter 1)
Chapter 5. Other Topics (ditto, chapter 1)
Glossary
The following sections in the standard:
3.1 Character Reader
3.2 Object Syntax
Chapter 6, A-F plus non-alphabetics
The following will be decided by a letter ballot mailed on 5/14/89:
Chapter 3. Object Syntax (ditto, chapter 1)
Chapter 4. Evaluation and Compilation (ditto, chapter 1)
The following sections in the standard:
4.2 Compilation
G-M
The following will be decided by a letter ballot mailed on 6/14/89:
Chapter 6. Catalog of Tools (A-M) (ditto, chapter 1)
The following section in the standard:
N-S
The following will be decided by a letter ballot mailed on 6/30/89:
Chapter 7. Catalog of Tools (N-Z) (ditto, chapter 1)
The following section in the standard:
T-Z
All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.
To change these dates, a 2/3 vote of the editorial committee
or a majority vote of X3J13 is required.
Rationale:
In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
Current Practice:
None.
Adoption Cost:
None.
Benefits:
Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
Larry Masinter says:
"There are a couple of areas where I expect some further work that might
impact these dates:
a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues
b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances.
c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left."
Jeff Rosenking says:
I agree with the CUT-OFF-DATES proposal and believe that a
strict adherence to it may allow us to complete the standard in
the desired time frame. If an exception situation arises then
the exception clause may be voted on by the editorial committee
and/or X3J13 as a whole; I think this provides enough room for
modification, if it is needed.
One concern I have is on the cut-off-date for the Format of tool
descriptions. The apparent need to modify (shorten) the standard
will most likely require a change in the tool description format.
I personally favor having the present format that we adopted, if
I was drafting the standard for my own use. BUT, since I am not
the only intended user of this standard and since we are not the
only group (country) I agree that we have to consider the
feelings of all those who may use this document.
I will support a modification to the tool formats to extract the
examples field and put them in a library or appendix section. If
addiontal measures need to be taken to "trim" the standard we may
want to limit the tool formats to just include a DESCRIPTION,
SYNTAX, ARGUMENTS and VALUES field, with the other fieldsput into
supplementary volumes of the standard. Perhaps the Japanese, and
also the Germans, English and French, will provide alternative
methods for making the standard more concise. Their input and
agreement, on ANSI Common LISP, will make the standard much more
valuable.
∂09-Feb-89 0537 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 05:36:52 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA19584; Thu, 9 Feb 89 05:35:16 PST
Message-Id: <8902091335.AA19584@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:56
To: x3j13@sail.stanford.edu
Subject: Issue: ERROR-TERMINOLOGY
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING (including CLtL -> standard conversion)
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code shall not use any constructions
that are prohibited by the standard.
(2) Conforming code shall not depend on extensions
included in an implementation.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necesarily code that does not
do error checking. In many cases it may do less error
checking, but no guarantee that error checking will be
less in unsafe code is expressed or implied.
Implementations are permitted to treat all code as safe
code all the time, by simply ignoring the SAFETY
quality or the entire OPTIMIZE declaration.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not accessible in
the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might or might not be signalled in unsafe code.
Every implementation is required to detect the error at
least in safe code. When the error is not signalled,
the "consequences are undefined" (see below).
Note: The situation which has been identified as an error is
illegal in all implementations, but some implementations
do not actually detect the situation. Conforming code
known to be safe may rely on the error's being signalled.
For example, "an error should be signalled if ENDP is
given a non-list argument."
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The consequences
may range from harmless to fatal. No conforming code can
depend on the results or effects. Conforming code must
treat the results and effects as unpredictable.
In places where the words "must", "must not" or "may
not" are used, then "the consequences are undefined"
if the stated requirement is not met, and no specific
consequence is explicitly stated.
For example: CLtL currently says: (page 69) "Once a
name has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable is an error." This statement would be
transformed to: "Once a name has been declared by
DEFCONSTANT to be constant, any further assignment or
binding of that special variable has undefined consequences."
Note: A result or effect is unpredictable if it might
vary among implementations or separate invocations
within a single implementation. Theh definition of
a harmless effect is difficult to specify precisely.
It is intended that printing error messages on the
stream *ERROR-OUTPUT* or modifying implementation
data during normal operations are harmless. Allocating
storage, invoking a garbage collector, and re-hashing
are prototypicl examples of things that have harmless
effects. In general, an effect is harmless is if does
not cause the implementation to halt or otherwise enter
an inconsistent state.
An effect is fatal if it causes the implementation to
halt or destroys user, implementation, or system data.
For example, leaving the file system in an inconsistent
state is considered fatal. Other unpredictable effects
include entering the debugger or destroying a user data
structure.
If code depends on a harmless effect, then the result
can be fatal. This is why conforming code may not
depend on such effects.
Implementations are permitted to do anything in this
situation.
RETURN VALUES ARE UNDEFINED Only the number and nature of the return values
of a construct are not well defined but any side-effect
and transfer-of-control behavior is well defined. For
example, if the return values of some function F are
undefined, then an expression such as
(length (list (F))) is still well-defined because it
does not rely on any particular aspect of the value or
values returned by F.
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the results
and effects of this situation as unpredictable but
harmless. For example, ``the consequences of the garbage
collector when invoked are unspecified.''
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat
the situation in ANY ONE of the following ways:
(1)When the situation occurs, an error is signalled at
least in safe code,
OR
(2)When the situation occurs, the "consequences are
undefined",
OR
(3)When the situation occurs, the consequences are
defined.
Also, no conforming code can depend on the results or
effects of this situation, and all conforming code must
treat the results and effects of the situation as
undefined. Implementations are permitted to do anything
in this situation. For example, "implementations may be
extended to define other type specifiers to have a
corresponding class."
Note: Users should consult the implementation reference
manual to determine the results or effects of this
situation, but should never depend on the results or
effects of this situation in code to be run on other
implementations.
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
WARNING IS ISSUED A warning is issued, as described in WARN, in both safe
and unsafe code and when the situation is detected by
the compiler. Conforming code may rely on the fact
that a warning will be issued in both safe and unsafe
code and when the situation is detected by the compiler.
Every implementation is required to detect this
situation in both safe and unsafe code and when the
situation is detected by the compiler. The presence of
a warning will in no way alter the value returned by
the form which caused the situation to occur. For
example, "a warning is issued by the compiler if a
declaration specifier is not one of those defined in
Chapter 9 of CLtL and has not been declared in a
DECLARATION declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not rely
on the fact that a warning will be issued. If the
situation is detected by the compiler, a warning may or
may not be issued, depending on the implementation.
The presence of a warning will in no way alter the
value returned by the form which caused the situation
to occur. For example, (paraphrasing from CLtL, p. 160)
"a warning should be issued by a compiler if a variable
declared to be ignored is ever referred to or is also
declared special, or if a variable is lexical, never
referred to, and not declared to be ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
Rationale:
For the standard to be an exact specification, terminology must be
defined and agreed upon.
Current Practice:
CLtL uses "is signalled", "should be signalled", "is an error",
"a warning is issued", and "a warning should be issued".
It also uses "is not permitted", "is desireable that", "is not legitimate",
"is illegal", and "should be" (not associated with "signalled"),
"must be", "must not", as well as other such terms.
The definition of "is an error" in CLtL has come to mean "is
allowed" in places where implementations typically extend the language.
CLOS and the Condition System use "is undefined" "is unspecified",
"may be extended", "free to extend the syntax", and "return values are
undefined".
Adoption Cost:
The cost of adopting this terminology will be mostly associated with the
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").
Benefits:
Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
Barmar comments:
"... I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue."
RPG responds:
"This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.
I doubt we will be able to settle this without fine tuning as we see
the effects in the document."
∂09-Feb-89 0928 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 9 Feb 89 09:28:02 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA18047; Thu, 9 Feb 89 09:28:49 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA17625; Thu, 9 Feb 89 09:25:28 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA18377; Thu, 9 Feb 89 09:28:22 PST
Date: Thu, 9 Feb 89 09:28:22 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8902091728.AA18377@clam.sun.com>
To: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
Subject: Re: Issue: ERROR-TERMINOLOGY
Regarding "CONSEQUENCES ARE UNSPECIFIED": I believe that attempts to
use this concept will just get into trouble.
(The problems I see are with "unspecified side-effects". Unspecified
values are OK.) For one thing, how are we to decide what effects
are harmless? Is changing value of *READ-BASE* harmless? That depends
on the program. Is changing the alue of *READ-BASE* to NIL harmless?
And so on.
The example statement that ``the consequences of the garbage collector
when invoked are unspecified'' has some interest. Perhaps there is an,
exception or two, but in general there should be *no* side-effects from
running the garbage collector, at least none visible to a Lisp program.
It can make sense to specify that certain actions may or may not
have certain side effects, or to specify a range of outcomes, but
that requires a statement in each case. Various cleanup proposals
with "EXPLICITLY-VAGUE" somewhere in their names are of this kind.
My proposal is that the concept and term "CONSEQUENCES ARE UNSPECIFIED"
be deleted from the Common Lisp standard. Any existing uses will have
to be changed. Usually some "explicitly vague" statement is appropriate.
∂09-Feb-89 1008 X3J13-mailer Issue: ERROR-TERMINOLOGY
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
To be more explicit, it is valid to specify what can happen if an illegal
operation is performed. If we are not able to list all such effects, users
can have two questions: Do *I* have to worry about detecting that my
program is about to perform this action because my run will be trashed, or
can I simply let it happen without worry? ``Undefined'' and
``unspecified'' are the terms that anwer these questions.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified. Second, the other clauses in the
definition must be read at the same time as you read the one about
harmless effects: programs that depend on the effects are not conforming.
Because *read-base* is something explicitly to depend upon, any change to
it behind your back is not harmless.
Certainly in the definition of harmless effects we can explicitly
rule out unspecified changes to things like *read-base* (we can enumerate
them if you like).
People seem to feel that if we cannot with mathematical precision define a
term we should not use it. The attitude to head in that direction is good,
but if you want to go all the way, we are sadly many years away from a
suitable draft. When I read the current draft (and CLtL for that matter) I
find that almost every paragraph requires my detailed knowledge of Lisp
(and sometimes Lisp implementation technology) to understand. Therefore,
we cannot hope for a self-contained document.
Cris writes:
``Perhaps there is an, exception or two, but in general there should be
*no* side-effects from running the garbage collector, at least none
visible to a Lisp program.''
One effect that can be detected is the time it takes. In a realtime system,
that can be fatal. This is perhaps the most serious effect whose harmlessness
is debatable.
Finally, we all depend on the implementors to implement harmless effects
all the time. I think it is useful to be able to specify which operations
are allowed to go boom and which must not for their benefit.
I think in Hawaii we agreed informally to look at the draft when it has
more of the uses of these terms in place to determine whether their meanings
are adequate or whether we should drop some or replace them. Let's stick
with that.
-rpg-
∂09-Feb-89 0959 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Feb 89 09:58:54 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 9 Feb 89 12:28:54 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 9 Feb 89 12:54:29 EST
Date: Thu, 9 Feb 89 12:56 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Issue: ERROR-TERMINOLOGY
To: Cris Perdue <cperdue@sun.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <8902091728.AA18377@clam.sun.com>
Message-Id: <19890209175604.9.BARMAR@OCCAM.THINK.COM>
Date: Thu, 9 Feb 89 09:28:22 PST
From: cperdue@sun.com (Cris Perdue)
Regarding "CONSEQUENCES ARE UNSPECIFIED": I believe that attempts to
use this concept will just get into trouble.
(The problems I see are with "unspecified side-effects". Unspecified
values are OK.)
That's why they are categorized differently. We all recognize that
unspecified values is an easy problem.
For one thing, how are we to decide what effects
are harmless? Is changing value of *READ-BASE* harmless? That depends
on the program. Is changing the alue of *READ-BASE* to NIL harmless?
And so on.
Didn't we go through this once before. The proposal has an informal
definition of "harmless", and that's the best we're going to get. By
its definition, setting the value of *READ-BASE* to any of its allowable
values is harmless; the results of a program may change, but they are
predicted by the language definition. The consequences of setting it to
something that isn't a fixnum from 2 to 36 is undefined, in my opinion,
so it isn't necessarily harmless.
The example statement that ``the consequences of the garbage collector
when invoked are unspecified'' has some interest. Perhaps there is an,
exception or two, but in general there should be *no* side-effects from
running the garbage collector, at least none visible to a Lisp program.
Here are some results of the garbage collector I'd expect in typical
Lisp systems: the output of (ROOM) will change, the order of entries in
EQ/EQL hash tables will change.
It can make sense to specify that certain actions may or may not
have certain side effects, or to specify a range of outcomes, but
that requires a statement in each case. Various cleanup proposals
with "EXPLICITLY-VAGUE" somewhere in their names are of this kind.
My proposal is that the concept and term "CONSEQUENCES ARE UNSPECIFIED"
be deleted from the Common Lisp standard. Any existing uses will have
to be changed. Usually some "explicitly vague" statement is appropriate.
Kathy, are there any uses of it yet? Have you started converting uses
of "is an error" to the new terminology? I think the DEFPACKAGE
proposal may have used the word "unspecified" when describing the
results of executing a DEFPACKAGE for an existing package but with a
conflicting definition, but I don't know whether the author of the
Cleanup proposal intended to be using the new terminology or was just
using the word informally.
barmar
∂09-Feb-89 1059 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 9 Feb 89 10:59:03 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA20436; Thu, 9 Feb 89 11:00:06 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA23021; Thu, 9 Feb 89 10:56:46 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA18461; Thu, 9 Feb 89 10:59:45 PST
Date: Thu, 9 Feb 89 10:59:45 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8902091859.AA18461@clam.sun.com>
To: RPG@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re: Issue: ERROR-TERMINOLOGY
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE, which passed at
the last meeting, I think is a good example of a form of specification
that can be successful. It prescribes a set of things that destructive
operations can do without pinning itself down to just one alternative.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified.
I was trying to ask the question whether changing *read-base* would
be a "harmless" side-effect for some other operation, such as running
the garbage collector. I wasn't meaning to talk about unspecified effects
of an explicit (incf *read-base*).
∂14-Feb-89 0922 X3J13-mailer X3J13/ISO overlap
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Feb 89 09:22:21 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00787g; Tue, 14 Feb 89 09:16:35 PST
Received: by challenger id AA02286g; Tue, 14 Feb 89 09:12:12 PST
Date: Tue, 14 Feb 89 09:12:12 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8902141712.AA02286@challenger>
To: x3j13@sail.stanford.edu
Subject: X3J13/ISO overlap
ISO will be meeting at the following times:
Thursday, 3/30 2:00 - 6:00
Friday, 3/31 9:00 - 5:00
Saturday, 4/1 9:00 - 1:00, if necessary (determined at Friday's meeting)
All meetings will be held at CONTEL.
---jan---
∂14-Feb-89 1226 X3J13-mailer Copying and Equality paper
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89 12:25:55 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 14 Feb 89 15:18:15 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 14 Feb 89 15:20:39 EST
Date: Tue, 14 Feb 89 15:23 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Copying and Equality paper
To: x3j13@sail.stanford.edu
Message-Id: <19890214202339.8.BARMAR@OCCAM.THINK.COM>
Last month I distributed a draft of a paper on Copying and Equality at
the X3J13 meeting, hoping to get comments before I submit it to Lisp
Pointers. I got one verbal comment at the meeting, but I've received
nothing since. I'd like to work on it some more soon, so if you've got
any comments, please send them.
barmar
∂20-Feb-89 0129 X3J13-mailer Issue: SUBSETTING-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Feb 89 01:28:58 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06837; Mon, 20 Feb 89 01:27:08 PST
Message-Id: <8902200927.AA06837@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Feb 89 04:24
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: SUBSETTING-POSITION
Issue: SUBSETTING-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
10-JAN-89, Version 3 by Chapman
20-FEB-89, Version 4 by Chapman
Problem Description:
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and
still be a conforming implementation?
What subsets should be specified in the draft standard we submit to
ANSI?
What position should we take if someone should propose a subset?
Subsets might omit syntax, functions, admissable values or arguments
to functions, or data types. For example, a subset might disallow SPECIAL
declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
to work on proper lists, or might omit complex numbers. Each of these is a
"subset" in the sense that a subset of correct programs for the "full"
language would be correct for the "subset" language.
Subsets can have various levels of "determinability" for programs. The
issue is: how easy is it to tell whether a program written in the "full"
language would run in a "subset" implementation? Except for the
(non-trivial) issue of macro expansions, some subsets are "lexically"
determinable, e.g., if a function is omitted, you can tell if the program
uses it by scanning the program. Some subsets are "dynamically"
determinable, e.g, a subset might signal an error if the :TEST argument to
MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
dynamically determinable, e.g., if the subset implements dynamic extent for
rest lists, it may be impossible to tell even with run-type checks whether
the a program written in the "full" language would conform.
Some "subsets" might be merely restrictive interpretations, e.g., a
"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
BREAK halt the program execution rather than "enter the debugger"; since we
cannot define what "enter the debugger" means, we might want to define
explicitly this subset as a reasonable one for embedded systems.
Proposal (SUBSETTING-POSITION:NONE)
The draft standard we submit to ANSI contains *no* subsets.
In the section on "subsetting" it should be mentioned
that Lisp is a "small" language with a "big" library.
We are not opposed in principle to one or more subset definitions.
Rationale:
We have no well-defined proposals for subset definitions, and didn't have
the time or energy to pursue their definition, or confidence that we could
reach convergence on a reasonable definition.
There are several properties that a subset definition must have to be
considered: it must be well defined in terms of conformance of code, programs,
and implementations; all valid programs in the subset must be valid programs in
the full language; the subset definition should address how it can be
determined if a program in the full language is valid in the subset.
Current Practice:
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However,
the only two levels that were important were the minimum
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another.
The new Fortran language standards committee is
banning subsetting.
At one point, there was an ANSI standard for "Minimal Basic". It was
too minimal. Later work on ANSI Basic involved a rather different-looking
language and a number of optional extensions for such things as real-time process control.
SPARC feels that subsets aren't good for facilitating interchange, but serve the
purpose of allowing timely implementation of the standard.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for making decisions in X3J13.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Jeff Dalton says:
"I'd be happier if it were fairly easy for someone reading the standard
to determine which part was the "library" and which the core language.
For example, where do we find FUNCALL and APPLY?
The draft C standard has an explicit division. Section 3 is
"Language" and section 4 is "Library". It may not be necessary
to go that far for Common Lisp."
GLS says: "I am in agreement with SUBSETTING-POSITION:NONE."
Loosemore says: "... even if the standard doesn't define
any subsets, that is not going to prevent subsets from happening, and
perhaps the standard ought to define some terminology to describe such
implementations (even if it's only to say that they can't call
themselves Common Lisps at all)."
RPG says: "One point worth making might be that a conforming program that is
delivered may not also be a conforming implementation."
Paraphrased:
A conforming implementation does not have to be present in order to deliver
a conforming program.
One could produce a linkable version of an application that would
include almost no part of the Lisp environment.
Therefore, subsets are not mandated for this case.
∂20-Feb-89 1255 X3J13-mailer Re: Issue: SUBSETTING-POSITION
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Feb 89 12:55:32 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA02399; Mon, 20 Feb 89 15:53:31 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01512; Mon, 20 Feb 89 15:51:32 EST
Message-Id: <8902202051.AA01512@mist.>
To: "chapman%aitg.DEC@decwrl.dec.com"@multimax.encore.com
Cc: x3j13@sail.stanford.edu, "skona%csilvax@hub.ucsb.edu"@multimax.encore.com
Subject: Re: Issue: SUBSETTING-POSITION
In-Reply-To: Your message of 20 Feb 89 04:24:00 +0000.
Date: Mon, 20 Feb 89 15:51:29 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I support SUBSETTING-POSITION:NONE in general (though I would still
like to see LOOP be optional :-) ).
However, this brushes on another issue: what to do about well
considered proposals which we generally approve of but don't want to
put in the standard at this time. Chapter 3 of CLOS is possibly the
least controversial member of this class. The OSS/Iterator proposal
and STREAM-INFO are other potential members.
I would very much like to see the standard include an official
appendix containing such features. The wrapper wording for the
appendix would state that these are not part of this Common Lisp
standard but will be considered for future versions of the standard
(note "will be considered", not "will be included"). Implementations
are in no way required to support these features, but if they do, they
should conform to these descriptions as much as possible to avoid
gratuitous incompatibilities. However, we recognize that, since these
features are new and somewhat experimental, it may be unreasonable for
an implementation to precisely conform to the any given description in
the appendix.
While the success of such an appendix will rely a great deal on the
good will of implementors, I believe that it will succeed to a large
extent and that it will make the work of the next standards committee
and the life of Common Lisp users easier.
∂20-Feb-89 1406 X3J13-mailer Issue: CONFORMANCE-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Feb 89 14:06:12 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14009; Mon, 20 Feb 89 14:04:18 PST
Message-Id: <8902202204.AA14009@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Feb 89 16:02
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: CONFORMANCE-POSITION
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
6-FEB-89, Version 5 by Chapman
20-FEB-89, Version 6 by Chapman
Problem Description:
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-PROGRAM)
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
The basic test for conformance will be that code written to the letter
of the standard will run in all "conforming" implementations.
The basic rules are as follows:
. Conforming code uses only the syntax specified in the standard.
. Conforming code is written into a program
in only the sequence specified in the standard.
. Conforming code is written using only the functions, macros,
special forms, variables, constants specified in the standard.
. Conforming implementations provide the functions, macros, special
forms, variables, constants, and arrange that they behave in ways
that conform to the specifications of them in the standard.
The definitions of all other functions, macros, or symbols must accompany
the program. Extensions to syntax are not allowed in conforming programs.
. Conformance will not be machine-checkable.
. Conforming programs will only be defined in terms of their structure.
It's possible for a conformal code to
run in all conformal implementations, but to have allowable
implementation-dependent behavior which could make it non-portable.
Insofar as we allow options in the standard this will be true.
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
Rationale:
The standard must contain information about conformance. Only including
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming programs.
Current Practice:
CLtL generally describes things in terms of what correct code can
expect, but the document itself levies the requirement on an implementation
to support all the described functionality.
dpANS C also defined conformance in terms of programs.
It has further defined both "conforming" and "strictly conforming" programs.
Pascal defines conformance in terms of both, PL/I defines conformance in
terms of conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
Adoption Cost:
None.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂21-Feb-89 0638 X3J13-mailer Updated version of standard available
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 06:38:41 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA03842; Tue, 21 Feb 89 06:36:49 PST
Message-Id: <8902211436.AA03842@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 09:31
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Updated version of standard available
I have put the latest version of the standard on hudson.dec.com
(ftp_user merrychristmas) for your access. Below are informational
comments and directions for building the standard.
Please let me know if you need help.
kathy chapman
How to build the Common Lisp working draft standard
Following are the files you'll need to build the standard and
the method for building the standard.
To build from scratch
1. You'll need to have AM fonts. If you only have CM fonts,
you'll have to wait a month or so until I can get my files
converted to CM fonts.
2. Copy all the files from hudson.dec.com, ftpuser, to your
directory where you plan to do the build. To decrease the
length of time it takes to copy, you don't need any files
with the .dvi or the .ln3 extension. It will be
approximately 9000 blocks.
3. The top level files you'll provide to your TEX processor
are named chapter1.tex, chapter2.tex..., chapter7.tex.
To use .dvi files, copy chapter1.dvi, chapter2.dvi, ...
chapter7.dvi to your host. That's all you need.
Organization of source files (Chapters 1 - 5, concepts)
1. Each section of each chapter is in a separate file.
2. The files are named sxy00.zzz where the letters are as
follows:
s = "s"
x = chapter number
y = section number
00 = "00"
zzz = name of section; most of the time, this is the
complete name; the exception is when the name is too long
for my file system.
3. The files chapter1.tex, chapter2.tex ..., chapter5.tex
contain the information to put the sections together into
chapters.
Organization of source files (Chapters 6 and 7, tool
descriptions)
1. Each function, macro, special form, constant, and variable
(called tools) has its own file.
2. The CLtL files are numbered f001.xxx through f722.xxx
where xxx (can be longer than 3 characters) is the name of
the tool. The tools are ordered alphabetically;
non-alphabetic tool names or parts of tool names generally
precede alphabetic ones.
!
Page 2
3. In some cases the tool's name contains an illegal
character for my file system. In that case you will see
the character spelled out in the filename as follows:
star = "*"
plus = "+"
eqsign = "="
minus = "-"
var = this is the variable of the two tools that have the
same name, e.g. + is a function and + is a variable. The
function + is named "plus" (filename is f005.plus). The
variable + is named "plusvar" (filename is f006.plusvar).
slash = "/"
lessthan = "<"
gtrthan = ">"
4. Starting with f750.xxx are tools that have been added via
clean-up and compiler issues. There is no special
ordering for these tools.
5. Starting with f800.xxx are the tools that are part of the
condition system. They are ordered alphabetically. Many
duplicate tools that are in f001 - f722. Of course the
obsolete versions will be deleted from the directory after
the first review of the condition system has been
completed.
6. Starting with f900.xxx are the tools that are part of
CLOS. They are also ordered alphabetically and there are
also entries that duplicate entries in the f001 - f722
files.
7. The proper files in the proper alphabetic order are
included to be processed in the chapter6.tex and
chapter7.tex files. Also, there are files that group the
tools according to their ordering in CLtL. The files have
names like characters.tex, arrays.tex, ... and correspond
to the chapters in CLtL that contain tool descriptions.
∂21-Feb-89 2149 X3J13-mailer Source for section 1.8
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:46:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09753; Tue, 21 Feb 89 08:08:26 PST
Message-Id: <8902211608.AA09753@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:08
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 1.8
%%Portability Issues
Following is a list of situations which are known to cause portability
problems between implementations:
\beginlist
%% 5.1.4 3
\item{\bull} {\word Macros}
provided by an {\word implementation} may expand
into code that is not portable among differing {\word implementations}.
\item{\bull} {\datatype Floating}-point numbers
\item{\bull} Implementation-dependent sizes
\item{\bull} Conditions
\item{\bull} Declarations
\item{\bull} Files: treatment of {\datatype pathnames}
native syntax, actual
files present
\item{\bull} {\datatype Packages}
\item{\bull} Deliberate non-portability: {\tt #+}, {\tt #-}
\item{\bull} Extended syntax for some
{\word macros} and {\word special forms}, e.g. {\function if}
\item{\bull} Extended argument syntax for some {\word functions},
e.g. non-standard
{\function open} keywords
\item{\bull} Extended functionality of {\word operators} -
allowing arguments not required by the
standard. e.g. {\tt (string pathname)} and {\tt (intern string package-name)}
\item{\bull} Extended {\function format} operations
\item{\bull} File system capabilities
\item{\bull} I/O to a terminal
\endlist
∂21-Feb-89 2155 X3J13-mailer Issue: FONTS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:55:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09577; Tue, 21 Feb 89 08:05:55 PST
Message-Id: <8902211605.AA09577@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:05
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: FONTS
Issue: FONTS
References: Working draft of the standard
Category: Clarifiaction
Edit history: 25-JAN-89, Version 1 by Chapman
7-FEB-89, Version 2 by Chapman (added discussion)
Problem Description:
The Common Lisp language description makes use of many commonly-used
English words for both their establish meanings and for special
purposes. Since the standard is required to be unambiguous,
a way was devised to distinguish an English word from special word of the same
name.
Proposal (FONTS:STANDARD)
Following is a list of the types of words that have been chosen for
special fonting and the name of the font used to represent each.
Word type Font name
Objects of type xxx (e.g. symbols) Slanted 10 point
Words in the glossary Italics
Tools in Chapters 6 and 7 Bold 9 point
Words in the keyword package defined by the standard Bold 9 point
Parameters supplied to functions/macros/special forms Sans serif 10 point
Rationale:
If the wording in the standard is unambiguous, users of the
standard will find it much easier to write portable code and
conforming implementations.
Current Practice:
CLtL uses fonting mainly for emphasis and for referring to
parameters in function descriptions.
Adoption Cost:
None.
Benefits:
The English descriptions in the standard will be less ambiguous.
Conversion Cost:
None.
Aesthetics:
The fonts have been reworked several times in order to improve
readability. It still requires some familiarity with the style
in order to discover its utility.
Discussion:
Steele says:
"Looks fine to me."
Rosenking says:
"Lets go with this proposal."
∂21-Feb-89 2151 X3J13-mailer Feb. 21 Letter Ballot
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:50:56 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09708; Tue, 21 Feb 89 08:07:50 PST
Message-Id: <8902211607.AA09708@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:07
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Feb. 21 Letter Ballot
Digital Equipment Corporation
290 Donald Lynch Blvd.
Marlborough, Mass. 01752
DLB5-2/B10
617-490-8027
Dear Members,
The issues, proposals, and sections of the standard named
below have been mailed to the X3J13 mailing list electronically
and via hardcopy.
The purpose of this ballot is to come to closure on certain
parts of the standard that are either non-controversial, or are
required to be agreed upon before work continues on the standard.
These proposals presumably have been reviewed and debated before
you received this ballot. The nature of the items on this ballot
is that an absolute "no" vote is not possible. If you don't like
the proposals or the sections in the standard, your vote should be
"I" (see below), and you should state your problem and your
proposed fix. If there is a majority of "I" votes, the proposal
or section will be corrected and brought to vote again at the
March meeting. Hopefully that won't be necessary since we have
another 20 or so proposals and sections to vote on at the meeting.
For each proposal and section, please choose one of the
following:
[Y]es: adopt the Proposal or section as is.
[I]f the following condition holds....
[A]bstain
- Who can vote?
Only principals may vote.
- Notes
Your vote must be received by me by March 14, 1989, in
order to be counted.
If you wish to mail your ballot in hardcopy form, please
send it to me at the address in the letterhead.
!
Page 2
- Letter ballot
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | | |
------------------------------------------------------------------------
FONTS | 2 | | | |
------------------------------------------------------------------------
TOC | 1 | | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | | |
------------------------------------------------------------------------
Thanks in advance for reviewing these proposals and sections,
Kathy Chapman
∂21-Feb-89 2153 X3J13-mailer Issue: TOC
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:52:47 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09649; Tue, 21 Feb 89 08:07:07 PST
Message-Id: <8902211607.AA09649@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:06
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: TOC
Issue: TOC
References: Working draft of the standard
Category: Editorial
Edit history: 25-JAN-89, Version 1 by Chapman
Problem Description:
The Table of Contents of the standard has changed several times since
the first one was introduced in November, 1987. One step in finalizing
the standard is to agree on the TOC.
Proposal (TOC:STANDARD)
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions
1.8 Portability Issues
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction
2.2 Types
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation
Chapter 5. Other Topics
CONTENTS
5.1 Errors
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment
Top level loop
Environment inquiry
Time
5.4 Generalized Reference
Chapter 6. Catalog of Tools (A-M)
A-F plus non-alphabetics
G-M
Chapter 7. Catalog of Tools (N-Z)
N-S
T-Z
Rationale:
The current TOC is a result of a year's worth of meetings and many
discussions of the editorial committee. The organization loosely
follows the CLOS chapters 1 and 2 organization by putting the
concepts first, and followed by an alphabetic listing of the
functions/macros/special forms/variables/constants.
The information that deals with data types is organized according to
the Lisp type hierarchy, and a listing of each language element
that is associated with that data type is located at the end
of each data type description in Chapter 2. These listings are
derived from the contents of the chapters in CLtL.
If we come to the conclusion that the standard should be shortened,
Chapters 6 and 7 can be modified to include fewer tools, and section
6.1 can be modified to reflect movement of some of the non-essential
parts of each description to an appendix.
Current Practice:
CLtL, as well as many other Lisp language specifications,
are organized by data types. The Lucid reference manual's chapters
each deal with a data type, but within those chapters, the information
is organized by concepts followed by an alphabetic listing of
language elements.
CLOS chapters 1 and 2 are organized by concepts first and an
alphabetic listing of language elements next.
Adoption Cost:
None.
Benefits:
The data type organization is useful for describing Lisp, and is therefore
used in chapters 2 and 3. However, categorizing
language elements by the data types they are meant to be used with imposes
an unnecessary structure on the document.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂21-Feb-89 2149 X3J13-mailer Source for section 2.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:48:43 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09830; Tue, 21 Feb 89 08:11:18 PST
Message-Id: <8902211611.AA09830@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:09
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 2.4
%% Slots
\beginsubSection{Introduction to Slots}
An {\word object}
that has {\datatype standard-class} as its {\word metaclass} has zero or
more named {\word slots}.
The {\word slots} of an {\word object} are determined by the {\word class}
of the {\word object}. Each {\word slot}
can hold one value. The {\word name} of a {\word slot} is a
{\datatype symbol} that is syntactically valid for use as a variable
name.
When a {\word slot} does not have a value, the {\word slot} is said to be {\bit
unbound}. When an unbound {\word slot} is read, the generic
function {\function slot-unbound} is invoked. The
system-supplied primary {\word method}
for {\function slot-unbound} signals an error.
The default initial value form for a {\word slot}
is defined by the \hbox{{\keyword
:initform}} slot option. When the {\keyword :initform} form is used to
supply a value, it is evaluated in the lexical environment in which
the {\function defclass} form was evaluated. The {\keyword :initform} along with
the lexical environment in which the {\function defclass} form was evaluated
is called a {\bit captured\/} {\keyword :initform}. See the section
``Object Creation and Initialization'' for more details.
A {\bit local slot\/} is defined to be a {\word slot}
that is visible to exactly
one {\word instance},
namely the one in which the {\word slot} is allocated. A {\bit
shared slot\/} is defined to be a {\word slot} that is visible to more than one
{\word instance} of a given {\word class} and its {\word subclasses}.
A {\word class} is said to define a {\word slot} with a given {\word name} when
the {\function defclass} form for that {\word class}
contains a {\word slot} specifier with
that {\word name}.
Defining a {\word local slot} does not immediately create a {\word slot};
it causes a {\word slot} to be created each time an
{\word instance} of the {\word class} is
created. Defining a {\word shared slot} immediately creates a {\word slot}.
The {\keyword :allocation} slot
option to {\function defclass} controls the kind
of {\word slot} that is defined.
If the value of the {\keyword :allocation} slot
option is {\keyword :instance}, a {\word local slot} is created.
If the value of
{\keyword :allocation} is {\keyword :class}, a {\word shared slot} is created.
A {\word slot} is said to be {\bit accessible\/} in an {\word instance}
of a {\word class} if
the {\word slot} is defined by the {\word class}
of the {\word instance} or is inherited from
a {\word superclass} of that {\word class}.
At most one {\word slot} of a given {\word name} can be
{\word accessible} in an {\word instance}.
A {\word shared slot} defined by a {\word class} is
{\word accessible} in all {\word instances}
of that {\word class}.
A detailed explanation of
the inheritance of {\word slots} is given in the section ``Inheritance of
Slots and Slot Options.''
\endsubSection%{Slots}
\beginsubSection{Accessing Slots}
{\word Slots} can be accessed in two ways: by use of the primitive function
{\function slot-value} and by use of {\word generic functions}
generated by the {\function
defclass} form.
The function {\function slot-value} can
be used with any of the {\word slot} names
specified in the {\function defclass} form to access a specific {\word slot}
{\word accessible} in an {\word instance} of the given {\word class}.
The macro {\function defclass} provides
syntax for generating {\word methods} to
read and write {\word slots}.
If a reader {\word method} is requested, a {\word method} is
automatically generated for reading the value of the {\word slot}, but no
{\word method} for storing a value into it is generated. If a writer {\word
method}
is requested, a {\word method} is automatically generated for storing a value
into the {\word slot}, but no {\word method}
for reading its value is generated. If
an accessor {\word method} is requested,
a {\word method} for reading the value of
the {\word slot} and a {\word method}
for storing a value into the {\word slot} are
automatically generated. Reader and writer {\word methods} are implemented
using {\function slot-value}.
When a reader or writer {\word method} is specified for a
{\word slot}, the name of the
{\word generic function} to which the generated {\word method} belongs is directly
specified. If the {\word name}
specified for the writer {\word method} is the symbol
{\tt name}, the {\word name} of the {\word generic function}
for writing the {\word slot}
is the symbol {\tt name}, and the {\word generic function} takes two
arguments: the new value and the {\word instance}, in that order. If the
{\word name}
specified for the accessor {\word method}
is the symbol {\tt name}, the
{\word name} of the {\word generic function} for reading the {\word slot}
is the symbol {\tt
name\/}, and the {\word name} of the {\word generic function} for writing the
{\word slot} is
the list {\tt (setf name)}.
A {\word generic function}
created or modified by supplying reader, writer, or
accessor {\word slot} options can be treated exactly as an ordinary
{\word generic function}.
Note that {\function slot-value} can be used to read or write the value of a
{\word slot} whether or not reader or writer {\word methods}
exist for that {\word slot}.
When {\function slot-value} is used, no reader or writer {\word methods} are
invoked.
The macro {\function with-slots} can be used to establish a lexical
environment in which specified {\word slots}
are lexically available as if they
were variables. The
macro {\function with-slots} invokes the function {\function
slot-value} to access the specified {\word slots}.
The macro {\function with-accessors} can be used to establish a lexical
environment in which specified {\word slots} are lexically available through
their accessors as if they were variables. The macro {\function
with-accessors} invokes the appropriate accessors to access the
specified {\word slots}.
Any accessors specified by {\function with-accessors} must
already have been defined before they are used.
\endsubSection%{Accessing Slots}
\beginsubsubsection{Inheritance of Slots and Slot Options}
The set of the {\word names} of all {\word slots}
{\word accessible} in an {\word instance} of a {\word class}
$C$ is the union of the sets of {\word names} of {\word slots}
defined by $C$ and its
{\word superclasses}. The structure of an {\word instance}
is the set of {\word names}
of {\word local slots} in that {\word instance}.
In the simplest case, only one {\word class} among $C$ and its
{\word superclasses}
defines a {\word slot} with a given {\word slot} name.
If a {\word slot} is defined by a
{\word superclass} of $C$\negthinspace, the {\word slot} is said to be
inherited. The characteristics of the {\word slot} are determined by the
{\word slot} specifier of the defining {\word class}.
Consider the defining {\word class} for
a slot $S$\negthinspace. If the value of the {\keyword :allocation}
slot
option is {\tt :instance}, then $S$ is a {\word local slot} and each
{\word instance}
of $C$ has its own {\word slot} named $S$ that stores its own value. If the
value of the {\keyword :allocation} slot
option is {\tt :class}, then $S$
is a {\word shared slot}, the {\word class}
that defined $S$ stores the value, and all
{\word instances} of $C$ can access that single {\word slot}.
If the {\keyword
:allocation} slot option is omitted, {\tt :instance} is used.
In general, more than one {\word class} among $C$ and its
{\word superclasses} can
define a {\word slot} with a given {\word name}.
In such cases, only one {\word slot} with
the given name is {\word accessible} in an {\word instance}
of $C$\negthinspace, and
the characteristics of that {\word slot} are
a combination of the several {\word slot}
specifiers, computed as follows:
\beginlist
\itemitem{\bull} All the {\word slot}
specifiers for a given {\word slot} name are ordered
from most specific to least specific, according to the order in $C$'s
{\word class precedence list} of the {\word classes}
that define them. All references
to the specificity of {\word slot} specifiers immediately below refers to this
ordering.
\itemitem{\bull} The allocation of a {\word slot}
is controlled by the most specific
{\word slot} specifier. If
the most specific {\word slot} specifier does not contain an
{\keyword :allocation} slot option, {\tt
:instance} is used. Less specific
{\word slot} specifiers do not affect the allocation.
\itemitem{\bull} The default initial value form for a
{\word slot}
is the value of the {\keyword :initform} slot option in the most
specific {\word slot} specifier that contains one. If no {\word slot} specifier
contains an {\keyword :initform} slot option, the {\word slot}
has no default
initial value form.
\itemitem{\bull} The contents of a {\word slot} will always be of type {\tt
(and} $T\sub 1$ $\ldots$ $T\sub n${\tt )} where $T\sub 1 \ldots T\sub n$ are
the values of the {\keyword :type} slot options contained
in all of the {\word slot}
specifiers. If no {\word slot}
specifier contains the {\keyword :type} slot option, the
contents of the {\word slot} will always be of type {\datatype t}. The result
of attempting to store in a {\word slot}
a value that does not satisfy the {\word type} of the {\word slot} is undefined.
\itemitem{\bull} The set of initialization arguments that initialize a given
{\word slot} is the union of the initialization arguments declared in the {\keyword
:initarg} slot options in all the {\word slot} specifiers.
\itemitem{\bull} The documentation string for a {\word slot} is the value of the
{\keyword :documentation} slot option
in the most specific {\word slot} specifier
that contains one. If no {\word slot} specifier contains a {\keyword
:documentation} slot option, the {\word slot} has no documentation string.
\endlist
A consequence of the allocation rule is that a {\word shared slot} can be
{\word shadowed}. For example, if a class $C\sub 1$ defines
a {\word slot} named $S$
whose value for the {\keyword :allocation} slot option is {\tt :class},
that {\word slot} is {\word accessible}
in {\word instances} of $C\sub 1$ and all of its
{\word subclasses}. However, if $C\sub 2$ is a {\word subclass}
of $C\sub 1$ and also
defines a {\word slot} named $S$\negthinspace, $C\sub 1$'s
{\word slot} is not shared
by {\word instances} of $C\sub 2$ and its {\word subclasses}. When a class
$C\sub 1$ defines a {\word shared slot}, any subclass $C\sub 2$ of $C\sub
1$ will share this single {\word slot}
unless the {\function defclass} form for
$C\sub 2$ specifies a {\word slot} of the same
{\word name} or there is a {\word superclass}
of $C\sub 2$ that precedes $C\sub 1$ in the {\word class precedence list} of
$C\sub 2$ that defines a {\word slot} of the same name.
A consequence of the type rule is that the value of a {\word slot} satisfies
the type constraint of each {\word slot} specifier that contributes to that
{\word slot}. Because the result of attempting to store in a
{\word slot} a value
that does not satisfy the type constraint for the {\word slot} is undefined,
the value in a {\word slot} might fail to satisfy its type constraint.
The {\keyword :reader}, {\keyword :writer}, and {\keyword :accessor}
slot options
create {\word methods} rather than define the characteristics of a {\word
slot}.
Reader and writer {\word methods} are inherited in the sense described in
the section ``Inheritance of Methods.''
{\word Methods} that access {\word slots}
use only the name of the {\word slot} and the {\word type}
of the {\word slot's} value. Suppose a {\word superclass}
provides a {\word method} that
expects to access a {\word shared slot} of a given {\word name},
and a {\word subclass} defines
a {\word local slot} with the same {\word name}.
If the {\word method} provided by the
{\word superclass}
is used on an {\word instance} of the {\word subclass},
the {\word method} accesses
the {\word local slot}.
∂21-Feb-89 2201 X3J13-mailer Issue: CUT-OFF-DATES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:00:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09483; Tue, 21 Feb 89 08:05:05 PST
Message-Id: <8902211605.AA09483@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:04
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: CUT-OFF-DATES
Issue: CUT-OFF-DATES
References: Working draft of the standard
Category: Policy
Edit history: 20-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
25-JAN-89, Version 3 by Chapman
7-FEB-89, Version 4 by Chapman
Problem Description:
The X3J13 committee has informally agreed that a 12/89 standard is
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.
Proposal (CUT-OFF-DATES:ESTABLISH)
Item Dates
________________________________________________Final Changes___Letter Ballot__
Format of tool descriptions 11/1/88 2/21/89
Meaning of each item in each tool description 11/1/88 2/21/89
Fonts 2/1/89 2/21/89
Changes via clean-up to existing functions 4/1/89
Adding functions via clean-up 3/15/89
Conformance issues 3/1/89 mtg
Error terms 2/19/89 2/21/89
Changes to TOC 2/19/89 2/21/89
Contents of sections:
Chapter 1. Introduction 4/1/89 n/a
CONTENTS
1.1 Scope, Purpose, and Application 3/1/89 mtg
1.2 Organization of the Document 3/1/89 mtg
1.3 Referenced Publications 3/1/89 mtg
1.4 Definitions 3/1/89 mtg
1.5 Compliance 3/1/89 mtg
1.6 Implementation-defined Features 3/15/89 mtg
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions 3/1/89 mtg
1.8 Portability Issues 2/19/89 2/21/89
Chapter 2. Objects and Types 4/1/89 4/14/89
CONTENTS
2.1 Introduction 3/15/89 mtg
2.2 Types 3/22/89 mtg
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes 2/19/89 2/21/89
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots 2/19/89 2/21/89
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects 2/19/89 2/21/89
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax 4/14/89 5/14/89
CONTENTS
3.1 Character Reader 4/1/89 4/14/89
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax 4/8/89 4/14/89
Chapter 4. Evaluation and Compilation 5/1/89 5/14/89
CONTENTS
4.1 Evaluation Model 4/14/89 5/14/89
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation 4/22/89 5/14/89
Chapter 5. Other Topics 4/1/89 4/14/89
CONTENTS
5.1 Errors 3/15/89 mtg
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output 3/8/89 mtg
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment 3/8/89 mtg
Top level loop
Environment inquiry
Time
5.4 Generalized Reference 3/8/89 mtg
Chapter 6. Catalog of Tools (A-M) 6/14/89
A-F plus non-alphabetics 4/1/89 4/14/89
G-M 5/1/89 5/14/89
Chapter 7. Catalog of Tools (N-Z) 6/30/89
N-S 6/1/89 6/14/89
T-Z 6/14/89 6/30/89
Glossary 4/1/89 4/14/89
The following will be decided by a letter ballot mailed on 2/21/89:
This list of cut-off-dates (issue CUT-OFF-DATES)
Table of Contents of the standard (issue TOC)
Error terms (issue ERROR-TERMINOLOGY)
Fonts used for distinguishing special words and phrases (issue FONTS)
The following sections in the standard:
1.8 Portability Issues
2.3 Classes
2.4 Slots
2.5 Objects
6.1 Introduction (Format and meaning of tool descriptions in Chapters 6
and 7)
The following will be decided at the 3/89 meeting:
Conformance issues (the issues presented at the 1/89 meeting)
Chapter 1. Introduction (even though all parts have been voted on,
chapter 1 as a whole should be voted on)
The following sections in the standard:
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
1.7 Language Extensions
2.1 Introduction
2.2 Types
5.1 Errors
5.2 Input/Output
5.3 Interface with the Programming Environment
5.4 Generalized Reference
The following will be decided by a letter ballot mailed on 4/14/89:
Chapter 2. Objects and Types (ditto, chapter 1)
Chapter 5. Other Topics (ditto, chapter 1)
Glossary
The following sections in the standard:
3.1 Character Reader
3.2 Object Syntax
Chapter 6, A-F plus non-alphabetics
The following will be decided by a letter ballot mailed on 5/14/89:
Chapter 3. Object Syntax (ditto, chapter 1)
Chapter 4. Evaluation and Compilation (ditto, chapter 1)
The following sections in the standard:
4.2 Compilation
G-M
The following will be decided by a letter ballot mailed on 6/14/89:
Chapter 6. Catalog of Tools (A-M) (ditto, chapter 1)
The following section in the standard:
N-S
The following will be decided by a letter ballot mailed on 6/30/89:
Chapter 7. Catalog of Tools (N-Z) (ditto, chapter 1)
The following section in the standard:
T-Z
All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.
To change these dates, a 2/3 vote of the editorial committee
or a majority vote of X3J13 is required.
Rationale:
In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
Current Practice:
None.
Adoption Cost:
None.
Benefits:
Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
Larry Masinter says:
"There are a couple of areas where I expect some further work that might
impact these dates:
a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues
b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances.
c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left."
Jeff Rosenking says:
I agree with the CUT-OFF-DATES proposal and believe that a
strict adherence to it may allow us to complete the standard in
the desired time frame. If an exception situation arises then
the exception clause may be voted on by the editorial committee
and/or X3J13 as a whole; I think this provides enough room for
modification, if it is needed.
One concern I have is on the cut-off-date for the Format of tool
descriptions. The apparent need to modify (shorten) the standard
will most likely require a change in the tool description format.
I personally favor having the present format that we adopted, if
I was drafting the standard for my own use. BUT, since I am not
the only intended user of this standard and since we are not the
only group (country) I agree that we have to consider the
feelings of all those who may use this document.
I will support a modification to the tool formats to extract the
examples field and put them in a library or appendix section. If
addiontal measures need to be taken to "trim" the standard we may
want to limit the tool formats to just include a DESCRIPTION,
SYNTAX, ARGUMENTS and VALUES field, with the other fieldsput into
supplementary volumes of the standard. Perhaps the Japanese, and
also the Germans, English and French, will provide alternative
methods for making the standard more concise. Their input and
agreement, on ANSI Common LISP, will make the standard much more
valuable.
∂21-Feb-89 2201 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:01:42 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09435; Tue, 21 Feb 89 08:04:17 PST
Message-Id: <8902211604.AA09435@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:04
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: ERROR-TERMINOLOGY
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
21-FEB-89, Version 5 by Chapman, added van Roggen and RPG comments
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING (including CLtL -> standard conversion)
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code shall not use any constructions
that are prohibited by the standard.
(2) Conforming code shall not depend on extensions
included in an implementation.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necesarily code that does not
do error checking. In many cases it may do less error
checking, but no guarantee that error checking will be
less in unsafe code is expressed or implied.
Implementations are permitted to treat all code as safe
code all the time, by simply ignoring the SAFETY
quality or the entire OPTIMIZE declaration.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not
accessible in the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might or might not be signalled in unsafe code.
Every implementation is required to detect the error at
least in safe code. When the error is not signalled,
the "consequences are undefined" (see below).
Note: The situation which has been identified as an
error is illegal in all implementations, but some
implementations do not actually detect the situation.
Conforming code known to be safe may rely on the
error's being signalled.
For example, "an error should be signalled if ENDP is
given a non-list argument." (Note that there are no
explicit examples of "should signal an error" in
CLtL outside of the Implementation Notes, from which
this example was taken.)
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The consequences
may range from harmless to fatal. No conforming code
can depend on the results or effects. Conforming code
must treat the results and effects as unpredictable.
In places where the words "must", "must not" or "may
not" are used, then "the consequences are undefined"
if the stated requirement is not met, and no specific
consequence is explicitly stated.
For example: CLtL currently says: (page 69) "Once a
name has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable is an error." This statement would be
transformed to: "Once a name has been declared by
DEFCONSTANT to be constant, any further assignment or
binding of that special variable has undefined
consequences."
Note: A result or effect is unpredictable if it might
vary among implementations or separate invocations
within a single implementation. Theh definition of
a harmless effect is difficult to specify precisely.
It is intended that printing error messages on the
stream *ERROR-OUTPUT* or modifying implementation
data during normal operations are harmless. Allocating
storage, invoking a garbage collector, and re-hashing
are prototypicl examples of things that have harmless
effects. In general, an effect is harmless is if does
not cause the implementation to halt or otherwise enter
an inconsistent state.
An effect is fatal if it causes the implementation to
halt or destroys user, implementation, or system data.
For example, leaving the file system in an inconsistent
state is considered fatal. Other unpredictable effects
include entering the debugger or destroying a user data
structure.
If code depends on a harmless effect, then the result
can be fatal. This is why conforming code may not
depend on such effects.
Implementations are permitted to do anything in this
situation.
RETURN VALUES ARE UNSPECIFIED Only the number and nature of the return values
of a construct are not well specifiedbut any
side-effect and transfer-of-control behavior is well
specified. For example, if the return values of some
function F are unspecified, then an expression such as
(length (list (F))) is still well-specified because it
does not rely on any particular aspect of the value or
values returned by F.
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the
results and effects of this situation as unpredictable
but harmless. For example, ``the consequences of the
garbage collector when invoked are unspecified.''
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat
the situation in ANY ONE of the following ways:
(1)When the situation occurs, an error is signalled at
least in safe code,
OR
(2)When the situation occurs, the "consequences are
undefined",
OR
(3)When the situation occurs, the consequences are
defined.
Also, no conforming code can depend on the results or
effects of this situation, and all conforming code must
treat the results and effects of the situation as
undefined. Implementations are permitted to do anything
in this situation. For example, "implementations may be
extended to define other type specifiers to have a
corresponding class."
Note: Users should consult the implementation reference
manual to determine the results or effects of this
situation, but should never depend on the results or
effects of this situation in code to be run on other
implementations.
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
WARNING IS ISSUED A warning is issued, as described in WARN, in both safe
and unsafe code and when the situation is detected by
the compiler. Conforming code may rely on the fact
that a warning will be issued in both safe and unsafe
code and when the situation is detected by the compiler.
Every implementation is required to detect this
situation in both safe and unsafe code and when the
situation is detected by the compiler. The presence of
a warning will in no way alter the value returned by
the form which caused the situation to occur. For
example, "a warning is issued by the compiler if a
declaration specifier is not one of those defined in
Chapter 9 of CLtL and has not been declared in a
DECLARATION declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not rely
on the fact that a warning will be issued. If the
situation is detected by the compiler, a warning may or
may not be issued, depending on the implementation.
The presence of a warning will in no way alter the
value returned by the form which caused the situation
to occur. For example, (paraphrasing from CLtL, p. 160)
"a warning should be issued by a compiler if a variable
declared to be ignored is ever referred to or is also
declared special, or if a variable is lexical, never
referred to, and not declared to be ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
Rationale:
For the standard to be an exact specification, terminology must be
defined and agreed upon.
Current Practice:
CLtL uses "is signalled", "should be signalled", "is an error",
"a warning is issued", and "a warning should be issued".
It also uses "is not permitted", "is desireable that", "is not legitimate",
"is illegal", and "should be" (not associated with "signalled"),
"must be", "must not", as well as other such terms.
The definition of "is an error" in CLtL has come to mean "is
allowed" in places where implementations typically extend the language.
CLOS and the Condition System use "is undefined" "is unspecified",
"may be extended", "free to extend the syntax", and "return values are
undefined".
Adoption Cost:
The cost of adopting this terminology will be mostly associated with the
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").
Benefits:
Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
Barmar comments:
"... I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue."
RPG responds:
"This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.
I doubt we will be able to settle this without fine tuning as we see
the effects in the document."
RPG also says:
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
To be more explicit, it is valid to specify what can happen if an illegal
operation is performed. If we are not able to list all such effects, users
can have two questions: Do *I* have to worry about detecting that my
program is about to perform this action because my run will be trashed, or
can I simply let it happen without worry? ``Undefined'' and
``unspecified'' are the terms that anwer these questions.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified. Second, the other clauses in the
definition must be read at the same time as you read the one about
harmless effects: programs that depend on the effects are not conforming.
Because *read-base* is something explicitly to depend upon, any change to
it behind your back is not harmless.
Certainly in the definition of harmless effects we can explicitly
rule out unspecified changes to things like *read-base* (we can enumerate
them if you like).
People seem to feel that if we cannot with mathematical precision define a
term we should not use it. The attitude to head in that direction is good,
but if you want to go all the way, we are sadly many years away from a
suitable draft. When I read the current draft (and CLtL for that matter) I
find that almost every paragraph requires my detailed knowledge of Lisp
(and sometimes Lisp implementation technology) to understand. Therefore,
we cannot hope for a self-contained document.
∂21-Feb-89 2150 X3J13-mailer Source for section 6.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:50:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09971; Tue, 21 Feb 89 08:12:50 PST
Message-Id: <8902211612.AA09971@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:10
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 6.1
%% 6.1 Introduction
Following is information necessary to read the {\word tool}
descriptions in
this chapter and Chapter 7.
\beginsubSection{Notation}
This specification uses an extended Backus Normal Form (BNF) to
describe the syntax of @clisp. This section discusses the syntax of
BNF expressions. The primary extension used is the following:
$$\lbrack\!\lbrack\, O\,\rbrack\!\rbrack$$
An expression of this form will appear whenever a list of elements is
to be spliced into a larger structure and the elements can appear in
any order. The symbol $O$ represents a description of the syntax of
some number of syntactic elements to be spliced; that description must
be of the form
$$O\sub 1\ \vert\ \ldots\ \vert\ O\sub n$$
\noindent where each $O\sub i$ can be either of the form $S$ or of
the form $S${\rm *}. The expression $\lbrack\!\lbrack
O\,\rbrack\!\rbrack$ means that a list of the form
$$(O\sub{i\sub 1}\ldots O\sub{i\sub j})\quad 1\leq j$$
\noindent is spliced into the enclosing expression, such that if $n \neq m$
and $1\leq n,m\leq j$,
then either $O\sub{i\sub n}\neq O\sub{i\sub m}$
or $O\sub{i\sub n} = O\sub{i\sub m} = Q\sub{k}$, where for some
$1\leq k \leq n$, $O\sub{k}$ is of the form $Q\sub{k}${\rm *}.
For example, the expression
(\hbox{{\tt x}}\ {$\lbrack\!\lbrack$}$\,$\hbox{{\tt A}}$\ $
$\vert\ $\hbox{{\tt B}}{\rm *}$\ \vert\ $\hbox{{\tt C}}$\,$
{$\rbrack\!\rbrack$}$\ $\hbox{{\tt y}})
\noindent means that at most one {\tt A}, any number of {\tt B}'s, and
at most one {\tt C} can occur in any order.
It is a description of any of these:
\screen!
(x y)
(x B A C y)
(x A B B B B B C y)
(x C B A B B B y)
\endscreen!
\noindent but not any of these:
\screen!
(x B B A A C C y)
(x C B C y)
\endscreen!
\noindent In the first case, both {\tt A} and {\tt C} appear too often,
and in the second case {\tt C} appears too often.
An indirection extension is introduced in order to make this
new syntax more readable:
$$\downarrow\!O$$
\noindent If $O$ is a non-terminal symbol, the right-hand side
of its definition is substituted for the entire expression
$\downarrow\negthinspace O$. For example, the following BNF is equivalent to
the BNF in the previous example:
(\hbox{{\tt x}}$\ ${$\lbrack\!\lbrack$}$\downarrow\!O\,$
{$\rbrack\!\rbrack$}$\ $\hbox{{\tt y}})
O::= \hbox{{\tt A}}$\ \vert\ $\hbox{{\tt B}}{\rm *}$\ \vert\ $\hbox{{\tt C}}
The syntax description for a generic function describes the
lambda-list of the generic function itself, while the method
signatures describe the lambda-lists of the defined methods.
The syntax description for a function, macro, or special form
describes its parameters.
\beginsubsubsection{Operator description template}
Each {\word operator}
description contains the following information:
\label Name:
What the {\word operator} is called.
\label Syntax:
How to use the {\word operator} in code. For example:
\Defun {F} {x y {\opt} z \key\ k\/}
\noindent This description indicates that the function {\bf F}
has two required parameters, {\arg x\/} and {\arg y}. In addition,
there is an optional parameter {\arg z\/} and a keyword parameter {\arg
k}.
\label Method Signature (optional):
The description of a generic function includes descriptions of the
methods that are defined on that generic function by the standard. A
method signature is used to describe the parameters and
parameter specializers for each method.
Methods defined for the generic function must be of the form described
by the method signature.
\Defmeth {F} {\paren{x class\/} \paren{y t\/} {\opt} z \key\ k\/}
\noindent This signature indicates that this method on the generic function
{\bf F} has two required parameters, {\arg x\/}, which must be an
instance of the class {\it class}, and {\arg y}, which can be any
object. In addition, there is an optional parameter {\arg z\/} and a
keyword parameter {\arg k}. This signature also indicates that this
method on {\bf F} is a primary method and has no qualifiers.
\label Arguments:
The @clisp\ {\word type} or natural language description of
what arguments the
{\word operator} accepts, and information about defaults for optional
arguments.
For {\word special forms} and {\word macros}, their arguments are not
evaluated unless it is explictly stated in their descriptions that they
are evaluated.
\label Values:
The @clisp\ {\word type} or natural language description of
what is
returned by the operator.
\label Description:
A summary of the {\word operator}
and all intended aspects of the {\word operator}, but does not
necessarily have to include explicit reference to all its arguments.
\label Examples:
Examples of use of the {\word
operator}. These examples
are not part of the standard.
\label Side Effects:
Anything that is changed as a result of the
evaluation of the {\word form} containing this {\word operator}.
\label Affected By:
Anything that can affect the result this
{\word operator} produces.
\label Conditions:
Three kinds of information may appear here:
\beginlist
\item{\bull}
Situations which are detected by the {\word operator} and formally signalled.
\item{\bull}
Conditions which are handled by the {\word operator}.
\item{\bull}
Situations which may be detected by the {\word operator}.
\endlist
This field may not include conditions that could
be signalled by calling {\word operators\/} passed to this {\word operator}
as arguments or through dynamic variables.
\label See Also:
List of references to other parts of the
standard where information pertaining to this {\word operator} exists. This
list is not part of the standard.
\label Notes:
Information pertaining to this {\word operator} not
found elsewhere in this description. This information is not part of
the standard.
\endsubsubsection%{Operator description template}
\beginsubsubsection{Variable description template}
Each {\word variable}
description contains the following information:
\beginlist
\label Name:
What the {\word variable} is called.
\label Description:
A summary of the {\word variable}
and all intended aspects of the {\word variable}, but does not
necessarily include all the fields referenced below it.
\label Examples:
Examples of use of the {\word
variable}.
These examples
are not part of the standard.
\label Affected By:
Anything that can affect the value of this variable
including {\word functions} which bind this variable and
{\word functions} which assign this variable.
\label See Also:
List of references to other parts of the
standard where information pertaining to this {\word variable} exists. This
list is not part of the standard.
\label Notes:
Information pertaining to this {\word variable} not
found elsewhere in this description. This information is not part of
the standard.
\endsubsubsection%{Variable description template}
\beginsubsubsection{Other information}
Following are general notes that apply to Chapter 6.
Any argument that is named by a name appearing in the following
list has the meaning specified in this list.
\beginlist
\itemitem{\args}
The arguments required by a {\word function} (usually supplied as an argument
itself).
\itemitem{\array}
See ``Types''.
\itemitem{\boolean}
The symbol @nil\ or any non-@nil\ value.
\itemitem{\chara}
See ``Types''.
\itemitem{\env}
An implementation-defined {\word object} that carries the environment
information necessary for evaluating certain {\word forms}.
\itemitem{\fill-pointer}
A non-negative {\datatype integer} no larger than the total
number of elements in the {\datatype vector}
(as returned by @Funref[array-dimension]\rm);
it is the number of ``active'' or ``filled-in'' elements in the {\datatype
vector}.
The {\word fill pointer} constitutes the ``active length'' of the {\datatype
vector};
all {\datatype vector} elements whose index is less than the
{\word fill pointer} are
active, and the others are inactive.
{\datatype Vector} elements not in the active region are still considered
part of the {\datatype vector}.
\itemitem{\form}
An {\word operator} and its argument list
which is a data {\word object}
meant to be {\word evaluated} as a program
to produce zero or more {\word values} (which are also data {\word objects}).
\itemitem{\fnc}
Code that produces zero or more {\word values}.
See ``Types''.
\itemitem{\integer}
See ``Types''.
\itemitem{\list}
See ``Types''.
\itemitem{\object}
A data structure.
\itemitem{\pack}
The possible ways a package name can be supplied as an argument.
\itemitem{(or pathname stream string)}
The possible ways a pathname name can be supplied as an argument.
\issue{PATHNAME-STREAM}
\path
\endissue{PATHNAME-STREAM}
\itemitem{\simple-vector}
See ``Types''.
\itemitem{\type-spec}
See ``Type Specifiers''.
\itemitem{\undefined}
The value returned by the {\word form} being described is not defined
by this standard. See ``Errors''.
\itemitem{\vector}
See ``Types''.
\endlist
Following are notes that apply to {\datatype sequence} functions:
\itemitem{1.} The variants formed by adding {\function -if}
and {\function -if-not}
to an {\word operator's} name do not take an item,
but instead a one-argument function,
and elements are tested for satisfying or not satisfying the function.
As an example,
{\tt (remove {\arg item} {\arg sequence})}
Also,
{\tt (remove-if \#'numberp {\arg sequence})}
returns a {\arg sequence} from which all numbers have been removed.
%% 14.0.0 10
\itemitem{2.} An element {\arg x} of a {\datatype sequence}
``satisfies the test'' if any of
the following are true:
%% 14.0.0 11
\beginlist
\itemitem{a.}
A {\word function} not suffixed by {\function -if} or {\function -if-not}
was called,
{\arg testfn} was supplied by the keyword {\keyword test}, and
{\tt (funcall {\arg testfn} {\arg item} (funcall {\arg keyfn} {\arg x}))} is true.
\itemitem{b.}
%% 14.0.0 12
A {\word function} not suffixed by {\function -if} or {\function -if-not}
was called,
{\arg testfn} was supplied by the keyword {\keyword :test-not}, and
{\tt (funcall {\arg testfn} {\arg item} (funcall {\arg keyfn} {\arg x}))} is false.
\itemitem{c.}
%% 14.0.0 13
A {\word function} suffixed by {\function -if } was called, and
{\tt (funcall {\arg predicate} (funcall {\arg keyfn} {\arg x}))} is true.
\itemitem{d.}
%% 14.0.0 14
A {\word function} suffixed by {\function -if-not } was called, and
{\tt (funcall {\arg predicate} (funcall {\arg keyfn} {\arg x}))} is false.
\endlist
In each case {\arg keyfn} is the
value of the {\keyword key} argument.
%% 14.0.0 15
In the following function descriptions,
two elements {\arg x} and {\arg y}
taken from {\datatype sequences} ``match'' if
either of the following holds:
%% 14.0.0 16
\beginlist
\itemitem{a.}
{\arg Testfn} was supplied by {\keyword test}
and
{\tt (funcall {\arg testfn} (funcall {\arg keyfn} {\arg x})
(funcall {\arg keyfn} {\arg y}))} is true.
%% 14.0.0 17
\itemitem{b.}
{\arg Testfn} was supplied by {\keyword test-not}, and
{\tt (funcall {\arg testfn} (funcall {\arg keyfn} {\arg x}) (funcall {\arg keyfn}
{\arg y}))} is false.
\endlist
%% 14.0.0 18
The order of the arguments to {\arg testfn} corresponds
to the order in which those arguments (or the {\datatype sequences} containing
those arguments)
were given to the sequence function.
If a sequence function gives two elements from the same
sequence argument to {\arg testfn}, they are given in the same order in
which they appear in the {\datatype sequence}.
\endlist
The font key to be used in Chapters 6 and 7
is as follows:
\beginlist
\itemitem{\arg Argument}
Used to represent {\word operator} arguments.
\itemitem{\datatype Data-type}
Used to represent @clisp\
{\word data types\/}.
\itemitem{\word Defined word}
Used to represent the words whose
definitions appear in the ``Glossary''.
\itemitem{\function Tools}
Used to represent {\word tools}.
\itemitem{\keyword Keywords}
Used to represent {\word keywords\/}.
\endlist
\endsubsubsection%{Other information}
∂21-Feb-89 2208 X3J13-mailer Source for section 2.5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:07:48 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09989; Tue, 21 Feb 89 08:14:05 PST
Message-Id: <8902211614.AA09989@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:10
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 2.5
%%Objects
\beginsubSection{Object Creation and Initialization}
The generic function {\function make-instance} creates and returns a new
{\word instance} of a {\word class}.
The first argument is a {\word class} or the {\word name} of a
{\word class},
and the remaining arguments form an {\bit initialization argument
list}.
The initialization of a new {\word instance} consists of several distinct
steps, including the following: combining the explicitly supplied
initialization arguments with default values for the unsupplied
initialization arguments, checking the validity of the initialization
arguments, allocating storage for the {\word instance}, filling
{\word slots} with
values, and executing user-supplied {\word methods} that perform additional
initialization. Each step of {\function make-instance} is implemented by a
{\word generic function}
to provide a mechanism for customizing that step. In
addition, {\function make-instance} is itself a {\word generic function}
and thus
also can be customized.
The \OS\ specifies system-supplied primary {\word methods} for each step and
thus specifies a well-defined standard behavior for the entire
initialization process. The standard behavior provides four simple
mechanisms for controlling initialization:
\beginlist
\itemitem{\bull} Declaring a {\datatype symbol}
to be an initialization argument for a
{\word slot}. An initialization argument is declared by using the {\keyword
:initarg} slot
option to {\function defclass}. This provides a mechanism
for supplying a value for a {\word slot} in a call to {\function make-instance}.
\itemitem{\bull} Supplying a default value form for an initialization
argument. Default value forms for initialization arguments are
defined by using the {\keyword :default-initargs} class
option to {\function
defclass}. If an initialization argument is not explicitly provided
as an argument to {\function make-instance}, the default value form is
evaluated in the lexical environment of the {\function defclass} form that
defined it, and the resulting value is used as the value of the
initialization argument.
\itemitem{\bull} Supplying a default initial value form for a {\word slot}.
A
default initial value form for a {\word slot} is defined by using the {\keyword
:initform} slot
option to {\function defclass}. If no initialization
argument associated with that {\word slot}
is given as an argument to {\function
make-instance} or is defaulted by {\keyword :default-initargs}, this
default initial value form is evaluated in the lexical environment of
the {\function defclass} form that defined it, and the resulting value is
stored in the {\word slot}.
The {\keyword :initform} form for a {\word local slot} may be
used when creating an {\word instance}, when updating an
{\word instance} to conform
to a redefined {\word class},
or when updating an {\word instance} to conform to the
definition of a different {\word class}.
The {\keyword :initform} form for a {\word shared
slot} may be used when defining or re-defining the {\word class}.
\itemitem{\bull} Defining {\word methods}
for {\function initialize-instance} and {\function
shared-initialize}. The slot-filling behavior described above is
implemented by a system-supplied primary {\word method} for {\function
initialize-instance} which invokes {\function shared-initialize}. The
generic function {\function shared-initialize} implements the parts of
initialization shared by these four situations: when making an
{\word instance},
when re-initializing an {\word instance}, when updating an {\word instance}
to conform to a redefined {\word class},
and when updating an {\word instance} to
conform to the definition of a different {\word class}. The system-supplied
primary {\word method} for {\function shared-initialize}
directly implements the
slot-filling behavior described above, and {\function initialize-instance}
simply invokes {\function shared-initialize}.
\endlist
\beginsubsubsection{Initialization Arguments}
An initialization argument controls {\word object} creation and
initialization. It is often convenient to use keyword {\datatype symbols}
to name
initialization arguments, but the {\word name} of an initialization argument
can be any {\datatype symbol},
including {\tt nil}. An initialization argument
can be used in two ways: to fill a {\word slot} with a value or to provide an
argument for an initialization {\word method}. A single initialization
argument can be used for both purposes.
An {\bit initialization argument list\/} is a list of alternating
initialization argument names and values. Its structure is identical
to a property list and also to the portion of an argument list
processed for {\keyword \&key} parameters. As in those lists, if an
initialization argument name appears more than once in an
initialization argument list, the leftmost occurrence supplies the
value and the remaining occurrences are ignored. The arguments to
{\function make-instance} (after the first argument) form an {\word initialization
argument list}. Error-checking of initialization argument names is
disabled if the keyword argument pair whose keyword is {\keyword
:allow-other-keys} and whose value is non-{\tt nil} appears in the
{\word initialization argument list}.
An initialization argument can be associated with a {\word slot}.
If the
initialization argument has a value in the {\word initialization argument
list}, the value is stored into the {\word slot}
of the newly created {\word object},
overriding any {\keyword :initform} form associated with the {\word slot}. A
single initialization argument can initialize more than one {\word slot}. An
initialization argument that initializes a {\word shared slot} stores its
value into the {\word shared slot}, replacing any previous value.
An initialization argument can be associated with a {\word method}. When an
{\word object} is created and a particular initialization argument is
supplied, the generic functions {\function initialize-instance}, {\function
shared-initialize}, and {\function allocate-instance} are called with that
initialization argument's name and value as a keyword argument pair.
If a value for the initialization argument is not supplied in the
{\word initialization argument list}, the {\word method's}
{\word lambda-list} supplies a
default value.
Initialization arguments are used in four situations: when making
an {\word instance}, when re-initializing an {\word instance},
when updating an {\word instance} to
conform to a redefined {\word class},
and when updating an {\word instance} to conform
to the definition of a different {\word class}.
Because initialization arguments are used to control the creation and
initialization of an {\word instance} of some particular
{\word class}, we say that an
initialization argument is ``an initialization argument for'' that
{\word class}.
\endsubsubsection%{Initialization Arguments}
\beginsubsubsection{Declaring the Validity of Initialization Arguments}
Initialization arguments are checked for validity in each of the four
situations that use them. An initialization argument may be valid in
one situation and not another. For example, the system-supplied
primary {\word method}
for {\function make-instance} defined for the class {\datatype
standard-class} checks the validity of its initialization arguments
and signals an error if an initialization argument is supplied that is
not declared as valid in that situation.
There are two means for declaring initialization arguments valid.
\beginlist
\itemitem{\bull} Initialization arguments that fill {\word slots}
are declared as
valid by the {\keyword :initarg} slot
option to {\function defclass}. The {\keyword
:initarg} slot
option is inherited from {\word superclasses}. Thus the set of
valid initialization arguments that fill {\word slots} for a {\word class} is the
union of the initialization arguments that fill {\word slots} declared as
valid by that {\word class} and its {\word superclasses}.
Initialization arguments
that fill {\word slots} are valid in all four contexts.
\itemitem{\bull} Initialization arguments that supply arguments to {\word
methods}
are declared as valid by defining those {\word methods}. The keyword name of
each keyword parameter specified in the {\word method's}
{\word lambda-list} becomes
an initialization argument for all {\word classes} for which the {\word
method} is
applicable. Thus {\word method} inheritance controls the set of valid
initialization arguments that supply arguments to {\word methods}. The
{\word generic functions} for which {\word method}
definitions serve to declare
initialization arguments valid are as follows:
\beginlist
\itemitem{--} Making an {\word instance} of a {\word class}:
{\function allocate-instance},
{\function initialize-instance}, and {\function shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when making an {\word instance} of a {\word class}.
\itemitem{--} Re-initializing an {\word instance}: {\function reinitialize-instance}
and {\function shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when re-initializing an {\word instance}.
\itemitem{--} Updating an {\word instance} to conform to a redefined
{\word class}:
{\function update-instance-for-redefined-class} and {\function shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when updating an {\word instance} to conform to a redefined {\word
class}.
\itemitem{--} Updating an {\word instance} to conform to the definition of a
different {\word class}:
{\function update-instance-for-different-class} and {\function
shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when updating an {\word instance} to conform to the definition
of a different {\word class}.
\endlist
\endlist
The set of valid initialization arguments for a {\word class} is the set of
valid initialization arguments that either fill {\word slots} or supply
arguments to {\word methods}, along with the predefined initialization
argument {\keyword :allow-other-keys}. The default value for {\keyword
:allow-other-keys} is {\tt nil}. The meaning of {\keyword
:allow-other-keys} is the same as when it is passed to an ordinary
{\word function}.
\endsubsubsection%{Declaring the Validity of Initialization Arguments}
\beginsubsubsection{Defaulting of Initialization Arguments}
A default value {\word form} can be supplied for an initialization
argument by using the {\keyword :default-initargs} {\word class} option. If an
initialization argument is declared valid by some particular {\word class},
its default value form might be specified by a different {\word class}.
In this case {\keyword :default-initargs} is used to supply a default value
for an inherited initialization argument.
The {\keyword :default-initargs} option is used only to provide default
values for initialization arguments; it does not declare a {\datatype symbol}
as a
valid initialization argument name. Furthermore, the {\keyword
:default-initargs} option is used only to provide default values for
initialization arguments when making an {\word instance}.
The argument to the {\keyword :default-initargs} class
option is a list of
alternating initialization argument names and {\word forms}.
Each {\word form} is the
default value form for the corresponding initialization
argument. The default value {\word form} of an initialization
argument is used and evaluated only if that initialization argument
does not appear in the arguments to {\function make-instance} and is not
defaulted by a more specific {\word class}. The default value {\word form} is
evaluated in the lexical environment of the {\function defclass} form that
supplied it; the resulting value is used as the initialization
argument's value.
The initialization arguments supplied to {\function make-instance} are combined
with defaulted initialization arguments to produce a {\bit
defaulted initialization argument list}. A {\word defaulted initialization
argument list} is a list of alternating initialization argument names and
values in which unsupplied initialization arguments are defaulted and in
which the explicitly supplied initialization arguments appear earlier in
the list than the defaulted initialization arguments. Defaulted
initialization arguments are ordered according to the order in the {\word
class
precedence list} of the {\datatype classes} that supplied the default values.
There is a distinction between the purposes of the {\keyword
:default-initargs} and the {\keyword :initform} options with respect to the
initialization of {\word slots}. The {\keyword :default-initargs}
class option
provides a mechanism for the user to give a default value {\word form}
for an initialization argument without knowing whether the
initialization argument initializes a {\word slot}
or is passed to a {\word method}.
If that initialization argument is not explicitly supplied in a call
to {\function make-instance}, the default value {\word form} is used, just
as if it had been supplied in the call. In contrast, the {\keyword
:initform} slot option provides a mechanism for the user to give a
default initial value form for a {\word slot}. An {\keyword :initform} form is
used to initialize a {\word slot} only if no initialization argument
associated with that {\word slot} is given as an argument to {\function
make-instance} or is defaulted by {\keyword :default-initargs}.
The order of evaluation of default value {\word forms} for initialization
arguments and the order of evaluation of {\keyword :initform} forms are
undefined. If the order of evaluation is important, {\function
initialize-instance} or {\function shared-initialize} {\word methods}
should be used
instead.
\endsubsubsection%{Defaulting of Initialization Arguments}
\beginsubsubsection{Rules for Initialization Arguments}
The {\keyword :initarg} slot option may be specified more than
once for a given {\word slot}.
The following rules specify when initialization arguments may be
multiply defined:
\beginlist
\itemitem{\bull} A given initialization argument can be used to
initialize more than one {\word slot} if the same initialization argument name
appears in more than one {\keyword :initarg} slot option.
\itemitem{\bull} A given initialization argument name can appear
in the {\word lambda-list} of more than one initialization {\word method}.
\itemitem{\bull} A given initialization argument name can
appear both in an {\keyword :initarg} slot option and
in the {\word lambda-list}
of an initialization {\word method}.
\endlist
If two or more initialization arguments that initialize
the same {\word slot}
are given in the arguments to {\function make-instance}, the
leftmost of these initialization arguments in the {\word initialization
argument list} supplies the value, even if the initialization arguments
have different names.
If two or more different initialization arguments that
initialize the same {\word slot} have default values and none is given
explicitly in the arguments to {\function make-instance}, the initialization
argument that appears in a {\keyword :default-initargs} class
option in the
most specific of the {\word classes} supplies the value. If a single {\keyword
:default-initargs} class option specifies two or more initialization
arguments that initialize the same {\word slot} and none is given explicitly
in the arguments to {\function make-instance}, the leftmost in the {\keyword
:default-initargs} class
option supplies the value, and the values of
the remaining default value {\word forms} are ignored.
Initialization arguments given explicitly in the
arguments to {\function make-instance} appear to the left of defaulted
initialization arguments. Suppose that the classes $C\sub 1$ and
$C\sub 2$ supply the values of defaulted initialization arguments for
different {\word slots}, and suppose that $C\sub 1$ is more specific than
$C\sub 2$; then the defaulted initialization argument whose value is
supplied by $C\sub 1$ is to the left of the defaulted initialization
argument whose value is supplied by $C\sub 2$ in the {\word defaulted
initialization argument list}. If a single {\keyword :default-initargs}
class option supplies the values of initialization arguments for two
different {\datatype slots}, the
initialization argument whose value is specified
farther to the left in the {\keyword :default-initargs} class
option appears
farther to the left in the {\word defaulted initialization argument list}.
If a {\word slot} has both an {\keyword :initform} form and an {\keyword
:initarg} slot option, and the initialization argument is defaulted
using {\keyword :default-initargs} or is supplied to {\function make-instance},
the captured {\keyword :initform} form is neither used nor evaluated.
The following is an example of the above rules:
\screen!
(defclass q () ((x :initarg a)))
(defclass r (q) ((x :initarg b))
(:default-initargs a 1 b 2))
\endscreen!
$$\vbox{\halign{\strut#\hfil&\quad\hfil#\hfil&\quad\hfil#\hfil\cr
{}&\bf Defaulted&{}\cr
\bf Form&\bf Initialization Argument List&\bf Contents of Slot\cr
\noalign{\hrule}
{\tt (make-instance 'r)}&{\tt (a 1 b 2)}&{\tt 1}\cr
{\tt (make-instance 'r 'a 3)}&{\tt (a 3 b 2)}&{\tt 3}\cr
{\tt (make-instance 'r 'b 4)}&{\tt (b 4 a 1)}&{\tt 4}\cr
{\tt (make-instance 'r 'a 1 'a 2)}&{\tt (a 1 a 2 b 2)}&{\tt 1}\cr}}$$
\endsubsubsection%{Rules for Initialization arguments}
\beginsubsubsection{Shared-Initialize}
The generic function {\function shared-initialize} is used to fill the {\word
slots}
of an {\word instance}
using initialization arguments and {\keyword :initform}
forms when an {\word instance} is created, when an
{\word instance} is re-initialized,
when an {\word instance}
is updated to conform to a redefined {\word class}, and when
an {\word instance} is updated to conform to a different {\word class}.
It uses
standard {\word method} combination. It takes the following arguments: the
{\word instance} to be initialized, a
specification of a set of {\word names} of {\word slots}
{\word accessible} in that {\word instance}, and any number of initialization
arguments. The arguments after the first two must form an {\word initialization
argument list}.
The second argument to {\function shared-initialize} may be one of the following:
\beginlist
\itemitem{\bull} It can be {\datatype list} of {\word slot} names, which specifies
the set of those {\word slot} names.
\itemitem{\bull} It can be {\tt nil}, which specifies the empty set of
{\word slot} names.
\itemitem{\bull} It can be the symbol {\tt t}, which specifies the set of
all of the {\word slots}.
\endlist
There is a system-supplied primary {\word method} for {\function
shared-initialize} whose first parameter specializer is the class {\datatype
standard-object}. This {\word method} behaves as follows on each {\word
slot},
whether shared or local:
\beginlist
\itemitem{\bull} If an initialization argument in the {\word initialization
argument list} specifies a value for that {\word slot}, that value is stored
into the {\word slot}, even if a value has already been stored in the {\word
slot}
before the {\word method} is run.
The affected {\word slots} are independent of which
{\word slots} are indicated by the second argument to {\function shared-initialize}.
\itemitem{\bull} Any {\word slots}
indicated by the second argument that are still
unbound at this point are initialized according to their {\keyword
:initform} forms. For any such {\word slot}
that has an {\keyword :initform} form,
that {\word form} is evaluated in the
lexical environment of its defining {\function
defclass} form and the result is stored into the {\word slot}.
For example,
if a {\keyword :before} method stores a value in the
{\word slot}, the {\keyword
:initform} form will not be used to supply a value for the {\word slot}. If
the second argument specifies a {\word name} that does not correspond to any
{\word slots} {\word accessible}
in the {\word instance}, the results are unspecified.
\itemitem{\bull} The rules mentioned in the section ``Rules for
Initialization Arguments'' are obeyed.
\endlist
The generic function {\function shared-initialize} is called by the
system-supplied primary {\word methods}
for {\function reinitialize-instance}, {\function
update-instance-for-different-class}, {\function
update-instance-for-redefined-class}, and {\function
initialize-instance}. Thus, {\word methods} can be written for {\function
shared-initialize} to specify actions that should be taken in all of
these contexts.
\endsubsubsection%{Shared-Initialize}
\beginsubsubsection{Initialize-Instance}
The generic function {\function initialize-instance} is called by {\function
make-instance} to initialize a newly created {\word instance}. It uses
standard {\word method} combination. {\word Methods} for {\function
initialize-instance} can be defined in order to perform any
initialization that cannot be achieved with the simple {\word slot}-filling
mechanisms.
During initialization, {\function initialize-instance} is invoked
after the following actions have been taken:
\beginlist
\itemitem{\bull} The {\word defaulted initialization argument list}
has been computed by
combining the supplied {\word initialization argument list} with any
default
initialization arguments for the {\word class}.
\itemitem{\bull} The validity of the {\word defaulted initialization argument
list} has been checked. If any of the initialization arguments has not
been declared as valid, an error is signalled.
\itemitem{\bull} A new {\word instance} whose {\word slots}
are unbound has been created.
\endlist
The generic function {\function initialize-instance} is called with the
new {\word instance} and the defaulted initialization arguments. There is
a system-supplied primary {\word method} for {\function initialize-instance}
whose parameter specializer is the class {\datatype standard-object}. This
{\word method} calls the generic function
{\function shared-initialize} to fill in
the {\word slots} according to the initialization arguments and the {\keyword
:initform} forms for the {\word slots}; the generic function {\function
shared-initialize} is called with the following arguments: the {\word instance},
{\tt t}, and the defaulted initialization arguments.
Note that {\function initialize-instance} provides the {\word defaulted
initialization argument list} in its call to {\function shared-initialize},
so the first step performed by the system-supplied primary {\word method} for
{\function shared-initialize} takes into account both the initialization
arguments provided in the call to {\function make-instance} and the
{\word defaulted initialization argument list}.
{\word Methods} for {\function initialize-instance} can be defined to specify
actions to be taken when an {\word instance} is initialized.
If only {\keyword :after}
methods for {\function initialize-instance} are defined, they will be
run after the system-supplied primary {\word method} for initialization and
therefore will not interfere with the default behavior of {\function
initialize-instance}.
The \OS\ provides two {\word functions} that are useful in the bodies of {\function
initialize-instance} methods. The function {\function slot-boundp}
returns a boolean value that indicates whether a specified {\word slot} has a
value; this provides a mechanism for writing {\keyword :after} methods for
{\function initialize-instance} that initialize {\word slots} only if they have
not already been initialized. The function {\function slot-makunbound}
causes the {\word slot} to have no value.
\endsubsubsection%{INITIALIZE-INSTANCE}
\beginsubsubsection{Definitions of Make-Instance and Initialize-Instance}
The generic function {\function make-instance} behaves as if it were defined as
follows, except that certain optimizations are permitted:
\screen!
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
...
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
(defmethod make-instance ((class-name symbol) &rest initargs)
(apply #'make-instance (find-class class-name) initargs))
\endscreen!
%This is the code:
%(defmethod make-instance ((class standard-class) &rest initargs)
% (setq initargs (default-initargs class initargs))
% (let* ((proto (class-prototype class))
% (methods
% (append
% (compute-applicable-methods #'allocate-instance `(,class))
% (compute-applicable-methods #'initialize-instance `(,proto))
% (compute-applicable-methods #'shared-initialize `(,proto nil)))))
% (unless
% (subsetp
% (let ((keys '()))
% (do ((plist initargs (cddr plist)))
% ((null plist) keys)
% (push (car plist) keys)))
% (union
% (class-slot-initargs class)
% (reduce #'union (mapcar #'function-keywords methods))))
% (error ...)))
% (let ((instance (apply #'allocate-instance class initargs)))
% (apply #'initialize-instance instance initargs)
% instance))
The elided code in the definition of {\function make-instance} checks the
supplied initialization arguments to determine whether an initialization
argument was supplied that neither filled a {\word slot} nor supplied an argument
to an applicable {\word method}.
%This check could be implemented using the generic
%functions ???{\function class-prototype},??? {\function
%compute-applicable-methods}, {\function
%function-keywords}, and ???{\function class-slot-initargs}. ???
%See Chapter~3 for a
%description of this initialization argument check.
The generic function {\function initialize-instance} behaves as if it were
defined as follows, except that certain optimizations are permitted:
\screen!
(defmethod initialize-instance ((instance standard-object) &rest initargs)
(apply #'shared-initialize instance t initargs)))
\endscreen!
These procedures can be customized at either the Programmer Interface level,
the meta-object level, or both.
Customizing at the Programmer Interface level includes using the {\keyword
:initform}, {\keyword :initarg}, and {\keyword :default-initargs} options to
{\function defclass}, as well as defining {\word methods}
for {\function make-instance}
and {\function initialize-instance}. It is also possible to define
{\word methods} for {\function shared-initialize}, which would be invoked by the
generic functions {\function reinitialize-instance}, {\function
update-instance-for-redefined-class}, {\function
update-instance-for-different-class}, and {\function
initialize-instance}.
The meta-object level supports additional
customization.
%by allowing methods to be defined on {\function
%make-instance},
%???{\bf default-initargs}???, and {\function
%allocate-instance}.
%Chapters~2 and~3 document each of these generic
%functions and the system-supplied primary methods.
Implementations are permitted to make certain optimizations to {\function
initialize-instance} and {\function shared-initialize}.
%The
%description of {\bf shared-initialize} in Chapter~2 mentions the
%possible optimizations.
%Because of optimization, the check for valid initialization arguments
%might not be implemented using the generic functions
%???{\function class-prototype},???
%{\function compute-applicable-methods}, {\function
%function-keywords}, and
%???{\function class-slot-initargs}???. In addition,
%methods for the generic function
%???{\function default-initargs},??? and the
%system-supplied primary methods for
%???{\function allocate-instance}???, {\function
%initialize-instance}, and {\function shared-initialize} might not be called on
%every call to {\function make-instance} or might not receive exactly the
%arguments that would be expected.
\endsubsubsection%{Definitions of MAKE-INSTANCE and Initialize-Instance}
\endsubSection%{Object Creation and Initialization}
\beginsubSection{Changing the Class of an Instance}
The function {\function change-class} can be used to change the {\word class}
of an
{\word instance} from its current class,
$C\sub {\hbox{{\prmseven from}}}$, to a
different class, $C\sub {\hbox{{\prmseven to}}}$; it changes the
structure of the {\word instance} to conform to the definition of the class
$C\sub {\hbox{{\prmseven to}}}$.
Note that changing the {\word class} of an {\word instance}
may cause {\word slots} to be
added or deleted.
When {\function change-class} is invoked on an {\word instance},
a two-step updating
process takes place. The first step modifies the structure of
the {\word instance}
by adding new local {\word slots} and discarding local {\word slots} that
are not specified in the new version of the {\word instance}. The second step
initializes the newly added local {\word slots} and performs any other
user-defined actions. These two steps are further described in the two
following sections.
\beginsubsubsection{Modifying the Structure of the Instance}
In order to make the {\word instance} conform to the class $C\sub
{\hbox{{\prmseven to}}}$, {\word local slots} specified by the class $C\sub
{\hbox{{\prmseven to}}}$ that are not specified by the class $C\sub
{\hbox{{\prmseven from}}}$ are added, and {\word local slots} not specified by
the class $C\sub {\hbox{{\prmseven to}}}$ that are specified by the
class $C\sub {\hbox{{\prmseven from}}}$ are discarded.
The values of {\word local slots} specified by both the class $C\sub
{\hbox{{\prmseven to}}}$ and the class $C\sub {\hbox{{\prmseven
from}}}$ are retained. If such a {\word local slot} was unbound, it remains
unbound.
The values of {\word slots} specified as shared in the class $C\sub
{\hbox{{\prmseven from}}}$ and as local in the class $C\sub
{\hbox{{\prmseven to}}}$ are retained.
This first step of the update does not affect the values of any {\word shared
slots}.
\endsubsubsection%{Modifying the Structure of the Instance}
\beginsubsubsection{Initializing Newly Added Local Slots}
The second step of the update initializes the newly added {\word slots} and
performs any other user-defined actions. This step is implemented by
the generic function {\function update-instance-for-different-class}. The
generic function {\function update-instance-for-different-class} is invoked
by {\function change-class} after the first step of the update has been
completed.
The generic function {\function update-instance-for-different-class} is
invoked on two arguments computed by {\function change-class}. The first
argument passed is a copy of the {\word instance} being updated and is an
{\word instance} of the class $C\sub {\hbox{{\prmseven from}}}$; this copy has
{\word dynamic extent} within the generic function {\function change-class}.
The
second argument is the {\word instance} as updated so far by {\function change-class}
and is an {\word instance} of the class $C\sub {\hbox{{\prmseven to}}}$.
The generic function {\function update-instance-for-different-class} also
takes any number of initialization arguments. When it is called by
{\function change-class}, no initialization arguments are provided.
There is a system-supplied primary {\word method} for {\function
update-instance-for-different-class} that has two parameter
specializers, each of which is the class {\datatype standard-object}. First
this {\word method} checks the validity of initialization arguments and
signals an error if an initialization argument is supplied that is not
declared as valid. (See the section ``Declaring the Validity of
Initialization Arguments'' for more information.) Then it calls the
generic function {\function shared-initialize} with the following arguments:
the {\word instance}, a list of {\word names} of the newly added
{\word slots}, and the
initialization arguments it received.
\endsubsubsection%{Initializing Newly added Local Slots}
\beginsubsubsection{Customizing the Change of Class of an Instance}
{\word Methods}
for {\function update-instance-for-different-class} may be defined
to specify actions to be taken when an {\word instance} is updated. If only
{\keyword :after} methods for {\function update-instance-for-different-class} are
defined, they will be run after the system-supplied primary {\word method} for
initialization and will not interfere with the default behavior of
{\function update-instance-for-different-class}. Because no initialization
arguments are passed to {\function update-instance-for-different-class} when
it is called by {\function change-class},
the {\keyword :initform} forms for {\word slots}
that are filled by {\keyword :before} methods for {\function
update-instance-for-different-class} will not be evaluated by {\function
shared-initialize}.
{\word Methods}
for {\function shared-initialize} may be defined to customize {\word class}
redefinition. See the section ``Shared-Initialize'' for more
information.
\endsubsubsection%{Customizing the Change of Class of an Instance}
\endsubSection%{Changing the Classes of an Instance}
\beginsubSection{Reinitializing an Instance}
The generic function {\function reinitialize-instance} may be used to change
the values of {\word slots} according to initialization arguments.
The process of reinitialization changes the values of some {\word slots} and
performs any user-defined actions. It does not modify the structure
of an {\word instance} to add or delete {\word slots},
and it does not use any {\keyword
:initform} forms to initialize {\word slots}.
The generic function {\function reinitialize-instance} may be called
directly. It takes one required argument, the {\word instance}. It also
takes any number of initialization arguments to be used by {\word methods} for
{\function reinitialize-instance} or for {\function shared-initialize}. The
arguments after the required {\word instance} must form an
{\word initialization
argument list}.
There is a system-supplied primary {\word method} for {\function
reinitialize-instance} whose parameter specializer is the class {\datatype
standard-object}. First this {\word method} checks the validity of
initialization arguments and signals an error if an initialization
argument is supplied that is not declared as valid. (See the section
``Declaring the Validity of Initialization Arguments'' for more
information.) Then it calls the generic function {\function
shared-initialize} with the following arguments: the {\word instance}, {\tt
nil}, and the initialization arguments it received.
\beginsubsubsection{Customizing Reinitialization}
{\word Methods} for {\function reinitialize-instance} may be defined to specify
actions to be taken when an {\word instance} is updated.
If only {\keyword :after}
methods for {\function reinitialize-instance} are defined, they will be run
after the system-supplied primary {\word method} for initialization and
therefore will not interfere with the default behavior of {\function
reinitialize-instance}.
{\word Methods} for {\function shared-initialize} may
be defined to customize {\word class}
redefinition. See the section ``Shared-Initialize'' for more
information.
\endsubsubsection%{Customizing Reinitialization}
\endsubSection%{Reinitializing an Instance}
\beginsubSection{Meta-Objects}
The implementation of the \OS\ manipulates {\word classes},
{\word methods}, and {\word generic
functions}.
The \OS\ contains a set of {\word generic
functions} defined by {\word methods} on {\word classes};
the behavior of those {\word generic
functions} defines the behavior of the \OS.
The {\word instances} of the {\word classes}
on which those {\word methods} are defined are called meta-objects.
%Programming
%at the meta-object protocol level involves defining new classes of
%meta-objects along with methods specialized on these classes.
\beginsubSection{Standard Meta-objects}
The \OS\ supplies a set of meta-objects, called standard
meta-objects. These include the class {\datatype standard-object} and
{\word instances} of the classes {\datatype standard-method}, {\datatype
standard-generic-function}, and {\datatype method-combination}.
\beginlist
\itemitem{\bull}
The class {\datatype standard-method} is the default {\word class} of
{\word methods} defined by the forms {\function defmethod}, {\function
defgeneric}, {\function generic-function}, {\function generic-flet}, {\function
generic-labels}, and {\function with-added-methods}.
\itemitem{\bull}
The class {\datatype standard-generic-function} is the default {\word class} of
{\word generic functions} defined by the forms {\function defmethod},
{\function defgeneric}, {\function generic-function}, {\function generic-flet},
{\function generic-labels}, {\function with-added-methods}, and {\function defclass}.
\itemitem{\bull} The {\word class} named {\datatype standard-object}
is an {\word instance} of
the class {\datatype standard-class} and is a {\word superclass}
of every {\word class} that
is an {\word instance} of {\datatype standard-class}
except itself and {\datatype
structure-class}.
\itemitem{\bull} Every {\word method} combination object is an {\word instance}
of a
{\word subclass} of the class {\datatype method-combination}.
\endlist
\endsubSection%{Standard Meta-objects}
\endSection%{Meta-Objects}
∂21-Feb-89 2209 X3J13-mailer Source for section 2.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:09:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09793; Tue, 21 Feb 89 08:11:01 PST
Message-Id: <8902211611.AA09793@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:09
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 2.3
%% Classes
\beginsubSection{Introduction to Classes}
A {\bit class\/} is an {\word object}
that determines the structure and behavior
of a set of other {\word objects}, which are called its {\bit instances}.
A {\word class} can inherit structure and behavior from other {\word classes}.
A {\word class} whose definition refers to other {\word classes}
for the purpose of
inheriting from them is said to be a {\bit subclass\/} of each of
those {\word classes}. The {\word classes} that are designated for purposes of
inheritance are said to be {\bit superclasses\/}
of the inheriting {\word class}.
A {\word class} can have a {\bit name}. The function {\function class-name} takes a
{\word class} object and returns its {\word name}.
The {\word name} of an anonymous {\word class} is
{\tt nil}. A {\datatype symbol}
can {\bit name\/} a {\word class}. The function {\function
find-class} takes a {\datatype symbol} and returns the {\word class} that the
{\datatype symbol}
names. A {\word class} has a {\bit proper name\/} if the
{\word name} is a {\datatype symbol}
and if the {\word name} of the {\word class}
names that {\word class}. That is, a class~$C$ has the {\bit proper
name\/}~$S$ if $S=$ {\tt (class-name $C$)} and $C=$ {\tt (find-class
$S$)}. Notice that it is possible for {\tt (find-class $S\sub 1$)}
$=$ {\tt (find-class $S\sub 2$)} and $S\sub 1\neq S\sub 2$.
If $C=$ {\tt (find-class $S$)}, we say that $C$ is the class named
$S$.
A class $C\sub{1}$ is a direct {\bit superclass\/} of a class
$C\sub{2}$ if $C\sub{2}$ explicitly designates $C\sub{1}$ as a
{\word superclass} in its definition. In this case $C\sub{2}$ is a
direct {\bit subclass\/} of $C\sub{1}$. A class $C\sub{n}$ is a {\bit
superclass\/} of a class $C\sub{1}$ if there exists a series of
classes $C\sub{2},\ldots,C\sub{n-1}$ such that $C\sub{i+1}$ is a
direct {\word superclass} of $C\sub{i}$ for $1 \leq i<n$. In this case,
$C\sub{1}$ is a {\bit subclass\/} of $C\sub{n}$. A {\word class} is
considered neither a {\word superclass} nor a {\word subclass}
of itself. That is, if
$C\sub{1}$ is a {\word superclass} of $C\sub{2}$, then $C\sub{1} \neq
C\sub{2}$. The set of {\word classes} consisting of some given
class $C$ along with all of its {\word superclasses} is called ``$C$ and its
superclasses.''
Each {\word class}
has a {\bit class precedence list}, which is a total ordering
on the set of the given {\word class} and its
{\word superclasses}. The total ordering
is expressed as a list ordered from most specific to least specific.
The {\word class precedence list} is used in several ways. In general, more
specific {\word classes} can {\bit shadow}, or override, features that would
otherwise be inherited from less specific {\word classes}. The
{\word method} selection
and combination process uses the {\word class precedence list} to order
{\word methods}
from most specific to least specific.
When a {\word class} is defined, the order
in which its direct {\word superclasses}
are mentioned in the defining form is important. Each {\word class} has a
{\bit local precedence order\/}, which is a list consisting of the
{\word class} followed by its direct
{\word superclasses} in the order mentioned
in the defining {\word form}.
A {\word class precedence list}
is always consistent with the {\word local precedence
order} of each {\word class} in the list.
The {\word classes} in each {\word local precedence
order} appear within the {\word class precedence list} in the same order. If
the {\word local precedence orders} are inconsistent with each other,
no {\word class
precedence list} can be constructed, and an error is signalled.
The {\word class precedence list} and its computation is discussed
in the section ``Determining the Class Precedence List.''
{\word Classes} are organized into a directed acyclic graph. There are
two distinguished {\word classes},
named {\datatype t} and {\datatype standard-object}.
The {\word class} named {\datatype t} has no {\word superclasses}.
It is a {\word superclass} of
every {\word class} except itself.
The {\word class} named {\datatype standard-object} is
an {\word instance} of
the class {\datatype standard-class} and is a {\word superclass} of
every {\word class} that is an
{\word instance} of {\datatype standard-class} except itself.
There is a mapping from the object system {\word class} space into
the {\word type} space. Many of the standard {\word types}
specified in this document have a corresponding
{\word class} that has the same {\word name} as the
{\word type}. Some {\word types} do
not have a corresponding {\word class}. The integration of
the {\word type} and {\word class}
systems is discussed in the section ``Integrating Types and Classes.''
{\word Classes} are represented by {\word objects} that are themselves
{\word instances} of {\word classes}.
The {\word class} of the {\word class} of an {\word object} is termed
the {\bit metaclass\/} of that {\word object}. When no misinterpretation is
possible, the term {\bit metaclass\/} will be used to refer to a {\word
class}
that has {\word instances} that are themselves
{\word classes}. The {\word metaclass}
determines the form of inheritance used by the {\word classes} that are its
{\word instances} and the representation of the
{\word instances} of those {\word classes}.
The \CLOS\ provides a default {\word metaclass},
{\datatype standard-class}, that is
appropriate for most programs.
%The meta-object protocol provides
%mechanisms for defining and using new metaclasses.
Except where otherwise specified, all {\word classes} mentioned in this
standard are {\word instances} of the
class {\datatype standard-class}, all {\word generic
functions} are {\word instances}
of the class {\datatype standard-generic-function},
and all {\word methods} are {\word instances} of the class {\datatype standard-method}.
\endsubSection%{Classes}
%\beginsubsubsection{Metaclasses}
%??? Is the following paragraph necessary in this specification???
%
%The {\bit metaclass\/} of an object is the class of its class. The
%metaclass determines the representation of instances of its instances and
%the forms of inheritance used by its instances for slot descriptions and
%method inheritance. The metaclass mechanism can be used to provide
%particular forms of optimization or to tailor the \CLOS\ for particular
%uses.
%The protocol for defining metaclasses is discussed in the chapter
%``The \CLOS\ Meta-Object Protocol.''
%\endsubsubsection%{Metaclasses}
\beginsubsubsection{Standard Metaclasses}
The \CLOS\ provides a number of predefined {\word metaclasses}.
These include the
classes {\datatype standard-class}, {\datatype built-in-class}, and {\datatype
structure-class}:
\beginlist
\itemitem{\bull}
The class {\datatype standard-class} is the default {\word class} of
{\word classes} defined
by {\function defclass}.
\itemitem{\bull} The class {\datatype built-in-class} is the {\word class} whose
{\word instances} are {\word classes}
that have special implementations with
restricted capabilities. Any {\word class} that corresponds to a standard
{\word type}
might be an {\word instance} of {\datatype built-in-class}.
The predefined {\word type} specifiers that are required to have
corresponding {\word classes}
are listed in Figure {\chapno--\the\capno}. It is
implementation-dependent
whether each of these {\word classes} is implemented as a
{\datatype built-in-class}.
\itemitem{\bull}
All {\word classes} defined by means of {\function defstruct}
are {\word instances} of
{\datatype structure-class}.
\endlist
\endsubsubsection%{Standard Metaclasses}
\beginsubSection{Defining Classes}
The macro {\function defclass} is used to define a new named {\word class}.
%The
%syntax for {\function defclass} is given in Figure??
The definition of a {\word class} includes:
\beginlist
\itemitem{\bull} The {\word name} of the new {\word class}.
For newly defined {\word classes}
this {\word name} is a proper name.
\itemitem{\bull} The list of the direct {\word superclasses}
of the new {\word class}.
\itemitem{\bull} A set of {\bit slot} specifiers. Each {\word slot} specifier
includes the {\word name} of the {\word slot}
and zero or more {\bit slot} options. A
{\word slot} option pertains only to a single {\word slot}.
If a {\word class} definition
contains two {\word slot}
specifiers with the same {\word name}, an error is signalled.
\itemitem{\bull} A set of {\bit class} options.
Each {\word class} option pertains
to the {\word class} as a whole.
\endlist
The {\word slot}
options and {\word class} options of the {\function defclass} form provide
mechanisms for the following:
\beginlist
\itemitem{\bull} Supplying a default initial value {\word form}
for a given {\word slot}.
\itemitem{\bull} Requesting that {\word methods} for {\word generic functions}
be automatically generated for reading or writing {\word slots}.
\itemitem{\bull} Controlling whether a given {\word slot} is shared by
{\word instances}
of the {\word class} or whether each
{\word instance} of the {\word class} has its own {\word slot}.
\itemitem{\bull} Supplying a set of initialization arguments and initialization
argument defaults to be used in {\word instance} creation.
%\itemitem{\bull} Requesting that a constructor function be automatically
%generated for making instances of the new class.
\itemitem{\bull} Indicating that the {\word metaclass}
is to be other than the default.
\itemitem{\bull} Indicating the expected {\word type}
for the value stored in the {\word slot}.
\itemitem{\bull} Indicating the documentation string for the {\word slot}.
\endlist
\endsubSection%{Defining Classes}
\goodbreak
\beginsubSection{Creating Instances of Classes}
The generic function {\function make-instance} creates and returns a new
{\word instance} of a {\word class}.
The \OS\ provides several mechanisms for
specifying how a new {\word instance} is to be initialized. For example, it
is possible to specify the initial values for {\word slots} in newly created
{\word instances}
either by giving arguments to {\function make-instance} or by
providing default initial values. Further initialization activities
can be performed by {\word methods} written for {\word generic functions}
that are
part of the initialization protocol. The complete initialization
protocol is described in the section ``Object Creation and
Initialization.''
\endsubSection%{Creating Instances of Classes}
\beginsubSection{Inheritance}
A {\word class}
can inherit {\word methods}, {\word slots},
and some {\function defclass} options
from its {\word superclasses}.
The following sections describe the inheritance of
{\word methods}, the inheritance of {\word slots} and {\word slot} options,
and the inheritance of
{\word class} options.
\beginsubsubsection{Inheritance of Class Options}
The {\keyword :default-initargs} class option is inherited. The set of
defaulted initialization arguments for a {\word class} is the union of the
sets of initialization arguments supplied in the {\keyword
:default-initargs} class options of the {\word class} and its
{\word superclasses}.
When more than one default initial value {\word form} is supplied for a given
initialization argument, the default initial value {\word form} that is used
is the one supplied by the {\word class} that is most specific according to
the {\word class precedence list}.
If a given {\keyword :default-initargs} class option specifies an
initialization argument of the same {\word name} more than once, an
error is signalled.
\endsubsubsection%{Inheritance of Class Options}
\beginsubsubsection{Examples}
\screen!
(defclass C1 ()
((S1 :initform 5.4 :type number)
(S2 :allocation :class)))
(defclass C2 (C1)
((S1 :initform 5 :type integer)
(S2 :allocation :instance)
(S3 :accessor C2-S3)))
\endscreen!
Instances of the class {\tt C1} have a {\word local slot}
named {\tt S1}, whose default
initial value is 5.4 and whose value should always be a {\datatype number}.
The class {\tt C1} also has a {\word shared slot} named {\tt S2}.
There is a {\word local slot} named {\tt S1}
in {\word instances} of {\tt C2}. The
default initial value of {\tt S1} is 5. The value of {\tt S1} will be
of type {\tt (and integer number)}. There are also {\word local slots} named
{\tt S2} and {\tt S3} in {\word instances} of {\tt C2}. The class {\tt C2}
has a {\word method} for {\tt C2-S3} for reading the value of slot {\tt S3};
there is also a {\word method} for {\tt (setf C2-S3)} that writes the
value of {\tt S3}.
\endsubsubsection%{Examples of Inheritance}
\endsubSection%{Inheritance}
\beginsubSection{Determining the Class Precedence List}
The {\function defclass} form for a {\word class}
provides a total ordering on that
{\word class} and its direct {\word superclasses}.
This ordering is called the {\bit
local precedence order}. It is an ordered list of the {\word class} and its
direct {\word superclasses}. The {\bit class precedence list\/} for a
class $C$ is a total ordering on $C$ and its {\word superclasses}
that is consistent
with the {\word local precedence orders} for each of $C$ and its
{\word superclasses}.
A {\word class} precedes its direct {\word superclasses}, and a
direct {\word superclass}
precedes all other direct {\word superclasses} specified to
its right in the {\word superclasses}
list of the {\function defclass} form. For
every class $C$, define $$R\sub C=\{(C,C\sub 1),(C\sub 1,C\sub
2),\ldots,(C\sub {n-1},C\sub n)\}$$ where $C\sub 1,\ldots,C\sub n$ are
the direct {\word superclasses} of $C$ in the order in which
they are mentioned in the {\function defclass} form. These ordered pairs
generate the total ordering on the class $C$ and its direct
{\word superclasses}.
Let $S\sub C$ be the set of $C$ and its {\word superclasses}. Let $R$ be
$$R=\bigcup\sub{c\in {S\sub C}}R\sub c$$.
The set $R$ may or may not generate a partial ordering, depending on
whether the $R\sub c$, $c\in S\sub C$, are consistent; it is assumed
that they are consistent and that $R$ generates a partial ordering.
When the $R\sub c$ are not consistent, it is said that $R$ is inconsistent.
%This partial ordering is generated by taking the the transitive
%closure of the set $R\cup \{(c,c) \vert c\in {S\sub C}\}$. When
%$(C\sub 1,C\sub 2)\in R$\negthinspace, it is said that $C\sub 1$
%{\bit precedes or equals} $C\sub 2$. Intuitively, $C\sub 1$ precedes
%or equals $C\sub 2$ when $C\sub 1=C\sub 2$ or $C\sub 2$ is a
%superclass of $C\sub 1$.
%
%Recall that a partial ordering of the set $S$ is a relation between
%objects of $S$ that is transitive, reflexive, and antisymmetric. The
%set $\{(c,c) \vert c\in {S\subC}\}$ was added to the transitive
%closure of the set $R$ in order to make the relation reflexive. In
%the remainder of this section the set of precedence relations $R$ and
%not the partial ordering will be used.
To compute the {\word class precedence list} for~$C$\negthinspace,
topologically sort the elements of $S\sub C$ with respect to the
partial ordering generated by $R$\negthinspace. When the topological
sort must select a {\word class} from a set of two or more
{\word classes}, none of
which are preceded by other {\word classes} with respect to~$R$\negthinspace,
the {\word class} selected is chosen deterministically, as described below.
If $R$ is inconsistent, an error is signalled.
\goodbreak
\beginsubsubsection{Topological Sorting}
Topological sorting proceeds by finding a class $C$ in~$S\sub C$ such
that no other {\word class} precedes that element according to the elements
in~$R$\negthinspace. The class $C$ is placed first in the result.
Remove $C$ from $S\sub C$, and remove all pairs of the form $(C,D)$,
$D\in S\sub C$, from $R$\negthinspace. Repeat the process, adding
{\word classes} with no predecessors to the end of the result. Stop when no
element can be found that has no predecessor.
If $S\sub C$ is not empty and the process has stopped, the set $R$ is
inconsistent. If every {\word class} in the finite set of
{\word classes} is preceded
by another, then $R$ contains a loop. That is, there is a chain of
classes $C\sub 1,\ldots,C\sub n$ such that $C\sub i$ precedes
$C\sub{i+1}$, $1\leq i<n$, and $C\sub n$ precedes $C\sub 1$.
Sometimes there are several {\word classes} from $S\sub C$ with no
predecessors. In this case select the one that has a direct
{\word subclass} rightmost in the {\word class precedence list} computed so far.
%Because a direct superclass precedes all other direct superclasses to
%its right, there can be only one such candidate class.
If there is no
such candidate {\word class}, $R$ does not generate a partial ordering---the
$R\sub c$, $c\in S\sub C$, are inconsistent.
In more precise terms, let $\{N\sub 1,\ldots,N\sub m\}$, $m\geq 2$, be
the {\word classes} from $S\sub C$ with no predecessors. Let $(C\sub
1\ldots C\sub n)$, $n\geq 1$, be the {\word class precedence list}
constructed so far. $C\sub 1$ is the most specific {\word class}, and $C\sub
n$ is the least specific. Let $1\leq j\leq n$ be the largest number
such that there exists an $i$ where $1\leq i\leq m$ and $N\sub i$
is a direct {\word superclass} of $C\sub j$; $N\sub i$ is placed next.
The effect of this rule for selecting from a set of {\word classes} with no
predecessors is that the {\word classes} in a simple {\word superclass} chain are
adjacent in the {\word class precedence list} and that {\word classes} in each
relatively separated subgraph are adjacent in the {\word class
precedence list}. For example, let $T\sub 1$ and $T\sub 2$ be subgraphs
whose only element in common is the class $J$\negthinspace. Suppose
that no {\word superclass} of $J$ appears in either $T\sub 1$ or $T\sub 2$.
Let $C\sub 1$ be the bottom of $T\sub 1$; and let $C\sub 2$ be the
bottom of $T\sub 2$. Suppose $C$ is a {\word class} whose direct {\word
superclasses}
are $C\sub 1$ and $C\sub 2$ in that order, then the {\word class precedence
list} for $C$ will start with $C$ and will be followed by all {\word classes}
in $T\sub 1$ except $J$. All the {\word classes} of $T\sub 2$ will be next.
The class $J$ and its {\word superclasses} will appear last.
\endsubsubsection%{Topological Sorting}
\beginsubsubsection{Examples}
This example determines a {\word class precedence list} for the
class {\tt pie}. The following {\word classes} are defined:
\screen!
(defclass pie (apple cinnamon) ())
(defclass apple (fruit) ())
(defclass cinnamon (spice) ())
(defclass fruit (food) ())
(defclass spice (food) ())
(defclass food () ())
\endscreen!
The set $S$~$=$ $\{${\tt pie, apple, cinnamon, fruit, spice, food,
standard-object, t}$\}$. The set $R$~$=$ $\{${\tt (pie, apple),
(apple, cinnamon), (apple, fruit), (cinnamon, spice), (fruit, food),
\hfil\break (spice, food), (food, standard-object), (standard-object,
t)}$\}$.
The class {\tt pie} is not preceded by anything, so it comes first;
the result so far is {\tt (pie)}. Remove {\tt pie} from $S$ and pairs
mentioning {\tt pie} from $R$ to get $S$~$=$ $\{${\tt apple, cinnamon,
fruit, spice, food, standard-object, t}$\}$ and $R$~$=$~$\{${\tt
(apple, cinnamon), (apple, fruit), (cinnamon, spice), (fruit,
food),\hfil\break (spice, food), (food, standard-object),
(standard-object, t)}$\}$.
The class {\tt apple} is not preceded by anything, so it is next; the
result is {\tt (pie apple)}. Removing {\tt apple} and the relevant
pairs results in $S$~$=$ $\{${\tt cinnamon, fruit, spice, food,
standard-object, t}$\}$ and $R$~$=$ $\{${\tt (cinnamon, spice),
(fruit, food), (spice, food), (food, standard-object),\hfil\break
(standard-object, t)}$\}$.
The classes {\tt cinnamon} and {\tt fruit} are not preceded by
anything, so the one with a direct {\word subclass} rightmost in the {\word
class
precedence list} computed so far goes next. The class {\tt apple} is a
direct {\word subclass} of {\tt fruit}, and the class {\tt pie} is a direct
{\word subclass} of {\tt cinnamon}. Because {\tt apple} appears to the right
of {\tt pie} in the {\word class precedence list},
{\tt fruit} goes next, and the
result so far is {\tt (pie apple fruit)}. $S$~$=$ $\{${\tt cinnamon,
spice, food, standard-object, t}$\}$; $R$~$=$ $\{${\tt (cinnamon,
spice), (spice, food),\hfil\break (food, standard-object),
(standard-object, t)}$\}$.
The class {\tt cinnamon} is next, giving the result so far as {\tt
(pie apple fruit cinnamon)}. At this point $S$~$=$ $\{${\tt spice,
food, standard-object, t}$\}$; $R$~$=$ $\{${\tt (spice, food), (food,
standard-object), (standard-object, t)}$\}$.
The classes {\tt spice}, {\tt food}, {\tt standard-object}, and {\tt
t} are added in that order, and the {\word class precedence list} is {\tt (pie
apple fruit cinnamon spice food standard-object t)}.
It is possible to write a set of {\word class} definitions that cannot be
ordered. For example:
\screen!
(defclass new-class (fruit apple) ())
(defclass apple (fruit) ())
\endscreen!
The class {\tt fruit} must precede {\tt apple} because the local
ordering of {\word superclasses} must be preserved. The class {\tt apple} must
precede {\tt fruit} because a {\word class} always precedes its own
{\word superclasses}. When this situation occurs, an error is signalled when
the system tries to compute the {\word class precedence list}.
The following might appear to be a conflicting set of definitions:
\screen!
(defclass pie (apple cinnamon) ())
(defclass pastry (cinnamon apple) ())
(defclass apple () ())
(defclass cinnamon () ())
\endscreen!
The {\word class precedence list} for {\tt pie} is {\tt (pie apple cinnamon
standard-object t)}.
The {\word class precedence list} for {\tt pastry} is {\tt (pastry cinnamon apple
standard-object t)}.
It is not a problem for {\tt apple} to precede {\tt cinnamon} in the
ordering of the {\word superclasses} of {\tt pie} but not in the ordering for
{\tt pastry}. However, it is not possible to build a new {\word class} that
has both {\tt pie} and {\tt pastry} as {\word superclasses}.
\endsubsubsection%{Examples}
\endsubSection%{Determining the Class Precedence List}
\beginsubSection{Redefining Classes}
A {\word class}
that is an {\word instance} of {\datatype standard-class} can be redefined
if the new {\word class}
will also be an {\word instance} of {\datatype standard-class}.
Redefining a {\word class} modifies the existing {\word class} object
to reflect the
new {\word class} definition; it does not create a new
{\word class} object for the
{\word class}. Any {\word method object}
created by a {\keyword :reader}, {\keyword :writer}, or
{\keyword :accessor} option specified by the old {\function defclass} form is
removed from the corresponding {\word generic function}.
{\word Methods} specified by the new {\function defclass} form are added.
% any function specified by the {\keyword :constructor}
% option of the old {\function defclass} form is removed from the
% corresponding symbol function cell.
When the class $C$ is redefined, changes are propagated to its {\word instances}
and to {\word instances} of any of its {\word subclasses}. Updating such an
{\word instance} occurs at an implementation-dependent time, but no later than
the next time a {\word slot}
of that {\word instance} is read or written. Updating an
{\word instance}
does not change its identity as defined by the {\function eq}
function. The updating process may change the {\word slots} of that
particular {\word instance},
but it does not create a new {\word instance}. Whether
updating an {\word instance} consumes storage is implementation-dependent.
Note that redefining a {\word class} may cause {\word slots}
to be added or deleted.
If a {\word class} is redefined in a way that changes the set of
{\word local slots}
accessible in {\word instances},
the {\word instances} will be updated. It is
implementation-dependent whether {\word instances} are updated if a
{\word class} is
redefined in a way that does not change the set of {\word local slots}
accessible in {\word instances}.
The value of a {\word slot}
that is specified as shared both in the old {\word class}
and in the new {\word class} is retained.
If such a {\word shared slot} was unbound
in the old {\word class}, it will be unbound in the new {\word class}.
{\word Slots} that
were local in the old {\word class} and that are shared in the new
{\word class} are
initialized. Newly added {\word shared slots} are initialized.
Each newly added {\word shared slot} is set to the result of evaluating the
captured {\keyword :initform} form for the {\word slot}
that was specified in the
{\function defclass} form for the new {\word class}.
If there is no {\keyword :initform}
form, the {\word slot} is unbound.
If a {\word class} is redefined in such a way that the set of {\word local
slots}
{\word accessible} in an {\word instance} of the {\word class}
is changed, a two-step process
of updating the {\word instances} of the {\word class} takes place.
The process may
be explicitly started by invoking the generic function {\function
make-instances-obsolete}. This two-step process can happen in other
circumstances in some implementations. For example, in some
implementations this two-step process will be triggered if the order
of {\word slots} in storage is changed.
The first step modifies the structure of the {\word instance} by adding new
{\word local slots} and discarding {\word local slots}
that are not defined in the new
version of the {\word class}.
The second step initializes the newly-added {\word local slots} and performs
any other user-defined actions. These two steps are further specified
in the next two sections.
\beginsubsubsection{Modifying the Structure of Instances}
The first step modifies the structure of {\word instances} of the redefined
{\word class} to conform to its new {\word class} definition.
Local {\word slots} specified
by the new {\word class} definition that are not specified as either local or
shared by the old {\word class} are added, and {\word slots}
not specified as either
local or shared by the new {\word class} definition that are specified as
local by the old {\word class} are discarded.
The {\word names} of these added and discarded
{\word slots} are passed as arguments
to {\function update-instance-for-redefined-class}
as described in the next section.
The values of {\word local slots} specified by both the new and old {\word
classes}
are retained. If such a local {\word slot} was unbound, it remains unbound.
The value of a {\word slot} that is specified as shared in the old
{\word class} and
as local in the new {\word class} is retained. If such a {\word shared slot}
was
unbound, the {\word local slot} will be unbound.
\endsubsubsection%{Modifying the Structure of the Instance}
\beginsubsubsection{Initializing Newly Added Local Slots}
The second step initializes the newly added {\word local slots} and performs
any other user-defined actions. This step is implemented by the generic
function {\function update-instance-for-redefined-class}, which is called after
completion of the first step of modifying the structure of the
{\word instance}.
The generic function {\function update-instance-for-redefined-class} takes
four required arguments: the {\word instance} being updated after it has
undergone the first step, a list of the names of {\word local slots} that were
added, a list of the names of {\word local slots} that were discarded, and a
property list containing the {\word slot} names and values of
{\word slots} that were
discarded and had values. Included among the discarded {\word slots} are
{\word slots} that were local in the old {\word class} and that are shared in the new
{\word class}.
The generic function {\function update-instance-for-redefined-class} also
takes any number of initialization arguments. When it is called by
the system to update an {\word instance} whose {\word class}
has been redefined, no
initialization arguments are provided.
There is a system-supplied primary {\word method} for {\function
update-instance-for-redefined-class} whose parameter specializer for
its {\word instance}
argument is the class {\datatype standard-object}. First this
{\word method} checks the validity of initialization arguments and signals an
error if an initialization argument is supplied that is not declared
as valid. (See the section ``Declaring the Validity of Initialization
Arguments'' for more information.) Then it calls the generic function
{\function shared-initialize} with the following arguments: the
{\word instance},
the list of {\word names} of
the newly added {\word slots}, and the initialization
arguments it received.
\endsubsubsection%{Initializing Newly added Local Slots}
\beginsubsubsection{Customizing Class Redefinition}
{\word Methods}
for {\function update-instance-for-redefined-class} may be defined
to specify actions to be taken when an {\word instance} is updated. If only
{\keyword :after} methods for
{\function update-instance-for-redefined-class} are
defined, they will be run after the system-supplied primary {\word method} for
initialization and therefore will not interfere with the default
behavior of {\function update-instance-for-redefined-class}. Because no
initialization arguments are passed to {\function
update-instance-for-redefined-class} when it is called by the system,
the {\keyword :initform} forms for {\word slots}
that are filled by {\keyword :before}
methods for {\function update-instance-for-redefined-class} will not be
evaluated by {\function shared-initialize}.
{\word Methods}
for {\function shared-initialize} may be defined to customize {\word class}
redefinition. See the section ``Shared-Initialize'' for more
information.
\endsubsubsection%{Customizing Class Redefinition}
\beginsubsubsection{Extensions}
There are two allowed extensions to {\word class} redefinition:
\beginlist
\itemitem{\bull} The \OS\ may be extended to permit the new {\word class}
to be an {\word instance} of a {\word metaclass}
other than the {\word metaclass} of the
old {\word class}.
\itemitem{\bull} The \OS\ may be extended to support an updating process
when either the old or the new {\word class} is an {\word instance} of a
{\word class}
other than {\datatype standard-class} that is not a {\datatype built-in-class}.
\endlist
\endsubsubsection%{Extensions}
\beginsubSection{Integrating Types and Classes}
The \CLOS\ maps the space of {\word classes} into the {\word type} space.
Every {\word class}
that has a proper name has a corresponding {\word type} with the same
{\word name}.
The proper name of every {\word class} is a valid type specifier. In
addition, every {\word class object} is a valid type specifier. Thus the
expression {\tt (typep {\tt object class\/})} evaluates to true if the
{\word class} of {\tt object\/} is {\tt class\/} itself or a
{\word subclass} of {\tt
class}. The evaluation of the expression {\tt (subtypep {\tt class1
class2\/})} returns the values {\tt t~t} if {\tt class1\/} is a
subclass of {\tt class2\/} or if they are the same {\word class}; otherwise it
returns the values {\tt nil~t}. If $I$ is an {\word instance} of some
{\word class}
$C$ named $S$ and $C$ is an {\word instance} of {\datatype standard-class}, the
evaluation of the expression {\tt (type-of $I$\/)} will return $S$ if
$S$ is the proper name of $C$\negthinspace; if $S$ is not the proper
name of $C$\negthinspace, the expression {\tt (type-of $I$\/)} will
return $C$\negthinspace.
Because the names of {\word classes}
and {\word class objects} are type specifiers, they may
be used in the special form {\function the} and in type declarations.
Many but not all of the predefined type specifiers have a
corresponding {\word class} with
the same proper name as the {\word type}. These type
specifiers are listed in Figure {\chapno--\the\capno}.
For example, the type {\datatype array\/}
has a corresponding {\word class} named {\datatype array\/}.
No type specifier that is a
list, such as {\tt (vector double-float 100)}, has a corresponding {\word
class}.
The form {\function deftype} does not create any {\word classes}.
Each {\word class} that corresponds to a predefined type specifier
can be implemented in one of three ways, at the discretion of each
implementation. It can be a {\datatype standard-class\/} (of the kind
defined by {\function defclass}), a {\datatype structure-class\/} (defined
by {\function defstruct}), or a {\datatype built-in-class\/} (implemented in
a special, non-extensible way).
A {\datatype built-in-class}
is one whose {\word instances} have restricted capabilities or
special representations. Attempting to use {\function defclass} to define
{\word subclasses} of a {\datatype built-in-class}
signals an error. Calling {\function
make-instance} to create an {\word instance} of a
{\datatype built-in-class} signals an error.
Calling {\function slot-value} on an
{\word instance} of a {\datatype built-in-class} signals an
error.
Redefining a {\datatype built-in-class}
or using {\function change-class} to change
the {\word class} of an {\word instance}
to or from a {\datatype built-in-class} signals an error.
However, {\datatype built-in-classes} can be used as parameter specializers in
{\word methods}.
%The \OS\ specifies that all predefined type specifiers
%listed in Figure~2-1 are built-in classes, but a particular
%implementation is allowed to extend the \OS\ to define some of them as
%standard classes or as structure classes.
It is possible to determine whether a {\word class}
is a {\datatype built-in-class} by
checking the {\word metaclass}.
A standard {\word class} is an {\word instance} of {\datatype
standard-class}, a built-in {\word class}
is an {\word instance} of {\datatype
built-in-class}, and a structure {\word class}
is an {\word instance} of {\datatype
structure-class}.
Each {\datatype structure} type created by {\function defstruct} without using the {\tt
:type} option has a corresponding {\word class}.
This {\word class} is an {\word instance} of
{\datatype structure-class}.
%A portable program must assume that {\datatype
%structure-class} is a subclass of {\datatype built-in-class} and has the
%same restrictions as built-in classes. Whether {\datatype structure-class}
%in fact is a subclass of {\datatype built-in-class} is
%implementation dependent.
The {\tt :include} option of {\function defstruct} creates a direct
{\word subclass} of the {\word class}
that corresponds to the included {\datatype structure}.
The purpose of specifying that many of the standard type
specifiers have a corresponding {\word class}
is to enable users to write {\word methods} that
discriminate on these {\word types}.
{\word Method} selection requires that a
{\word class precedence list} can be
determined for each {\word class}.
The hierarchical relationships among the type specifiers
are mirrored by relationships among the {\word classes} corresponding to those
{\word types}. The existing type hierarchy is used for determining the
{\word class precedence list}
for each {\word class} that corresponds to a predefined
{\word type}. In some cases,
a {\word local precedence order} is not specifiied for two {\word supertypes}
of a
given type specifier. For example, {\datatype null} is a {\word subtype}
of both
{\datatype symbol} and {\datatype list}, but it is not specified
whether {\datatype symbol} is more specific or less
specific than {\datatype list}. The \CLOS\ defines those
relationships for all such {\word classes}.
Figure {\chapno--\the\capno}
lists the set of {\word classes} required by the \OS\
that correspond to predefined type specifiers. The
{\word superclasses} of each such {\word class}
are presented in order from most
specific to most general, thereby defining the {\word class precedence list}
for the {\word class}. The {\word local precedence order} for
each {\word class} that
corresponds to a type specifier can be derived from this
table.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus .5 fil&&#\hfil\cr %was &&#
\noalign{\vskip -9pt}
\hfil\bf Predefined Type&\bf Class Precedence List for Corresponding Class\span\omit\span\omit\cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
array&(array t)\cr
bit-vector&(bit-vector vector array sequence t)\cr
character&(character t)\cr
complex&(complex number t)\cr
cons&(cons list sequence t)\cr
float&(float number t)\cr
integer&(integer rational number t)\cr
list&(list sequence t)\cr
null&(null symbol list sequence t)\cr
number&(number t)\cr
ratio&(ratio rational number t)\cr
rational&(rational number t)\cr
sequence&(sequence t)\cr
string&(string vector array sequence t)\cr
symbol&(symbol t)\cr
t&(t)\cr
vector&(vector array sequence t)\cr
\noalign{\vskip -9pt}
}}
\caption{}
\endfig
Individual implementations may be extended to define other type
specifiers to have a corresponding {\word class}. Individual implementations
may be extended to add other {\word subclass} relationships and to add other
elements to the {\word class precedence lists} in the preceding figure,
as long as
they do not violate the type relationships and disjointness
requirements specified by this standard.
A standard {\word class} defined with no direct {\word superclasses} is guaranteed to
be disjoint from all of the {\word classes} in the table, except for the
class named {\datatype t}.
%The following Common Lisp types will have corresponding classes when
%Common Lisp is modified to define them each as being disjoint from {\datatype
%cons}, {\datatype symbol}, {\datatype array}, {\datatype number}, and
%{\datatype character}:
%
%\beginlist
%
%\item{\bull} function
%\item{\bull} hash-table
%\item{\bull} package
%\item{\bull} pathname
%\item{\bull} random-state
%\item{\bull} readtable
%\item{\bull} stream
%
%\endlist
\endsubSection%{Integrating Types and Classes}
∂22-Feb-89 1338 X3J13-mailer cs proposal part 2 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:37:30 PST
Date: Wed, 22 Feb 89 10:08:21 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100821.baggins@almvma>
Subject: cs proposal part 2 of 3
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
\multicolumn{2}{l} }
\newcommand{\csdag}{\bf$\Rightarrow$\ddag}
\newcommand{\editstart}{}
\newcommand{\editend}{\\ & \end{tabular}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\appendix
\chapter{Editorial Modifications to CLtL}
The following sections specify the editorial changes needed in
CLtL to support the proposal. Section/subsection numbers and titles
match those found in \cite{steele84}. The notation
{\csdag x (pn, function)} denotes a reference to paragraph x within the
subsection (we count each individual example or metastatement
as 1 paragraph of text). Also, {\bf (pn, function)}, or simply
{\bf (pn)} is included as an additional
aid to the reader indicating the page number and function modified.
When an entire paragraph is deleted,
the first few words of the paragraph is noted.
If a section or paragraph of CLtL is {\em not} referenced,
no editorial changes are required to support this proposal.
\footnote{This may be an over optimistic statement since the changes
are fairly pervasive. The editor should take the sense of
Chapter 1 into account in resolving any discrepancies.}
%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types} % 2
%----------------------------------------------------------------------
\edithead {\csdag 8 (p12)}
\editstart
\\ \bf replace &
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\\ \bf with &
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\editend
\setcounter{subsection}{1}
\subsection{Characters} % 2.2.
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf replace &
\cltxt
Characters are represented as data objects of type {\clkwd character}.
There are two subtypes of interest, called
{\clkwd standard-char} and {\clkwd string-char}.
\\ \bf with &
\cltxt
Characters are represented as data objects of type
{\clkwd character}.
\editend
\\
\edithead {\csdag 2 (p20)}
\editstart
\\ \bf replace &
\cltxt
This works well enough for printing characters. Non-printing
characters
\\ \bf with &
\cltxt
This works well enough for graphic characters. Non-graphic
characters
\editend
\subsubsection{Standard Characters} % 2.2.1.
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique label, a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
\\ &
Common LISP requires all implementations to support a {\em standard}
character subrepertoire. Typically, an implementation
incorporates the standard
characters as a subset of a larger repertoire corresponding
to a frequently used set of characters, or base coded character
set.
The term {\em base character repertoire} refers to
the collection of characters represented by
the base coded character set.
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
The {\clkwd base-character} type is defined as a subtype of
{\clkwd character}. A {\clkwd base-character}
object can contain any member of the base character repertoire.
Objects of type
{\clkwd (and character (not base-character))} are referred to
as {\em extended characters}.
\editend
\\
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf delete &
\cltxt
Common LISP defines a "standard character set" ...
\editend
\\
\edithead {\csdag 1 (P20)}
\editstart
\\ \bf new &
\cltxt
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\editend
\\
\edithead {\csdag 2 (p21)}
\editstart
\\ \bf delete &
\cltxt
! " \# ...
\editend
\\
\edithead {\csdag 2 new (p21)}
\editstart
\\ &
{\bf Common LISP Standard Character Subrepertoire}
\editend
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic label categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
\\
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
Label & Glyph & Name or description
& Label & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\\
\edithead {\csdag 3 (p21)}
\editstart
\\ \bf delete &
\cltxt
@ A B C...
\editend
\\
\edithead {\csdag 4 (p21)}
\editstart
\\ \bf delete &
\cltxt
\bq a b c...
\editend
\\
\edithead {\csdag 5 (p21)}
\editstart
\\ \bf delete &
\cltxt
The Common LISP Standard character set is apparently ...
\editend
\\
\edithead {\csdag 6 (p21)}
\editstart
\\ \bf replace &
\cltxt
Of the ninety-four non-blank printing characters
\\ \bf with &
\cltxt
Of the ninety-five graphic characters
\editend
\\
\edithead {\csdag 9 (p21)}
\editstart
\\ \bf delete &
\cltxt
The following characters are called ...
\editend
\\
\edithead {\csdag 10 (p21)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd \#$\backslash$Backspace \#$\backslash$Tab } ...
\editend
\\
\edithead {\csdag 11 (p21)}
\editstart
\\ \bf delete &
\cltxt
Not all implementations of Common ...
\editend
\subsubsection{Line Divisions} % 2.2.2.
\edithead {\csdag 6 (p22)}
\editstart
\\ \bf replace &
\cltxt
a two-character sequence, such as
{\clkwd \#$\backslash$Return } and then
{\clkwd \#$\backslash$Newline },
is not acceptable,
\\ \bf with &
\cltxt
a two-character sequence is not acceptable,
\editend
\\
\edithead {\csdag 8 (p22)}
\editstart
\\ \bf delete &
\cltxt
Implementation note: If an implementation uses ...
\editend
\subsubsection{Non-standard Characters} % 2.2.3.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\subsubsection{Character Attributes} % 2.2.4.
\edithead {\csdag 0 section heading (p23)}
\editstart
\\ \bf replace &
\cltxt
Character Attributes
\\ \bf with &
\cltxt
Character Identity
\editend
\\
\edithead {\csdag 1 through 8 (p23)}
\editstart
\\ \bf delete all paragraphs&
\cltxt
Every object of type {\clkwd character} ...
\editend
\\
\edithead {\csdag 1 (p23)}
\editstart
\\ \bf new &
\cltxt
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
\\ &
Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
character registries}. That is, each character is included
in one and only one character registry.
\\ &
Character codes are composed from a character registry and a
character label. The convention by which a character registry and
character label compose a character code is implementation
dependent.
\editend
\subsubsection{String Characters} % 2.2.5.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\setcounter{subsection}{4}
\subsubsection{Character Registries} % 2.2.5.
\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
An implementation must document the registries it supports.
Registries must be uniquely
named using only {\clkwd standard-p} characters.
For each registry supported,
an implementation must define the individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character set standards
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
which are supported must be specified.
\end{itemize}
\editend
\subsection{Symbols} % 2.3.
\edithead {\csdag 12 (p25)}
\editstart
\\ \bf replace &
\cltxt
A symbol may have uppercase letters, lowercase letters, or both
in its print name.
\\ \bf with &
\cltxt
A symbol may have characters from any supported character registry
in its print name.
It may have uppercase letters, lowercase letters, or both.
\editend
\setcounter{subsection}{4}
\subsection{Arrays}
\subsubsection{Vectors}
\edithead {\csdag 6 (p29)}
\editstart
\\ \bf replace &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or rather, a special subset of the
characters);
\\ \bf with &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or optionally, special subsets of
the characters);
\editend
\subsubsection{Strings}
\edithead {\csdag 1 (p30)}
\editstart
\\ \bf replace &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd string-char}.
\\ \bf with &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype
of character.
\editend
\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.
\edithead {\csdag 14 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd standard-char} is a subtype of {\clkwd string-char};
{\clkwd string-char} is a subtype of {\clkwd character}.
\\ \bf with &
\cltxt
The type {\clkwd base-character} is a subtype of
{\clkwd character}.
The type {\clkwd string-char} is implementation defined as either
{\clkwd base-character} or {\clkwd character}.
\editend
\\
\edithead {\csdag 15 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
for {\clkwd string} means {\clkwd (vector string-char)}.
\\ \bf with &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
{\clkwd string} consists of vectors specialized by subtypes of
{\clkwd character}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd base-string} means
{\clkwd (vector base-character)}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd general-string} means
{\clkwd (vector character)} and is a subtype of {\clkwd string}.
\editend
\\
\edithead {\csdag 20 (p34)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (simple-array string-char (*))};
\\ \bf with &
\cltxt
{\clkwd (and string simple-array)};
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-base-string} means
{\clkwd (simple-array base-character (*))} and
is the most efficient string which can hold
the standard characters. {\clkwd simple-base-string}
is a subtype of {\clkwd base-string}.
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-general-string} means
{\clkwd (simple-array character (*))}.
{\clkwd simple-general-string}
is a subtype of {\clkwd general-string}.
\editend
\\
\edithead {\csdag 22 after (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd simple-string} is a subtype of
{\clkwd string}. (Note that although
{\clkwd string}
is a subtype of {\clkwd vector, simple-string} is not
a subtype of {\clkwd simple-vector}.
\\ \bf with &
\cltxt
The type {\clkwd simple-string} is a subtype of
{\clkwd string}, {\clkwd simple-string} consists of
simple vectors specialized by subtypes of
{\clkwd character}. (Note that although
{\clkwd string}
is a subtype of {\clkwd vector, simple-string} is not
a subtype of {\clkwd simple-vector}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{3}
\section{Type Specifiers} % 4
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Type Specifier Lists} % 4.2.
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf remove &
\\ &
\cltxt
{\clkwd standard-char}
\\ &
{\clkwd string-char}
\editend
\\
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf insert &
\\ &
\cltxt
{\clkwd base-character}
\\ &
{\clkwd base-string}
\\ &
{\clkwd general-string}
\\ &
{\clkwd simple-base-string}
\\ &
{\clkwd simple-general-string}
\editend
\setcounter{subsection}{2}
\subsection{Predicating Type Specifiers} % 4.3.
\edithead {\csdag 2 (p43)}
\editstart
\\ \bf delete &
\cltxt
As an example, the entire ...
\editend
\\
\edithead {\csdag 3 delete example (p43)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (deftype string-char () } ...
\editend
\setcounter{subsection}{4}
\subsection{Type Specifiers That Specialize} % 4.5.
\edithead {\csdag 5 after (p46)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (character {\em repertoire})}
\\ &
This denotes a character type specialized to members
of the specified repertoire. {\em Repertoire} may be
{\clkwd :base} or {\clkwd :standard} or any supported
character registry name or a list of names.
\editend
\setcounter{subsection}{5}
\subsection{Type Specifiers That Abbreviate} % 4.6.
\edithead {\csdag 20 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (array string-char ({\em size}))}: the set of
strings of
the indicated size.
\\ \bf with &
\cltxt
Means the union of the vector types specialized by subtypes of
character
and the indicated size.
For the purpose of object creation, it is equivalent to
{\clkwd (general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (simple-array string-char ({\em size}))}: the
set of simple strings of the indicated size.
\\ \bf with &
\cltxt
Means the union of the simple vector types specialized by subtypes of
character and the indicated size.
For the purpose of object creation, it is equivalent to
{\clkwd (simple-general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (base-string {\em size})}
\\ &
Means the same as {\clkwd (array base-character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-base-string {\em size})}
\\ &
Means the same as {\clkwd (simple-array base-character ({\em size}))}:
the set of simple base strings of the indicated size.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (general-string {\em size})}
\\ &
Means the same as {\clkwd (array character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-general-string {\em size})}
\\ &
Means the same as
{\clkwd (simple-array general-character ({\em size}))}:
the set of simple general strings of the indicated size.
\editend
\setcounter{subsection}{7}
\subsection{Type Conversion Function} % 4.8.
\edithead {\csdag 6 (p51)}
\editstart
\\ \bf replace &
\cltxt
Some strings, symbols, and integers may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
If {\em object} is a symbol whose print name is of length
1, then the sole element of the print name is returned.
If {\em object} is an integer {\em n}, then {\clkwd (int-char }
{\em n}{\clkwd )} is returned. See {\clkwd character}.
\\ \bf with &
\cltxt
Some strings amd symbols may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
If {\em object} is a symbol whose print name is of length
1, then the sole element of the print name is returned.
See {\clkwd character}.
\editend
\\
\edithead {\csdag 6 after (p52)}
\editstart
\\ \bf insert &
\begin{itemize}
\cltxt
\item Any string subtype may be converted to any other string
subtype, provided the new string can contain all actual
elements of the old string. It is an error if it cannot.
\end{itemize}
\editend
%----------------------------------------------------------------------
\setcounter{section}{5}
\section{Predicates} % 6
%----------------------------------------------------------------------
\edithead {\csdag 2 (p71)}
\editstart
\\ \bf replace &
\cltxt
but {\clkwd standard-char} begets {\clkwd standard-char-p}
\\ \bf with &
\cltxt
but {\clkwd bit-vector} begets {\clkwd bit-vector-p}
\editend
\setcounter{subsection}{1}
\subsection{Data Type Predicates} % 6.2.
\setcounter{subsubsection}{1}
\subsubsection{Specific Data Type Predicates} % 6.2.2.
\edithead {\csdag 36 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} {\em object}
\\ \bf with &
\cltxt
{\clkwd characterp} {\em object} \&{\clkwd optional}
{\em repertoire}
\editend
\\
\edithead {\csdag 37 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} is true if its argument is a character,
and otherwise is false.
\\ \bf with &
\cltxt
If {\em repertoire} is omitted, {\clkwd characterp}
is true if its argument is a character object,
and otherwise is false.
If a {\em repertoire} argument is specified,
{\clkwd characterp} is true if its argument
is a character object and a member of the specified repertoire,
and
otherwise is false.
For example, {\clkwd (characterp \#$\backslash$A}
{\clkwd :Latin)}
is true since \#$\backslash$A is a member of the
Latin character registry. {\em repertoire} may be any supported
character registry name or the names
{\clkwd :base} or {\clkwd :standard}. {\clkwd (characterp x :base)} is
true if its argument is a member of the base character
repertoire and false
otherwise.
{\clkwd (characterp x :standard)} is
true if its argument is a member of the standard character
subrepertoire and false
otherwise.
\editend
\\
\edithead {\csdag 38 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (characterp x) $\equiv$ (typep x \apostrophe character)}
\\ \bf with &
\cltxt
{\clkwd (characterp x :standard) $\equiv$ (typep x \apostrophe
(character :standard)}
\editend
\\
\edithead {\csdag 72 (p76)}
\editstart
\\ \bf replace &
\cltxt
See also {\clkwd standard-char-p, string-char-p, streamp,}
\\ \bf with &
\cltxt
See also {\clkwd standard-char-p, streamp,}
\editend
\setcounter{subsubsection}{2}
\subsubsection{Equality Predicates} % 6.2.3.
\edithead {\csdag 75 (p81)}
\editstart
\\ \bf replace &
\cltxt
which ignores alphabetic case and certain other attributes
of characters;
\\ \bf with &
\cltxt
which ignores alphabetic case
of characters;
\editend
%----------------------------------------------------------------------
\setcounter{section}{6}
\section{Control Structure} % 7
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Generalized Variables} % 7.2.
\edithead {\csdag 19 modify table (p95)}
\editstart
\\ \bf replace &
\cltxt
char string-char
\\ &
schar string-char
\\ \bf with &
\cltxt
char character
\\ &
schar character
\editend
\\
\edithead {\csdag 22 table entry (p96)}
\editstart
\\ \bf delete &
\cltxt
char-bit first set-char-bit
\editend
%----------------------------------------------------------------------
\setcounter{section}{9}
\section{Symbols} % 10
%----------------------------------------------------------------------
\edithead {\csdag 3 (p163)}
\editstart
\\ \bf replace &
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
It is an error to alter a symbol's print name.
\editend
\setcounter{subsection}{1}
\subsection{The Print Name} % 10.2.
\edithead {\csdag 5 (p168)}
\editstart
\\ \bf replace &
\cltxt
It is an extremely bad idea
\\ \bf with &
\cltxt
It is an error and an extremely bad idea
\editend
%----------------------------------------------------------------------
\setcounter{section}{10}
\section{Packages} % 11
%----------------------------------------------------------------------
\setcounter{subsection}{6}
\subsection{Package System Functions and Variables} % 11.7.
\edithead {\csdag 31 (p184,intern)}
\editstart
\\ \bf append &
\cltxt
All strings, base and extended, are acceptable {\em string}
arguments.
\editend
∂22-Feb-89 1337 X3J13-mailer cs proposal part1 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:36:18 PST
Date: Wed, 22 Feb 89 10:06:36 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100636.baggins@almvma>
Subject: cs proposal part1 of 3
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
Larry Masinter\thanks{Xerox Research} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{February 21, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
native languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
This document is separated into two parts. The first part explains the
major language changes and their motivations. While intended as
commentary to a general audience, and not explicitly as
part of the standard document, the X3 J13 editor may
include sections at her/his discretion. The second part,
Appendix A, provides
the page by page set of editorial changes to \cite{steele84}.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
native languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many native
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
To universally identify each character, we define a unique
collection of repertoires called {\em character
registries} as a partitioning of all characters.
That is, each character is included
in one and only one character registry.
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character registry and a character label.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities. For example, while Common LISP is free to
define unique manipulation facilities for characters, registries
and coded character sets, it should
not define standard coded character sets nor standard character
registries.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices. Thus, an important element of
this proposal is the removal of the {\em font} and {\em bits}
attributes from the language specification.
\footnote{These and other attributes may still be supported as
implementation-defined extensions.}
All functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified by this proposal.
The deleted functions and constants include:
{\em char-font-limit,
char-bits-limit,
int-char,
char-int,
char-bits,
char-font,
make-char,
char-control-bit,
char-meta-bit,
char-super-bit,
char-hyper-bit,
char-bit,
set-char-bit}.
The definition in \cite{steele84} of semi-standard characters has
been eliminated. This is replaced by a more uniform approach
to character naming with the introduction of character registries
(see below).
%----------------------------------------------------------------------
\section{Character Naming}
A Common LISP program must be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}.\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of character registry is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character registry name, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
Common LISP character codes are composed from a character registry and
a character label. The convention by which a character label and
character registry compose a character code is implementation
dependent.
We introduce new functions {\clkwd find-char, char-registry-name,} and
{\clkwd char-label} to
compose and decompose character objects. We also extend the
{\clkwd characterp} predicate to
support testing
membership of a character in a given character registry.
\footnote{
For example,
testing membership in the Japanese Katakana character registry.
}
A global variable {\clkwd *all-character-registry-names*}
is added to
support application determination of supported character registries.
The naming and content of the standard character registries
is left unspecified by this proposal.
\footnote{The only constraint is that character registries be
named using only {\clkwd standard-p} characters.}
Below are some candidate character registry names:
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control (meaning the collection of standard text communication
control codes)
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive. The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?). It is application
programs which require a reliable definition of the
registry names and their constituents. The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.
The proposed ISO Character Registry Standard is fixed;
an implementation may not extend a standard registry's
constituent set of characters beyond the
standard definition.
An implementation may provide support for all or part of any
character registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any standard
character registry).
Implementation registries must be uniquely
named using only {\clkwd standard-p} characters.
An implementation must document the registries it supports.
For each registry supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
\footnote{For example, {\em Xerox System Integration Character
Code Standard}\cite{xerox87}.}
supported are documented.
\end{itemize}
Which coded character sets and encoding schemes
are supported by the overall computing system, the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.
The diversity of glyph sets and coded character
set conventions in use worldwide and the desirability
of allowing Common LISP applications
to portabily manipulate symbolic elements from many
languages, perhaps simultaneously, mandate such a flexible approach.
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements must
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to include specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarily for the {\clkwd simple-string}
type specifier). This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
The following type specifier is added as a subtype
of {\clkwd character}:
\begin{itemize}
\item {\clkwd base-character}
\end{itemize}
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
(and character (not base-character))}
are referred to as {\em extended characters}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
The base characters are, in general, the default characters for I/O
operations.
\end{itemize}
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, is
in some sense privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However, there are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
It is the intention of this proposal that the composition of
base characters is typically
determined by the code capacity of the natural file system and I/O
transaction representations, and the assumed display glyphs should be
those of the terminals most commonly employed.
There are several advantages to this scheme. Internal representation
of strings of just base characters can be more compact than
strings including extended characters.
Source programs are likely to consist predominantly of base characters
since the standard characters are a subset of the base character
repertoire. Parsing of pure base character text
can be more efficient than parsing of text including
extended characters.
I/O can be performed more simply
with base characters.
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional
mechanisms, such as in \cite{linden87}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\subsection{String Type}
The {\clkwd string} type
is defined as
a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of character. Similarly, a simple
string is a specialized simple vector whose elements are of type
{\clkwd character} or a subtype of character. The following string
subtypes are
distinguished with standardized names: {\clkwd base-string},
{\clkwd general-string}, {\clkwd simple-base-string}, and
{\clkwd simple-general-string}.
All strings which are not base strings
are referred to as {\em extended strings}.
A base string can only contain base characters.
{\clkwd general-string} is equivalent to {\clkwd (vector character)}
and can contain any implementation supported base or extended characters,
in any mixture.
All Common LISP functions defined to operate on strings treat
base and extended strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coersion to an extended string.}
An implementation may support string subtypes in addition
to {\clkwd base-string} and
{\clkwd general-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic character registries
might provide as extended characters:
\begin{itemize}
\item {\clkwd general-string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd general-string}s.
The {\clkwd coerce} function is extended to
allow for explicit coercion between base strings and extended strings.
It is an error to coerce an extended character to a base character.
During reader
construction of symbols, if all the characters
in the symbol's name are of type {\clkwd base-character},
then the name of the symbol may be stored as a base string.
Otherwise it will be stored as an extended string.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
One keyword argument is proposed as an addition to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-coded-character-format}
whose value would be:
\begin{itemize}
\item
A name or list of names indicating an implementation recognized
scheme for representing 1 or more coded character sets.
\footnote{
For example, the so/si convention used by IBM on 370
machines could be selected by a list including
the name {\clkwd :ibm-shift-delimited}.
The run-encoding convention defined by XEROX could be
selected by {\clkwd :xerox-run-encoded}.
The convention based on
ASCII which uses leading bit patterns to distinguish two-byte codes
from one-byte codes could be selected by
{\clkwd :ascii-high-byte-delimited}.
}
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\footnote{
For example, if {\clkwd :ibm-shift-delimited} were the
argument, two
coded character set specifiers would have to be provided.
}
\end{itemize}
\end{itemize}
These arguments are provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream. (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
The new function {\clkwd external-coded-string-length}
takes a character
or string object as its required argument. It also takes an optional
{\em output-stream}.
It returns the number of implementation-defined
representation units
\footnote{
Often the same as the storage width of a base character, usually a byte.
}
required to externally store that object, using the
representation convention associated with the stream.
If the object cannot be represented in
that convention, the function returns {\clkwd nil}.
This function is necessary
to determine if strings can be written to fixed length
fields in databases or terminal screen templates. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
Related to the I/O interface,
we also introduce the function {\clkwd char-ccs-value}
which takes a character object and a coded character set name
(eg. {\clkwd :ISO8859/1-1987}) and returns the encoding of
the character within the coded character set.
%----------------------------------------------------------------------
%----------------------------------------------------------------------
∂22-Feb-89 1336 X3J13-mailer recent sent to wrong mailing list
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:34:48 PST
Date: Wed, 22 Feb 89 10:04:32 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100432.baggins@almvma>
Subject: recent sent to wrong mailing list
Sorry if this is a repeat for you. I'm resending the revised
document to this address as well.
=========================================================================
Date: Wed, 22 Feb 89 00:36:12 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.003612.baggins@almvma>
Subject: cs proposal revisions
I've sent out a revised cs document for your review. It reflects
a number of your comments from the Hawaii meeting and over the
net. The larger changes were:
-- The 'depreciated' appendix is eliminated. I re-introduced
the list of implementation-dependent attribute support
items into the document proper. The other items in
appendix B were simply eliminated.
-- The functions sbchar and sgchar are eliminated. In general,
the comments indicate that case discrimination by schar
does not introduce a substantial performance penalty.
-- Character registry names and constituents are NOT defined by
Common LISP. The proposal defines only the framework for
composition and decomposition of characters. The naming
of registries and definition of their constituents are
left completely as an ISO standard activity.
-- Character registry names and constituents are NOT defined by
Common LISP. The proposal defines only the framework for
composition and decomposition of characters. The naming
of registries and definition of their constituents are
left completely as an ISO standard activity.
Please send comments to the X3J13 mailing list. If time allows
and it seems needed, I will send out another revision in time to
allow for an actual vote at the March meeting. A straw vote list
will follow shortly.
Regards,
Thom
=========================================================================
Date: Wed, 22 Feb 89 02:09:18 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.020918.baggins@almvma>
Subject: Jan 1 cs proposal comments
>> From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>> Subject: Comments on the Character proposal dated January 1, 1989
>>
>> Page 6 -- *all-registry-names* should be renamed to
>> *all-character-registry-names*; the word "registry" by itself
>> is too general.
I made this change to the latest version of the proposal.
>>
>> Page 9 -- the fourth bullet requires a defined total ordering of all
>> characters. This seems unnecessary, and is impossible to implement in any
>> system (such as Symbolics Genera) that allows dynamic addition of character
>> registries by third-party software vendors and by users; in such a system
>> character codes have to be allocated dynamically and therefore their order
>> cannot be fixed ahead of time.
You are quite right. This bullet is removed.
>>
>> Page 9 -- This says an implementation must define the result of
>> standard-char-p on the characters it supports. I think that is incorrect.
>> Common Lisp fully defines the result of standard-char-p, which is NIL
>> for all characters added by an implementation.
Right. This bullet is removed.
>>
>> Page 14 -- This EXTERNAL-WIDTH function probably should be part of a
>> database facility or a terminal screen template facility; I'm not sure it
>> is useful by itself. Also note that its result is only meaningful with
>> respect to a specific state of the stream. To give two examples, with the
>> SO/SI encoding the answer can vary by 1 depending on whether the stream is
>> already shifted into the correct state for the first character; with the
>> universal encoding Symbolics uses, the answer can vary by a lot depending on
>> whether the character repertoires appearing in the string have been used
>> earlier on the same stream (and hence have been assigned encoding numbers).
>> Because of this dependence on the state of the stream, I cannot think of
>> any correct use of EXTERNAL-WIDTH that does not involve immediately
>> outputting the string to the stream. Therefore I believe the same effect
>> can be achieved without adding any new functions, by calling FILE-POSITION,
>> outputting to the stream, calling FILE-POSITION again, and subtracting. If
>> you still want to propose this feature, you should change the name: use
>> "length" instead of "width", since that's the word Common Lisp always uses,
>> and use a name that relates to the :EXTERNAL-CODE-FORMAT option to OPEN;
>> for example, STRING-LENGTH-IN-EXTERNAL-CODE-FORMAT or
>> EXTERNAL-CODED-STRING-LENGTH.
I changed the name to EXTERNAL-CODED-STRING-LENGTH. The description
already contained a comment regarding current state. Actually, I
favored the STREAM-INFO proposal which was voted down. This is
much less ambitious but I still feel more useful than actually
forcing I/O, backing up and rewriting. It's also not clear
that your alternative has the same effect since it seems that
some unwanted side-effects would occur such as premature appearance
on a display screen.
>>
>> Page 24 -- I can't figure out what you intend the meaning of SIMPLE-STRING
>> to be. Your report mostly does not mention it, but it doesn't say to
>> remove it either. If I have correctly correlated page 24 back to CLtL, you
>> are defining SIMPLE-STRING to be synonymous with SIMPLE-GENERAL-STRING.
>> Maybe what you really meant, though, was what you said in November you
>> would do, which was to make SIMPLE-STRING mean (AND STRING SIMPLE-ARRAY),
>> in other words a union of several subtypes. This is particular confusing
>> because Common Lisp uses the name SIMPLE-VECTOR to mean what you might call
>> a simple general vector, that is, (SIMPLE-ARRAY T 1) rather than
>> (SIMPLE-ARRAY * 1). Here are my suggestions for what to do with the
>> various names for string subtypes:
>>
>> STRING As a union of all strings, this is fine.
>> GENERAL-STRING I think (VECTOR CHARACTER) is just as good.
>> BASE-STRING I think (VECTOR BASE-CHARACTER) is just as good.
>> SIMPLE-STRING Should mean (SIMPLE-ARRAY CHARACTER 1).
>> SIMPLE-BASE-STRING This is fine.
>> SIMPLE-GENERAL-STRING This name is horrible, use SIMPLE-STRING.
>>
>> My rationale for these suggestions largely comes from thinking about
>> which of these names would ever be used in type declarations and about
>> how these names relate to the other names already in Common Lisp. To
>> repeat older comments:
>>
>> Pages 19 and 20 introduce a new type named simple-base-string, in addition
>> to simple-string. If you think about how simple-string would be used for
>> compiler optimization, it makes sense for simple-string to be the name for
>> the single simplest representation, rather than a name for a whole family
>> of representations that would have to be discriminated at run time. Thus
>> what you call simple-base-string should be called simple-string, and what
>> you call simple-string should just be called (simple-array character (*)).
>> This would not be an incompatible change in the meaning of simple-string.
>> Simple-string would be analogous to simple-vector.
>>
>> I changed my mind slightly on that and now claim that while SIMPLE-STRING
>> should still be a single representation, not a union, it should be the
>> representation that can hold all characters. This is both because of the
>> principle that correct programs should be easier to write than
>> extra-efficient programs, and because of the powerful analogy with the name
>> SIMPLE-VECTOR. Then the name SIMPLE-BASE-STRING is also needed for
>> convenient type declarations of the more efficient but less functional
>> string representation. That name is good, by analogy to BASE-CHARACTER.
>>
>> Adopting the above suggestions helps you decide what to do about the
>> SCHAR, SBCHAR, and SGCHAR mess. First of all, you only need two functions,
>> not three, because there are only two specified specialized representations.
>> SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
>> for SIMPLE-BASE-STRING, and SGCHAR is not needed. (In fact I would prefer
>> to remove all of the specialized versions of AREF from the language, in
>> favor of THE or type declarations, but I know that would only pass over
>> some peoples' dead bodies so I won't push it.)
>>
>> In case you are wondering, I have no quarrel with the name BASE-CHARACTER
>> and would not want to see it removed. I guess I differ from Larry here,
>> unless I erred when I wrote down his comments during the meeting.
The statement on p24 making SIMPLE-STRING == (SIMPLE-ARRAY CHARACTER (*))
was in error. P25 had it right. Since we changed SCHAR to accept
all simple strings there is no reason for SGCHAR and SBCHAR and
these are eliminated.
String and simple-string are (more clearly I hope) defined as union
types. I've changed the terminology from 'for the purpose of
declaration' to 'for object creation'. Perhaps there is a better
term but the effect seems to be identical to what you suggest. That is,
correct, portable programs are easier to write, one simply uses
string and simple-string. More efficient, less portable programs
need to specify the specialized subtype(s) explicitly.
Having both string and simple-string defined as union types seems
desirable on the basis of uniformity.
Of the type abbreviations I think BASE-CHARACTER is the most
useful and GENERAL-STRING, SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING
less so. I don't believe that any of these really complicate the
language.
>>
>> Page 25 -- The discussion of STRING and SIMPLE-STRING thinks that there
>> is a distinction between declaration and discrimination, but Common Lisp
>> no longer has such a distinction. Even when Common Lisp did have such
>> a distinction, the meanings for declaration stated here were incorrect.
I changed this to 'object creation'. Perhaps there is a better term.
>>
>> Page 29 -- *all-character-registry-names* has to be a variable, not a
>> constant, to accomodate systems (such as Symbolics Genera) that allows
>> dynamic addition of character registries by third-party software vendors
>> and by users.
Right, I made this change.
>>
>> Page 35 -- CHAR-REGISTRY should be renamed to CHAR-REGISTRY-NAME, so that
>> if at some later time character registry objects are added, there is no
>> possibility of confusion about whether this function returns a name or
>> an object.
Right, I made this change.
>>
>> Page 40 -- the default :ELEMENT-TYPE for OPEN cannot be BASE-CHARACTER. I
>> think this was discussed at the X3J13 meeting. The report suffers from a
>> confusion between two meanings of BASE-CHARACTER: the character type
>> implemented most efficiently by the Lisp, and the character type most
>> natural to the file system. These are not always the same. Furthermore,
>> in a network-based system that supports multiple file systems equally
>> (Symbolics Genera is an example), each file system might have a different
>> natural character type. BASE-CHARACTER should just mean the character type
>> implemented most efficiently by the Lisp. The default for :ELEMENT-TYPE
>> has two viable choices that I can see, and maybe you should just propose
>> both and let people vote:
>>
>> (1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
>> adheres to the principle that writing correct programs should be easier
>> than writing extra-efficient programs (since making a program correct
>> requires making every part of it correct, while making a program
>> efficient only requires improving the bottlenecks), and doesn't cost
>> anything in implementations that don't have extended characters.
>>
>> (2) The most natural type for the particular pathname being opened.
>> In some systems this would be a constant, and in a subset of those
>> systems this would be BASE-CHARACTER, however in general this might
>> depend on the host, device, or even type fields of the pathname,
>> and might also depend on information stored in the file system.
>> In general this would always be an (improper) supertype of
>> BASE-CHARACTER, but it's probably a bad idea to make that a requirement,
>> as some file systems might not be able to implement it conveniently.
>> Again this doesn't cost anything in implementations that don't have
>> extended characters.
The discussion on p16 about the base coded character set efficiency
has been removed. The default element-type now states that it is
implementation defined as character or a subtype of character.
>>
>> The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
>> already exists in Common Lisp) needs to be clarified. Perhaps they
>> are the same.
The same? I don't understand. For example, I can imagine the
element-type default as base-character and the external format
defaulted to either an ASCII or EBCDIC encoding.
>>
>> Also the following promise from 14 November did not show up in the report:
>>
>> >> There should be a name for the "natural" encoding and there should be a
>> >> specification of the properties of the natural encoding that a programmer
>> >> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> >> :INTERCHANGE. The definition probably involves the concept of data
>> >> interchange with non-Lisp programs on the same system.
>>
>> This will be added to the revision.
I lied. No one came up with the 'properties' of such an encoding.
Do you have some text to suggest?
>>
>> Appendix B -- I disagree with the way you've used deprecation. I'll
>> comment on each individual point:
>> - I see no justification for deprecating STANDARD-CHAR.
>> - I agree that STRING-CHAR should be deprecated, not deleted nor kept.
>> - I think fonts and bits should be removed outright, not deprecated,
>> because no portable program could possibly be using them.
>> - I think the CHAR-INT function needs to be kept, although the INT-CHAR
>> function should go away. This is for hashing. See comments below
>> on character attributes.
I've removed Appendix B and mention of deprecation. STANDARD-CHAR
is simply (characterp :standard). String-char is back in as
implementation-defined either character or base-character (and
maybe should be voted as a deprecated type).
>>
>> No particular page -- the use of strings for naming registries, labelling
>> characters, and naming external code formats is objectionable. Nothing
>> else in Common Lisp is named by strings. Use of strings might lead to
>> efficiency problems. We feel that keyword symbols are the appropriate
>> objects to use for these three kinds of names.
I changed these back to symbols.
>>
>> No particular page -- We agree with the deprecation or deletion of the two
>> particular character attributes defined by CLtL, but not with the
>> deprecation of the whole concept of character attributes. In fact on page
>> 20 you say "characters are uniquely distinguished by their codes," which
>> makes it impossible to have character attributes at all. The language must
>> define how conforming programs should be written so that they will work
>> both in implementations with character attributes and in implementations
>> without them. For example, the value of (eql x (code-char (char-code x)))
>> is unspecified. Another thing that needs to be said is that the exact
>> character operations (char=, string=, etc.) respect all character
>> attributes, while the inexact character operations (char-equal,
>> string-equal, etc.) respect or ignore each character attribute in an
>> implementation-defined but consistent fashion. Some of what you say on
>> page 44 about attributes in general needs to be part of the spec, not
>> deprecated. I would retain everything on that page except for INT-CHAR and
>> the last bullet (referring to bits and fonts), and I would add a remark
>> that FIND-SYMBOL and INTERN respect character attributes. If you want,
>> perhaps I or someone else at Symbolics can provide exact text for what
>> to say about character attributes that you could insert into your report.
I moved the attribute list previously in Appendix B back into the
description of characters. Let me know what text you would like
to see for FIND-SYMBOL and INTERN and I'll add it to the list.
>> No particular page -- On the subject of defining character registries in a
>> separate document, and relating them to ISO standards for character
>> encoding: I think that's fine. I don't see anything wrong with introducing
>> the concept of character registry and the requirement that each character
>> object relates to exactly one registry. However, I think the somewhat
>> random list of character registries on pages 7-8 and again on page 21 does
>> not belong in the language specification. Even the names of the
Right. They are not part of the Common LISP standard. The revised
document is considerably clearer in this regards.
>> standardized character registries belong in the character registry
>> standard, not in the Common Lisp language standard. I'm confused about the
>> meaning of BASE, STANDARD, and CONTROL as character registry names; these
>> are mentioned in your report but not explained very well. If these are
>> character registries that are required to exist in all Common Lisp
>> implementations, then unlike the others they do belong in the Common Lisp
>> language standard, not in the character registry standard.
By CONTROL, I meant a registry which contains the various control
codes mentioned in the various ISO coded character set standards.
BASE and STANDARD are no longer mentioned here. They are allowed
as Common LISP repertiore names in characterp and the character
type specifier.
>>
>> At the meeting there was some discussion about the issue of enumerating all
>> characters in a character registry. People claimed incorrectly that it was
>> impossible. In fact it's possible to do this, with questionable
>> efficiency, by the following program:
>>
>> (dotimes (code char-code-limit)
>> (let ((char (code-char code)))
>> (when char
>> (when (eq (char-registry-name char) desired-registry-name)
>> ... process this char ...))))
>>
>> Of course you have to change the EQ to EQUALP if you continue to use
>> strings to name character registries. For more efficiency, you could add
>> a way to iterate over all the codes in one character registry, but I think
>> that is unnecessary.
>>
>>
>> TYPOS:
Right. I've made these corrections.
>>
>> 25 -- base-string is missing from the Table 4-1 amendment.
>>
>> 26 -- general-string is not an array of BASE characters, also the first
>> two paragraphs under A.4.8 are garbled (the two separate sentences for
>> strings for symbols got smushed together).
>>
>> 37 -- This says the default for the :ELEMENT-TYPE option to MAKE-STRING
>> is SIMPLE-STRING. Actually it's CHARACTER.
>>
=========================================================================
Date: Wed, 22 Feb 89 03:48:56 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.034856.baggins@almvma>
Subject: cs proposal comments
>> From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
>> Subject: comments on character proposal
>>
>> Getting rid of bits and fonts (section 2.1) seems like a very good
>> idea to me. I would argue for deleting these "features" completely
>> instead of merely deprecating them, because there now seems to be
>> general agreement that the whole idea was brain-damaged in the first
>> place, plus it's just about impossible to use them portably anyway
>> (since implementations are free not to support them). Deprecating the
>> features would simply perpetuate the current sad state of affairs in
>> to the ANSI standard.
I deleted Appendix B from the proposal. The attribute check list is
incorporated into the character chapter as implementation dependent.
>>
>> I am not at all sure why we need to standardize the idea of character
>> registries at all, much less state that a character can only belong to
>> one registry, or define a standard set of registries. What does having
>> registries buy the user, other than perhaps a way to test whether a
>> character belongs to one or not? Why isn't it sufficient just to say
>> that implementations can support extended characters, and leave it at
>> that?
The registries are introduced to allow an application a portable
way to name, compose and decompose characters. Currently, there is
no way to do this in any programming language. There are other
possiblities. For example, simply labeling all characters
uniquely; another to define a universal coded character set and use
these numeric codes to 'name' characters. I don't think using
numbers for naming characters is useful since I'll always forget
what character 34539 actually is! Registries seem to provide a
framework for useful categorization of characters. It also
avoids the current mess that the coded character set standards
are in.
>>
>> I'm confused about how you propose to handle characters that appear in
>> more than one character repetoire, and whether characters with accent
>> marks are considered distinct from characters without accents. For
>> example, is the French "C" with a cedilla distinct from a normal
>> French "C", and is that distinct from the standard-char "C"?
We handle characters that appear in more than one repertoire by
using registries. No character appears in more than one registry.
The constituents of the registries are not defined by Common LISP.
I believe that in most environments today, it is recognized that
characters with accents are distinct from their vanilla cousins.
As we have proposed registries, they contain semantically
distinct characters.
>>
>> The way the document describes things now, it seems like the Common
>> Lisp standard would have to include a statement of exactly what
>> characters belong in each of the standard registries listed in section
>> 2.2. Otherwise, implementors might go off and define their own
>> character registries that happen to include some characters that ought
>> to belong in one of these standard registries. For instance, the machine
>> I happen to be sitting in front of right now supports an 8-bit native
>> character set, and it seems perfectly reasonable for a Lisp runnning on
>> this machine to include all 256 characters in its base character set,
>> but some of those might actually be supposed to live off in some other
>> registry.
The registries are independent of any coded character sets.
In particular, coded character sets are not registries. Your base
repertoire (set of 256 characters) are possibly drawn from
several registries.
You are correct that lacking an international standard (or ANSI one),
for character registries an implementation could define the
a single registry containing all supported characters. It could
also define NO registries and use only the conventional naming
of characters. I expect an implementation taking the no-cost way
would choose the second approach. On the other hand, an
implementation supporting text processing across international
boundaries is more likely to define some reasonable registries
eg. Latin, Greek, etc..
>>
>> Also in section 2.2, why is it necessary for there to be a total
>> ordering, or even a partial ordering, of all characters? It seems
>> like CHAR< and friends are not very useful except when comparing base
>> characters anyway. It seems like it would difficult to get things
>> like the Spanish N-with-twiddle character to collate correctly anyway,
>> given the constraints you have put on how character codes are derived
>> and the requirement that CHAR< be just like < on the char-codes.
Right. This is now removed.
>>
>> It doesn't seem like STANDARD-CHAR-P belongs in the list of character
>> predicates on p. 9, since no extended characters can possibly be
>> STANDARD-CHAR-P anyway.
Right. This is now removed.
>>
>> The stuff in section 2.3 seems mostly reasonable to me. It's not really
>> clear why you need GENERAL-STRING (as distinct from STRING) and
>> SIMPLE-GENERAL-STRING (as distinct from SIMPLE-STRING). Again, some
>> rationale would be helpful.
GENERAL-STRING means (VECTOR CHARACTER). This is not the meaning of
STRING (a union type). I agree that GENERAL-STRING is not much
of an abbreviation over (VECTOR CHARACTER). It still seems somewhat
more mnemonic.
>>
>> In section 2.4, the general idea of specifying an external character
>> encoding to OPEN seems reasonable. However, I'm confused by the
>> business about having more than one coded character set mixed
>> together. If a character appears in more than one coded character
>> set, which encoding takes precedence? It seems like this has not been
>> well thought-out. Also, seeing as though we have just voted down a
>> proposal to add an EXTERNAL-WIDTH function, it seems like a very bad
>> idea to lump it in here.
Some encoding schemes allow disjoint coded characters sets to
coexist. That is, a given character would appear on one but not
the other. For example, a ISO8859/1 coded character set could
coexist with a coded character set for Chinese.
As for External-width, it was part of our subcommittee discussions
long before the recent stream proposal. It will be a separate
item in the list of character votes.
>>
>> Now for the general comments.
>>
>> One thing that is not clear to me from reading this document is how
>> much of it has already been standardized by ISO. I share Larry's
>> concern that we might standardize one thing, and then have ISO go off
>> and standardize something completely different. I think it's a
>> mistake to try to second-guess what ISO might do.
The revision might make this clearer. I think this is a
red herring anyhow. As a programming language committee
we need to specify what is useful in the context of LISP. We
can't expect a coded character set committee to figure it out.
On the other hand, we can influence what gets standardized
by defining our framework. The ISO Prolog std committee is
interested in what we define.
>>
>> I am also concerned about trying standardize things that have not yet
>> been implemented. I think it's a mistake to try to do language design
>> in a standards committee.
>>
>> Finally, I have some problems with the presentation of your proposal.
>> One problem, as I mentioned at the meeting, is that you've made it an
>> all-or-nothing package, and I can't vote for the whole thing because
>> there are some parts of it that do not seem appropriate, even though I
>> would support some of the other changes individually. The other
>> problem is that Appendix A is virtually unreadable. Some of the
>> conceptual changes involve wording changes to several passages, and I
>> know that there are some other changes in the appendix that are not
>> mentioned in the introductory blurb at all. Is it totally impossible
>> to recast the changes in standard cleanup format proposals? The
>> advantage of that format is that it presents more context, including a
>> clear statement of why the existing CLtL behavior is "broken" and a
>> rationale for the proposed change.
There will be several votes regarding this proposal. I don't
intend to rewrite the document in a cleanup format.
>>
>> I know that we adopted things like the CLOS document that were
>> presented as single mega-proposals, but those were primarily additions
>> to the language and what you are proposing is essentially a large
>> number of incompatible changes. I'm having a hard time identifying
>> what all of those changes are.
>>
Actually, I don't think it's as large a number of changes as you
imply. In any case, the vote split should help this out.
=========================================================================
Date: Wed, 22 Feb 89 04:51:15 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
cc: David Gray <GRAY%DSG.CSC.TI.COM@RELAY.CS.NET>
Message-ID: <890222.045115.baggins@almvma>
Subject: cs proposal comments
>> From: David N Gray <Gray@DSG.csc.ti.com>
>> Subject: characters proposal
>>
>> I have read the documented titled "Extensions to Common LISP to Support
>> International Character Sets" dated January 1, 1989, and feel that it is
>> not much of an improvement over what we saw in October. Following are
>> some random comments about things I happened to notice; this is not
>> intended to be a comprehensive analysis.
>>
>> First, documents such as this ought to be labelled with an X3J13
>> document number so that they can be referred to conveniently and
>> unambiguously.
>>
>> "Appendix A" and "Appendix B" really should be chapters 3 and 4 since
>> they are an essential part of the proposal, rather than being an
>> appendage to it.
Appendix B is now eliminated. Appendix A is really quite unlike
chapters 1 and 2 in structure.
>>
>> Page 7 says that the definition of semi-standard-characters "is replaced
>> by a more uniform approach with introduction of the Control Character
>> Registry". Do you really mean that it _will_be_ replaced when the
>> Control Character Registry is defined in some subsequent document? I
>> certainly don't see anything in this document that could be considered a
>> replacement.
Yes. The revision is clearer on this. This document does not define
names for character registries nor their constituents.
>>
>> This whole concept of registries seems rather strange. Is the intent
>> that the alphabetic characters of the standard characters are to be in
>> the "Latin" registry while characters such as period and comma are in
>> "Latin-Punctuation"? Is #\NEWLINE in the "Control" registry? Where do
>> the digits go -- "Mathematical"?. Is #\- a "Latin-Punctuation" or a
>> "Mathematical"? Which registry is #\SPACE in? Now tell me what to do
>> with the extra non-Latin alphabetic characters used in Sweedish? Does
>> that require a separate registry for just those additional characters?
>> Now we have simple text in a single language using characters from at
>> least four different registries. Do you really think it possible to
>> agree on a "fixed", non-extensible, set of "Mathematical" or "Pattern"
>> characters?
Actually, I believe the simplicity of the registry framework will make
agreement easy. Currently, members of the coded character set
committees spend vast amounts of time lobbying for inclusion of their
favorite character(s) in the 'popular' coded character set standard.
The effect of not being included means fewer installations will
support their native language properly.
I think a new group, hopefully formed within
programming languages, should define the registries rather than
the existing coded character set committees. There is no competition
between registries, ie. no advantage of one over another. What this
committee has to agree upon is 1) a useful set of registry names and
2) definition of the constituents of each registry. The only argument
I would anticipate is "are the semantics of my alpha the same
or different from your alpha" type debates.
By the way,
the registries are fixed only in that a Common LISP implementation
cannot modify the standard definitions. This guarantees an application
program can portably rely on the composition and decomposition
functions to establish the availability of any given character.
>>
>> Page 9 says that an implementation needs to specify the total ordering
>> of characters within each registry, but what about the ordering of
>> characters in different registries? Is that completely undefined?
There is no ordering of characters within registries. As mentioned
in Hawaii, the character index (a number) was changed to character
label (a symbol) throughout the proposal.
>>
>> Page 25 section A.4.5 doesn't specify the syntax of a registry name; did
>> you intend it to be a string?
These have been changed to be symbols.
>>
>> Page 27 has an example using (typep x '(character "standard")) but
>> page 25 said that had to be a registry name; "standard" is not a
>> registry name.
The revision is clearer on this. character and characterp can take
registry names, :base or :standard. The meaning of :base and :standard
is defined by Common LISP as the base character repertoire and
standard character repertoire respectively.
>>
>> Page 29 - *ALL-REGISTER-NAMES* -- a list of strings?
Now a list of symbols.
>>
>> Page 33 -- FIND-CHAR -- does the index value within a registry have any
>> portable meaning? Is that intended to be specified for the standard
>> registries? Is "base" supposed to be accepted here? If not, how can
>> you access the base codes? If I were going to construct a character
>> from its index value, it would be more meaningful to use an index
>> relative to some coded character set rather than these registries.
FIND-CHAR takes a character label and registry. These are specified
by the registry standard. Base is not a registry name. We have
introduced a new function CHAR-CCS-VALUE which takes a character
object and a coded character set name (a symbol) and returns the
encoding of the character in the coded character set.
>>
>> Page 36, the last sentence doesn't make sense. The default for
>> :ELEMENT-TYPE would have to be either CHARACTER or BASE-CHARACTER.
Right. I've made this change.
>>
>> Page 37, section A.22.1.1 -- the part being deleted specifies the
>> meaning of including tab and form-feed characters in a Common Lisp
>> source file; do you really intend that to not have any standard meaning?
>> If my editor uses tabs for indenting, does that mean that the resulting
>> source file is not a standard-conforming program?
That really depends on the definition of a conforming program. Is
this defined yet?
>>
>> Page 38, the first reference to p360 of CLtL should be p353; the
>> deletion here says that there shall not be any standard name for the
>> commonly used control characters such as tab and form-feed. That still
>> seems wrong to me.
>>
>> Page 41, what's the point of appending "ccs" to the name of the
>> standard? Presumably that stands for "coded character set", but isn't
>> that adequately implied by the fact that this string will follow the
>> keyword :EXTERNAL-CODE-FORMAT ? The use of "default" seems odd since
>> :DEFAULT is used everywhere else.
This was to distinguish from someone referring to the set of characters
(repertoire) represented in a given coded character set. Ie. to
distinguish ISO8859/6-1987 coded character set from the ISO8850/6-1987
repertoire. In fact, the ISO coded character set standards never
refer to repertoires in isolation (ie. without the codes), so I've
dropped the 'ccs'. Also, "default" is now :DEFAULT as elsewhere.
>>
>> I agree with Moon that the excising of bits and fonts has not been done
>> carefully enough for them to be compatible extensions.
>>
I think the new revision takes care of this by incorporating the
attribute list as part of the language proper (ie. not deprecated).
∂22-Feb-89 1339 X3J13-mailer cs proposal part 3 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:38:49 PST
Date: Wed, 22 Feb 89 10:08:51 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100851.baggins@almvma>
Subject: cs proposal part 3 of 3
%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters} % 13
%----------------------------------------------------------------------
\edithead {\csdag 6 after (p233)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd char-code-limit} [{\clkwd Constant}]
\\ &
The value of {\clkwd char-code-limit} is a non-negative integer
that is the upper exclusive bound on values produced by the
function {\clkwd char-code}, which returns the {\em code}
of a given character; that is, the values returned by
{\clkwd char-code} are non-negative and strictly less than
the value of {\clkwd char-code-limit}.
There may be unassigned codes between 0 and
{\clkwd char-code-limit} which
are not legal arguments to {\clkwd code-char}.
\\ &
\cltxt
{\clkwd *all-character-registry-names*} [{\clkwd Variable}]
\\ &
The value of {\clkwd *all-character-registry-names*} is a list of
all character registry names supported by the implementation.
\editend
\setcounter{subsection}{0}
\subsection{Character Attributes} % 13.1.
\edithead {\csdag replace entire section (p233)}
\editstart
\\ \bf with &
\cltxt
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects. These are
considered implementation-defined attributes and
if supported by an implementation
effect the action of selected functions. In particular,
the following effects are noted:
\\ &
\begin{itemize}
\item Attributes, such as those
dealing with how the character is displayed or its typography,
are not part of the character code.
For example, bold-face, color
or size are not considered part of the character code.
\item If two characters differ in any attributes,
then they are not {\clkwd char=}.
\item If two characters have identical
attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code attributes. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item The effect, if any, on {\clkwd char-equal} of each
attribute has to be specified as part of
the definition of that attribute.
\item The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve attributes.
\item The function {\clkwd char-int} is equivalent to {\clkwd char-code}
if no attributes are associated with
the character object.
\item The function {\clkwd int-char} is equivalent to {\clkwd code-char}
if no attributes are associated with
the character object.
\item It is implementation dependent whether characters within
double quotes have attributes removed.
\item It is implementation dependent whether
attributes are removed from symbol names by {\clkwd read}.
\end{itemize}
\editend
\setcounter{subsection}{1}
\subsection{Predicates on Characters} % 13.2.
\edithead {\csdag 3 (p234)}
\editstart
\\ \bf replace &
\cltxt
argument is a "standard character" that is, an object of type
{\clkwd standard-char}.
Note that any character with a non-zero {\em bits} or {\em font}
attribute
is non-standard.
\\ \bf with &
\cltxt
argument is one of the Common LISP standard character subrepertoire.
\editend
\\
\edithead {\csdag 4 (p234)}
\editstart
\\ \bf delete &
\cltxt
Note that any character with non-zero ...
\editend
\\
\edithead {\csdag 6 (p235)}
\editstart
\\ \bf replace &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
The semi-standard characters \#$\backslash${\clkwd Backspace},
\#$\backslash${\clkwd Tab},
\#$\backslash${\clkwd Rubout},
\#$\backslash${\clkwd Linefeed},
\#$\backslash${\clkwd Return},
and \#$\backslash${\clkwd Page} are not graphic.
\\ \bf with &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
\editend
\\
\edithead {\csdag 7 (p235)}
\editstart
\\ \bf delete &
\cltxt
Programs may assume that graphic ...
\editend
\\
\edithead {\csdag 8 (p235)}
\editstart
\\ \bf delete &
\cltxt
Any character with a non-zero bits...
\editend
\\
\edithead {\csdag 9 (p235)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd string-char-p} ...
\editend
\\
\edithead {\csdag 10 (p235)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 13 (p235)}
\editstart
\\ \bf replace &
\cltxt
If a character is alphabetic, then it is perforce graphic. Therefore
any character
with a non-zero bits attribute cannot be alphabetic. Whether a
character is
alphabetic is may depend on its font number.
\\ \bf with &
\cltxt
If a character is alphabetic, then it is perforce graphic.
\editend
\\
\edithead {\csdag 22 (p236)}
\editstart
\\ \bf replace &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic, and therefore has a zero bits attribute).
However, it is permissible in theory for an alphabetic character
to be neither
uppercase nor lowercase (in a non-Roman font, for example).
\\ \bf with &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic).
\editend
\\
\edithead {\csdag 25 (p236)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object, and {\em radix}
must be a non-negative
integer. If {\em char} is not a digit of the radix specified
\\ \bf with &
\cltxt
The argument {\em char} must be in the standard character
subrepertoire and
{\em radix} must be a non-negative integer.
If {\em char} is not a standard character or is not a digit of the
radix specified
\editend
\\
\edithead {\csdag 51 (p237)}
\editstart
\\ \bf delete &
\cltxt
If two characters have the same bits ...
\editend
\\
\edithead {\csdag 52 (p237)}
\editstart
\\ \bf replace &
\cltxt
If two characters differ in any attribute (code, bits, or font), then
they are different.
\\ \bf with &
\cltxt
If the codes of two characters differ, then
they are different.
\editend
\\
\edithead {\csdag 94 (p239)}
\editstart
\\ \bf replace &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of bits
attributes and case are ignored, and font information is taken into
account in an implementation dependent manner.
\\ \bf with &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of case
are ignored.
\editend
\\
\edithead {\csdag 97 example (p239)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-equal \#$\backslash$A \#$\backslash$Control-A) is true}
\editend
\\
\edithead {\csdag 98 (p239)}
\editstart
\\ \bf delete &
\cltxt
The ordering may depend on the font ...
\editend
\setcounter{subsection}{2}
\subsection{Character Construction and Selection} % 13.3.
\edithead {\csdag 3 (p239)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} attribute of the
character object;
this will be a non-negative integer less than the (normal) value
\\ \bf with &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} of the
character object;
this will be a non-negative integer less than the value
\editend
\\
\edithead {\csdag 4 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-bits } ...
\editend
\\
\edithead {\csdag 5 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 6 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-font } ...
\editend
\\
\edithead {\csdag 7 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 8 (p240)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd code-char {\em code} \&optional {\em (bits 0) (font 0)}
[{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd code-char {\em code}
[{\em Function}]}
\editend
\\
\edithead {\csdag 9 (p240)}
\editstart
\\ \bf replace &
\cltxt
All three arguments must be non-negative integers. If it is possible
in the
implementation to construct a character object whose code attribute
is {\em code},
whose
bits attribute is {\em bits}, and whose font attribute is {\em font},
then such an object
is returned;
\\ \bf with &
\cltxt
The argument must be a non-negative integer. If it is possible
in the
implementation to construct a character object identified by
{\em code},
then such an object is returned;
\editend
\\
\edithead {\csdag 10 (p240)}
\editstart
\\ \bf replace &
\cltxt
For any integers, {\em c, b,} and {\em f}, if {\clkwd (code-char
{\em c b f})} is
\\ \bf with &
\cltxt
For any integer, {\em c}, if {\clkwd (code-char
{\em c})} is
\editend
\\
\edithead {\csdag 12 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-bits (code-char } ...
\editend
\\
\edithead {\csdag 13 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-font (code-char } ...
\editend
\\
\edithead {\csdag 14 (p240)}
\editstart
\\ \bf delete &
\cltxt
If the font and bits attributes ...
\editend
\\
\edithead {\csdag 15 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char= (code-char (char-code ...}
\editend
\\
\edithead {\csdag 16 (p240)}
\editstart
\\ \bf delete &
\cltxt
is true.
\editend
\\
\edithead {\csdag 17 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd make-char} ...
\editend
\\
\edithead {\csdag 18 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf delete &
\cltxt
If {\em bits} or {\em font} are zero ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf append &
\cltxt
{\clkwd find-char} {\em label registry} [{\em Function}]
\\ &
{\clkwd find-char} returns a character object.
The arguments {\em label} and {\em registry} are names
(objects coerceable to strings as if by the function {\clkwd string})
of character registries and labels.
{\em label}
uniquely identifies a character within the character
registry named {\em registry}.
If the implementation does not support the specified
character, {\clkwd nil} is returned.
\editend
\setcounter{subsection}{3}
\subsection{Character Conversions} % 13.4.
\edithead {\csdag 8 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd char-upcase} returns a character object with the same
font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
{\clkwd char-upcase} returns a character object with possibly
a different code.
\editend
\\
\edithead {\csdag 10 (p241)}
\editstart
\\ \bf replace &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with the
same font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with
possibly a different code.
\editend
\\
\edithead {\csdag 12 (p241)}
\editstart
\\ \bf delete &
\cltxt
Note that the action of ...
\editend
\\
\edithead {\csdag 13 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
({\em font} 0) [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
[{\em Function}]}
\editend
\\
\edithead {\csdag 14 (p241)}
\editstart
\\ \bf replace &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible
to construct a character object whose font attribute is {\em font},
and whose {\em code}
\\ \bf with &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible to construct a character object whose {\em code}
\editend
\\
\edithead {\csdag 15 (p242)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil} if {\em font}
is zero, {\em radix}
\\ \bf with &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil}.
{\em radix}
\editend
\\
\edithead {\csdag 22 (p242)}
\editstart
\\ \bf delete &
\cltxt
Note that no argument is provided for ...
\editend
\\
\edithead {\csdag 23 through 30 (p242, char-int, int-char)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-int} {\em char}
\editend
\\
\edithead {\csdag 32 (p242)}
\editstart
\\ \bf replace &
\cltxt
All characters that have zero font and bits attributes and that are
non-graphic
\\ \bf with &
\cltxt
All characters that are
non-graphic
\editend
\\
\edithead {\csdag 33 (p243)}
\editstart
\\ \bf replace &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}. The semi-standard
characters have the names {\clkwd Tab, Page, Rubout, Linefeed,
Return,} and {\clkwd Backspace}.
\\ \bf with &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}.
\editend
\\
\edithead {\csdag 35 (p243)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-name} will only locate "simple" ...
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd name-char} may accept other names for characters
in addition to those returned by {\clkwd char-name}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-registry-name} {\em char} [{\em Function}]
\\ &
{\clkwd char-registry-name} returns a string representing
the character registry to which {\em char} belongs.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-label} {\em char} [{\em Function}]
\\ &
{\clkwd char-label} returns a string representing
the character label of {\em char}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-ccs-value} {\em char name} [{\em Function}]
\\ &
{\clkwd char-ccs-value} returns the non-negative integer
representing the encoding of the character {\em char} in
The coded character set named by {\em name}.
If the implementation does not support the specified
coded character set, {\clkwd nil} is returned. If the
named coded character set does not contain the character,
{\clkwd nil} is returned.
\editend
\setcounter{subsection}{4}
\subsection{Character Control-Bit Functions} % 13.5.
\edithead {\csdag delete entire section (p243)}
\editstart
\editend
%----------------------------------------------------------------------
\setcounter{section}{13}
\section{Sequences} % 14
%----------------------------------------------------------------------
\setcounter{subsection}{0}
\subsection{Simple Sequence Functions} % 14.1
\edithead {\csdag 21 (p249,make-sequence)}
\editstart
\\ \bf append &
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{17}
\section{Strings} % 18
%----------------------------------------------------------------------
\edithead {\csdag 1 (p299)}
\editstart
\\ \bf replace &
\cltxt
Specifically, the type {\clkwd string} is identical to the type
{\clkwd (vector string-char),}
which in turn is the same as {\clkwd (array string-char (*))}.
\\ \bf with &
\cltxt
Specifically, the type {\clkwd string} is a subtype of
{\clkwd vector}
and consists of vectors specialized by subtypes of {\clkwd character}.
\editend
\setcounter{subsection}{0}
\subsection{String Access} % 18.1.
\edithead {\csdag 4 (p300)}
\editstart
\\ \bf replace &
\cltxt
character object. (This character will necessarily satisfy the
predicate
{\clkwd string-char-p}).
\\ \bf with &
\cltxt
character object.
\editend
\\
\edithead {\csdag 9 (p300)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
\\ \bf with &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
The new character must be of a type which can be stored in the
string; it is an error otherwise.
\editend
\setcounter{subsection}{2}
\subsection{String Construction and Manipulation} % 18.3.
\edithead {\csdag 2 (p302)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element :element-type
[{\em Function}]}
\editend
\\
\edithead {\csdag 3 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
This returns a string (in fact a simple string) of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
\\ \bf with &
\cltxt
This returns a string of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
The {\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type.
If {\clkwd :element-type} is omitted, the type
{\clkwd character} is the default.
\editend
\\
\edithead {\csdag 5 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
A string is really just a one-dimensional array of "string
characters" (that is,
those characters that are members of type {\clkwd string-char}).
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\\ \bf with &
\cltxt
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\editend
\\
\edithead {\csdag 29 (p304,make-string)}
\editstart
\\ \bf replace &
\cltxt
If {\em x} is a string character (a character of type
{\clkwd string-char}), then
\\ \bf with &
\cltxt
If {\em x} is a character, then
\editend
%----------------------------------------------------------------------
\setcounter{section}{21}
\section{Input/Output} % 22
\setcounter{subsection}{0}
\subsection{Printed Representation of LISP Objects} % 22.1.
\setcounter{subsubsection}{0}
\subsubsection{What the Read Function Accepts} % 22.1.1.
\edithead {\csdag Table 22-1: Standard Character Syntax Types (p336)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <tab>} {\em whitespace}
\\ &
{\clkwd <page>} {\em whitespace}
\\ &
{\clkwd <backspace>} {\em constituent}
\\ &
{\clkwd <return>} {\em whitespace}
\\ &
{\clkwd <rubout>} {\em constituent}
\\ &
{\clkwd <linefeed>} {\em whitespace}
\editend
\setcounter{subsubsection}{1}
\subsubsection{Parsing of Numbers and Symbols} % 22.1.2.
\edithead {\csdag Table 22-3: Standard Constituent Character
Attributes (p340)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <backspace>} {\em illegal}
\\ &
{\clkwd <tab>} {\em illegal}
\\ &
{\clkwd <linefeed>} {\em illegal}
\\ &
{\clkwd <page>} {\em illegal}
\\ &
{\clkwd <return>} {\em illegal}
\\ &
{\clkwd <rubout>} {\em illegal}
\editend
\setcounter{subsubsection}{3}
\subsubsection{Standard Dispatching Macro Character Syntax} % 22.1.4.
\edithead {\csdag Table 22-4: Standard \# Macro Character Syntax (p352)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd \#<backspace>} {\em signals error}
\\ &
{\clkwd \#<tab>} {\em signals error}
\\ &
{\clkwd \#<linefeed>} {\em signals error}
\\ &
{\clkwd \#<page>} {\em signals error}
\\ &
{\clkwd \#<return>} {\em signals error}
\\ &
{\clkwd \#<rubout>} {\em undefined}
\editend
\\
\edithead {\csdag 8 (p353)}
\editstart
\\ \bf replace &
\cltxt
The following names are standard across all implementations:
\\ \bf with &
\cltxt
All non-graphic
characters, including extended characters, are uniquely
named in an implementation-dependent manner.
In particular, an implementation may support names of the
form {\em label:registry}.
The following names are standard across all implementations:
\editend
\\
\edithead {\csdag 11 through 18 inclusive delete (p353)}
\editstart
\\ \bf delete &
\cltxt
The following names are semi-standard; ...
\editend
\\
\edithead {\csdag 20 through 26 inclusive delete (p354)}
\editstart
\\ \bf delete &
\cltxt
The following convention is used in implementations ...
\editend
\\
\edithead {\csdag 108 (p360)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd \#<space>, \#<tab>, \#<newline>, \#<page>, \#<return>}
\\ \bf with &
\cltxt
{\clkwd \#<space>, \#<newline>}
\editend
\setcounter{subsubsection}{4}
\subsubsection{The Readtable} % 22.1.5.
\edithead {\csdag 3 (p360)}
\editstart
\\ \bf replace &
\cltxt
Even if an implementation supports characters with non-zero
{\em bits} and {\em font}
attributes, it need not (but may) allow for such characters to
have syntax
descriptions
in the readtable. However, every character of type
{\clkwd string-char}
must be represented in the readtable.
\\ \bf with &
\cltxt
All base and extended characters
are representable in the readtable.
\editend
\setcounter{subsubsection}{5}
\subsubsection{What the Print Function Produces} % 22.1.6.
\edithead {\csdag 13 (p366)}
\editstart
\\ \bf replace &
\cltxt
is used. For example, the printed representation of the character
\#$\backslash$A
with control
and meta bits on would be \#$\backslash${\clkwd CONTROL-META-A},
and that of
\#$\backslash$a with control and meta bits on would be
\#$\backslash${\clkwd CONTROL-META-$\backslash$a}.
\\ \bf with &
\cltxt
is used (see 22.1.4).
\editend
\setcounter{subsection}{2}
\subsection{Output Functions} % 22.3.
\setcounter{subsubsection}{0}
\subsubsection{Output to Character Streams} % 22.3.1.
\edithead {\csdag 26 (p384)}
\editstart
\\ \bf replace &
\cltxt
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
\\ \bf with &
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
Only characters which are members of the coded character set(s)
associated with the output stream or \#$\backslash${\clkwd Newline}
are valid to be written;
it is an error otherwise. All character streams must provide
appropriate line division behavior for
\#$\backslash${\clkwd Newline}.
\editend
\\
\edithead {\csdag 27 after (p384)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd external-coded-string-length} {\em object} \&{\clkwd optional}
{\em output-stream} [{\em Function}]
\\ &
{\clkwd external-coded-string-length}
returns the number of implementation defined
units required for the object on the output-stream. If
not applicable to the output stream, the function
returns {\clkwd nil}.
This number corresponds to the current state of the stream
and may change if there has been intervening output.
If the output stream is not specified {\clkwd *standard-output*}
is the default.
\editend
\setcounter{subsubsection}{2}
\subsubsection{Formatted Output to Character Streams} % 22.3.3.
\edithead {\csdag 23 delete example (p387)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (format nil "Type} $\tilde{ }$
{\clkwd :C to $\tilde{ }$ :A."} . . .
\editend
\\
\edithead {\csdag 66 (p389)}
\editstart
\\ \bf replace &
\cltxt
$\tilde{ }${\clkwd :C} spells out the names of the control bits and
represents non-printing
characters by their names: {\clkwd Control-Meta-F, Control-Return,
Space}.
This is a "pretty" format for printing characters.
\\ \bf with &
\cltxt
$\tilde{ }${\clkwd :C}
represents non-printing
characters by their names: {\clkwd Newline,
Space}. This is a "pretty" format
for printing characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\setcounter{section}{22}
\section{File System Interface} % 23
\setcounter{subsection}{1}
\subsection{Opening and Closing Files} % 23.2.
\edithead {\csdag 2 (p418)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\\ \bf with &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd
:external-coded-character-format}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\editend
\\
\edithead {\csdag 11 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd string-char}
\\ &
The unit of transaction is a string-character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream.
\\ \bf with &
\cltxt
The default value of {\clkwd :element-type} is
implementation-defined as character or a subtype of character.
\\ &
{\clkwd base-character}
\\ &
The unit of transaction is a base character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream.
\editend
\\
\edithead {\csdag 16 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character, not just a string-character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\\ \bf with &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\editend
\\
\edithead {\csdag 19 after (p420)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd :external-coded-character-format}
\\ &
This argument specifies a name or list of
names(s) indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
\\ &
The default value is {\clkwd :default} and is
implementation defined but must include the
base characters.
\\ &
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\\ &
References to standard ISO coded character set names must
include the full ISO reference number and approval year.
The following are valid ISO reference names:
:ISO8859/1-1987, :ISO6937/2-1983, :ISO646-1983, etc..
All implementation recognized schemes are formed from
{\clkwd standard-p} characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂22-Feb-89 1630 X3J13-mailer cs proposal part 3 of 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Feb 89 16:30:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 543952; Wed 22-Feb-89 19:27:07 EST
Date: Wed, 22 Feb 89 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal part 3 of 3
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890222.100851.baggins@almvma>
Message-ID: <19890223002701.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The last time you mailed this out it was only with great difficulty
and a lot of help from my friends that I was able to read it. The
version of LaTex available to me blows out when your document is
run through it. If you (or anyone else on this list) has a DVI
file already in a publicly (FTP) accessible place, I'd appreciate
knowing about it. Probably other recipients are in the same boat,
so mail the file name to X3J13.
∂22-Feb-89 1707 X3J13-mailer Re: cs proposal part 3 of 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:07:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA01715; Wed, 22 Feb 89 18:04:48 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09867; Wed, 22 Feb 89 18:04:43 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902230104.AA09867@defun.utah.edu>
Date: Wed, 22 Feb 89 18:04:42 MST
Subject: Re: cs proposal part 3 of 3
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Thom Linden <baggins@IBM.com>,
Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 22 Feb 89 19:27 EST
There is a copy of the DVI file on cs.utah.edu (128.110.4.21). The
file is pub/cl-cs-proposal.dvi.
-Sandra
-------
∂22-Feb-89 1714 X3J13-mailer cs proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:13:58 PST
Date: Wed, 22 Feb 89 12:41:41 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.124141.baggins@almvma>
Subject: cs proposal
I'm also mailing everyone (in Mathis mailing labels) a hardcopy
which is dated 22 Feb and contains the errata change to page 25.
Regards,
Thom
∂22-Feb-89 1713 X3J13-mailer cs proposal straw vote
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:12:50 PST
Date: Wed, 22 Feb 89 12:08:15 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.120815.baggins@almvma>
Subject: cs proposal straw vote
I would like to take a straw vote on various components of
the Characters proposal. The primary intent is to resolve the
actual list of items to be voted upon at the March meeting.
Let me know if you think some items should be separated or
combined. The vote may also indicate which items are controversial
or need revision before the March meeting.
As it is a straw vote, anyone can respond. Please comment on
your vote as well. In particular, if you are voting against
some item I would like to know what change(s), if any,
incorporated into the proposal might reverse your vote.
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
Proposal:
Eliminate of font and bit attributes.
Add rules for an implementation supporting attributes.
Redefine STRING-CHAR as implementation defined.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
Issue: CHARACTER-TYPE-RESTRICTIVEC
Problem: CHARACTER type doesn't allow thin & fat characters.
Proposal: a
Define BASE-CHARACTER as a subtype of STRING. a
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
Issue: STRING-TYPE-RESTRICTIVE
Problem: STRING type doesn't allow thin & fat strings.
Proposal: a
Define STRING as a union type a
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
All string functions operate as specified on any a
string object except it is an error to insert
an extended character into a base string.
Extend the COERCE function to allow coercion from a
base string to extended string.
Issue: STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal: ne
Add BASE-STRING
Add GENERAL-STRING
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Problem: SIMPLE STRING type doesn't allow thin & fat strings.
Proposal: a
Define SIMPLE-STRING as a union type a
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal: ne
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
Issue: FILE-EXTERNAL-REPRESENTATION
Problem: can't specify external encoding even when there are lots
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Issue: STRING-BINARY-WIDTH
Problem: Can't find out how many bytes a string will take when written as
text
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
Issue: CHAR-CODE-NON-PORTABLE
Problem: no way to talk about well-known external coding methods, only
internal codes
Proposal:
Add CHAR-CCS-VALUE function
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Problem: Can't portably talk about non-standard characters
Proposal:
Introduce the concept of Registries
Standardize on #\registry:id, add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
New syntax for CHARACTER type specifier
New #\label:registry character name syntax
New argument to CHARACTERP
∂22-Feb-89 1713 X3J13-mailer cs proposal errata
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:13:33 PST
Date: Wed, 22 Feb 89 12:22:03 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.122203.baggins@almvma>
Subject: cs proposal errata
Page 25, the insertion "23 after (p49):
(GENERAL-STRING size)
Means the same as (ARRAY CHARACTER (size)): the set of base
strings of the indicated size.
(SIMPLE-GENERAL-STRING size)
Means the same as (SIMPLE-ARRAY GENERAL-CHARACTER (size)): the
set of simple general strings of the indicated size.
Should read:
(GENERAL-STRING size)
Means the same as (ARRAY CHARACTER (size)): the set of general
strings of the indicated size.
(SIMPLE-GENERAL-STRING size)
Means the same as (SIMPLE-ARRAY CHARACTER (size)): the set of
simple general strings of the indicated size.
∂24-Feb-89 1437 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:37:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14585; Fri, 24 Feb 89 14:35:46 PST
Message-Id: <8902242235.AA14585@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14585; Fri, 24 Feb 89 14:35:46 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:35
To: x3j13@sail.stanford.edu
Subject: Issue: EXTRA-RETURN-VALUES
Issue: EXTRA-RETURN-VALUES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
Unless it is explicitly allowed in the standard,
if a standard function
returns a different number of return values from the number
specified by the standard, the results are unspecified.
Rationale:
The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."
Current Practice:
Adoption Cost:
Implementations and their associated documentation that now contain
functions that return extra values will have to change.
Benefits:
Programs will potentially become more portable.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂24-Feb-89 1426 X3J13-mailer Issue: EXTENTIONS-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:26:07 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13754; Fri, 24 Feb 89 14:24:16 PST
Message-Id: <8902242224.AA13754@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA13754; Fri, 24 Feb 89 14:24:16 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTENTIONS-POSITION
Issue: EXTENSIONS-POSITION
References: Chapter 1, Working draft of standard
Category: Clarification
Related Issues: CONFORMANCE-POSITION, IF-BODY, ERROR-TERMINOLOGY, EXTRA-SYNTAX,
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS, UNSPECIFIED-
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
2-FEB-89, Version 5 by Chapman
24-FEB-89, Version 6 by Chapman (added RPG's comment)
Problem Description:
What is the definition of a language extension?
What effect does a language extension have on a conforming program?
What obligation does an implementation have to warn the user that an
extension is being used?
Presumably the only thing that defining it as an extension can mean from
CL's point of view is `initially defining' it as an extension. Whether
an implementation permits redefinition of an extension is between that
implementation and its users and beyond the scope of Common Lisp. For
example, it is common practice to redefine some kinds of system functions
in Genera -- to extend the system in interesting ways, to fix bugs, etc.
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.
If the standard says that "the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
In places where the standard says that "an implementation may be extended",
this implies that a conforming, but probably non-portable, program can
be written using the implementation's extension.
Proposal (EXTENSIONS-POSITION:DISABLE)
Same as EXTENSIONS-POSITION:DOCUMENTATION except that
an implementation is required to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability.
Rationale:
The standard should contain information about language extensions
since most implementations have extended the language.
Current Practice:
CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL. In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
Adoption Cost:
Vendors will have to improve their documentation
to list all their extensions. Vendors will have to go through their
implementation and determine what is or isn't an extension.
Benefits:
This definition will provide a basis for proper understanding of
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Masinter says:
It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.
RPG says:
I favor remaining mute on this topic in the standard.
∂24-Feb-89 1439 X3J13-mailer Issue: MACRO-AS-FUNCTION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:38:14 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14651; Fri, 24 Feb 89 14:36:25 PST
Message-Id: <8902242236.AA14651@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14651; Fri, 24 Feb 89 14:36:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:36
To: x3j13@sail.stanford.edu
Subject: Issue: MACRO-AS-FUNCTION
Issue: MACRO-AS-FUNCTION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
6-FEB-89, Version 2 by Chapman
Problem:
May operators defined in the standard as "macros" and
"special forms" be implemented as functions instead? PROG1 is the main
example, but there might be others.
Proposal: MACRO-AS-FUNCTION:YES
Operators that are defined in CL as "macros" may be defined as functions
instead if the semantics can be preserved.
This is rare, perhaps only
restricted to
(defun prog1 (value &rest ignore) value)
(defun prog2 (value1 value2 &rest ignore) value2)
Operators defined as "special forms" may also be defined as functions.
Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO
The standard will remain silent on the issue of whether or not is
is legal for an implementation to implemention "macros" and
"special forms" as functions.
Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW
A conforming implementation does not define "macros" and "special forms"
as functions.
Rationale:
There isn't a good reason to disallow "macro" and "special form" function
definitions. It doesn't interfere with portability.
Current Practice:
One implementation defines PROG1 as a function.
Adoption Cost:
None for :YES; some for :DISALLOW.
Benefits:
Increased implementation flexibility.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂24-Feb-89 1439 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:39:14 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14750; Fri, 24 Feb 89 14:37:23 PST
Message-Id: <8902242237.AA14750@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14750; Fri, 24 Feb 89 14:37:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:37
To: x3j13@sail.stanford.edu
Subject: Issue: UNSOLICITED-MESSAGES
Issue: UNSOLICITED-MESSAGES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
6-FEB-89, Version 2 by Chapman
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?
Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*STANDARD-OUTPUT*, *ERROR-OUTPUT*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *TERMINAL-IO* since a user may not redirect
*TERMINAL-IO*.)
Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.
Rationale:
This proposal has very little impact on implementations, but helps the
user by explicitly stating the disposition of unsolicited messages.
Current Practice:
Adoption Cost:
Small. Implementations and their documentation may have to change slightly.
Benefits:
Portability.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂24-Feb-89 1439 X3J13-mailer Issue: UNSPECIFIED-DATATYPES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:38:57 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14708; Fri, 24 Feb 89 14:37:07 PST
Message-Id: <8902242237.AA14708@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14708; Fri, 24 Feb 89 14:37:07 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:36
To: x3j13@sail.stanford.edu
Subject: Issue: UNSPECIFIED-DATATYPES
Issue: UNPSECIFIED-DATATYPES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
6-FEB-89, Version 2 by Chapman
Problem: Is it OK to define the behavior of functions on datatypes not
explicitly permitted in the standard?
Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED
A conforming implementation does not define the behavior of functions
on data types not explicitly permitted in the standard.
Example: A conforming implementation is not allowed to define + as
operating on vectors.
Rationale:
While the original intent of CL designers was that
implementations be permitted to do these things, they get in the way of
portability when they're done, since it is nearly impossible to detect when
a program has used one of these features. It is simple to define a new
function
acme-common-lisp:+ which has the behavior of the "portable" + plus all the
new whizzy features, too.
Current Practice:
Adoption Cost:
Implementors would have to determine which functions had been allowed
to operate on data types not explicitly allowed in CLtL and rewrite those
functions. The implementation's documentation would have to change.
Benefits:
Portability.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
"The suggestion that implementations can shadow standard functions to
provide these features has been made before, and I'll repeat my standard
objection. The behavior of a standard function is also apparent when
calling a portable function that is defined to use that function. A
good example is FORMAT: a portable subroutine library would be quite
likely to define functions that take FORMAT-style argument lists
(Pitman's portable condition system defines several). If an
implementation extends FORMAT, these extensions should be reflected in
the behavior of these functions. But if the extensions are hidden in
ACME:FORMAT and the library calls LISP:FORMAT, this won't happen, and
there's no way to make it happen without modifying the library's source."
∂27-Feb-89 0217 X3J13-mailer Issue: EXTRA-SYNTAX
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 02:17:05 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14142; Mon, 27 Feb 89 02:15:12 PST
Message-Id: <8902271015.AA14142@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14142; Mon, 27 Feb 89 02:15:12 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 27 Feb 89 05:15
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-SYNTAX
Issue: EXTRA-SYNTAX
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: ERROR-TERMINOLOGY, EXTENSIONS-POSITION
Edit history: 8-JAN-89, Version 1 by Masinter
13-JAN-89, Version 2 by Chapman
3-FEB-89, Version 3 by Chapman
27-FEB-89, Version 4 by Chapman
Problem: is it OK to extend Common Lisp macros and special forms to take
additional syntax not specified?
Proposal: EXTRA-SYNTAX:NO
It isn't allowed.
Rationale:
It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.
Current Practice:
Adoption Cost:
Benefits:
Conversion Cost:
Aesthetics:
None.
Discussion:
∂27-Feb-89 0218 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 02:18:42 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14193; Mon, 27 Feb 89 02:16:50 PST
Message-Id: <8902271016.AA14193@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14193; Mon, 27 Feb 89 02:16:50 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 27 Feb 89 05:16
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
27-FEB-89, Version 3 by Chapman
Problem:
Is it OK to define Common Lisp functions with extra optional or named arguments
with system-dependent meanings?
Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED
Unless explicitly allowed in the standard,
implementations are not allowed to include such definitions.
When extra optional or named arguments are allowed in the
standard, they will be annotated as follows:
functions that may be
extended to take implementation-specific optional arguments are indicated
by an &REST IGNORE in their argument list; functions that may be extended
to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS.
Rationale:
The goal is not to outlaw any extensions currently offered by
implementors, but to make the range of extensions to functions defined in
the standard well documented in the standard. Implementations that want to
extend functions that aren't explicitly allowed to be extended can instead
shadow them.
Alternate proposal: NOT-IN-STANDARD-PACKAGE
Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
provide additional named arguments to a function if the names are not in
an implementation-specific package (the list of these currently includes
the LISP, USER, and KEYWORD packages).
Current Practice:
Most implementations extend function syntax with extra
optional and named arguments.
Adoption Cost:
Implementors will be required to determine which parts of their implementations
are conforming and which parts aren't.
Implementors will have to provide a candidate list of exceptions to the
editorial committee.
Benefits:
It will be more possible to write portable programs. Also, future standards
will be less likely to make changes that are incompatible with current
implementations.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂27-Feb-89 0255 X3J13-mailer Review schedule reminder
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 02:54:55 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15941; Mon, 27 Feb 89 02:52:59 PST
Message-Id: <8902271052.AA15941@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15941; Mon, 27 Feb 89 02:52:59 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 27 Feb 89 05:31
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Review schedule reminder
I would like to come to closure on several issues and sections of the
standard at the March meeting (i.e. take a vote on them). The complete
list is in issue CUT-OFF-DATES that I hope you have received either by
hardcopy mail or electronically. Below is a summary of what will be voted
on in March, and the dates I'm hoping to get comments from you. Please
see CUT-OFF-DATES for more details, or let me know if you didn't get that
issue.
Topic Suggested date for returning comments
______________________________________________________________________________
Conformance issues 3/1
CONFORMANCE-POSITION
EXTENSIONS-POSITION
SUBSETTING-POSITION
EXTRA-SYNTAX
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
MACRO-AS-FUNCTION
UNSOLICITED-MESSAGES
UNSPECIFIED-DATATYPES
Sections 1.1-1.5 3/1
Section 1.7 3/1
Sections 5.2-5.4 3/8
Section 1.6 3/15
Section 2.1 3/15
Section 5.1 (*) 3/15
Section 2.2 (**) 3/22
(*) This section is not complete as of now. Please do not review until
I let you know if will be worth your time.
(**) This section has undergone recent organizational changes. Please
do not review until after 3/1.
Please note that the dates above are only suggestions. Please feel free
to comment up to 3/21.
The sections of the standard are all available from hudson.dec.com
(ftp_user merrychristmas). Please see the file "how-to-build-standard.lis"
for information about file names.
I will also be sending you the sources from these sections electronically,
and will create a file named "march-27-ballot.tex" (and .dvi) that will contain
all these sections (except 5.1) and will be available after 3/1.
Please let me know if you have any trouble accessing or reviewing this
information. Note that after these sections have been voted in, we can
still change them with clean-up proposals.
kathy chapman
∂27-Feb-89 1101 X3J13-mailer characters and conformance
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 27 Feb 89 11:00:39 PST
Date: Mon, 27 Feb 89 10:48:34 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890227.104834.baggins@almvma>
Subject: characters and conformance
>> See issues CONFORMANCE-POSITION and ERROR-TERMINOLOGY.
>> kc
Is a program written in non-STANDARD-CHAR-P characters conforming?
The conformance-position and error-terminology issues don't seem to
provide an answer. Clearly it is the case that portability of such
a program is restricted to implementations which support the
specific characters used (eg. the CLtL semi-standard chars, Kanji,
Hangul). Should all such programs be considered non-conforming?
Perhaps the terms "conforming" and "strictly conforming" (mentioned
in use by ANS C) could be used which also deal with programs written
using extra optional keyword arguments.
Conforming rules:
--basic rules as stated in CONFORMANCE-POSITION issue
Strictly Conforming rules:
--Conforming rules (above)
--Strictly conforming code is written using only
STANDARD-CHAR-P characters.
--Strictly conforming code is written using no extra
optional keyword arguments.
Perhaps Strictly Conforming is where one lumps together all the
requirements to define maximally portable code.
∂28-Feb-89 0956 X3J13-mailer agenda items, registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Feb 89 09:56:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01016g; Tue, 28 Feb 89 09:50:16 PST
Received: by challenger id AA15462g; Tue, 28 Feb 89 09:45:48 PST
Date: Tue, 28 Feb 89 09:45:48 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8902281745.AA15462@challenger>
To: x3j13@sail.stanford.edu
Subject: agenda items, registration
Let me know if you have anything to add to the March agenda, how much time
you'll need and what day you'd prefer. I'll be away the week before the X3J13
meeting so please let me know by March 15.
If you have anything to be voted on, please mail documents by March 6 to avoid
the two week rule.
Please let me know of any changes to the registration list below.
X3J13 Attendee Information
02/28/89
Name Institute Paid L1 L2 L3
David Bartley TI -0- y y y
Paul Beiser HP -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Kathy Chapman DEC -0- - - -
Jeff Dalton University of Ediburgh -0- y y y
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI -0- y y y
George Hadden Honeywell S&RC -0- y y y
Masayuki Ida Aoyama Gakuin University -0- y y y
Gregor Kiczales Xerox Corp. -0- y y y
Aaron Larson Honeywell S&RC -0- y y y
Kevin Layer Franz, Inc. 50.00 y y y
Thom Linden IBM 50.00 y y y
David Loeffler MCC -0- y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines -0- y y y
Bob Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Cris Perdue Sun Microsystems -0- y y y
Dan Pierson Encore Computer -0- y y y
Kent Pitman Symbolics -0- y y y
Guy Steele Thinking Machines -0- y y y
Walter van Roggen DEC -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂28-Feb-89 1347 X3J13-mailer cs proposal
Received: from IBM.COM ([192.5.58.7]) by SAIL.Stanford.EDU with TCP; 28 Feb 89 13:46:58 PST
Date: Tue, 28 Feb 89 12:46:45 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890228.124645.baggins@almvma>
Subject: cs proposal
I'll be away from the office next week (6-9 March) and won't
be able to respond to any comments on the proposal before
13 March. I've received one straw vote response todate.
∂01-Mar-89 1109 X3J13-mailer Section 1.7
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:09:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00298; Wed, 1 Mar 89 11:07:25 PST
Message-Id: <8903011907.AA00298@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA00298; Wed, 1 Mar 89 11:07:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.7
%%Language Extensions
[{\it This section is dependent upon the passage or failure of the following
issues: EXTENSIONS-POSITION, EXTRA-SYNTAX, EXTRA-OPTIONAL-KEYWORD-ARGUMENTS,
UNSPECIFIED-DATATYPTES, UNSOLICITED-MESSAGES, MACRO-AS-FUNCTION, and
EXTRA-RETURN-VALUES. When they have passed or failed, this section
will be altered.}]
A language extension is
any implementation-supplied {\word tool} that isn't explicitly defined
in this standard. This includes facilities added to {\word tools} defined
in this standard.
An implementation may have extensions,
provided they do not alter the behavior of conforming code and
provided they are not explicitly prohibited by this standard.
From Common Lisp's point of view, defining an extension
refers to a facility's initial definition.
Whether an implementation permits redefinition of an extension is between that
implementation and its users and beyond the scope of this standard to
specify.
If this standard says that ``the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
In places where the standard says that ``an implementation may be extended",
this implies that a conforming, but probably non-portable, program can
be written using the implementation's extension.
%Following will be included if the proposal that states this is passed.
%An implementation is required to have a way to disable its extensions, so
%that a programmer can be told when he is using a feature that might
%affect his program's portability.
The following list contains specific guidance to implentations
concerning certain types of extensions.
\beginlist
\itemitem{\bf Additional syntax}
An implementation
is not allowed to extend {\word macros} and {\word special forms} to take
additional syntax not specified in this standard.
\itemitem{\bf Extra optional or named arguments}
Unless explicitly allowed in this standard,
implementations are not allowed to include definitions
of {\word functions} with extra optional or named arguments
with system-dependent meanings.
When extra optional or named arguments are allowed by this
standard, they will be annotated as follows:
{\word functions} that may be
extended to take implementation-specific optional arguments are indicated
by {\tt &rest ignore} in their argument list.
{\word Functions} that may be extended
to take additional keyword parameters are indicated by {\tt &allow-other-keys}.
The goal is not to outlaw any extensions currently offered by
implementors, but to make the range of extensions to {\word functions}
defined in
this standard well documented in this standard. Implementations that want to
extend {\word functions} that aren't explicitly
allowed to be extended can instead
shadow them.
% or as follows, if this proposal passes.
%Alternate proposal: NOT-IN-STANDARD-PACKAGE
%
%Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
%provide additional named arguments to a function if the names are not in
%an implementation-specific package (the list of these currently includes
%the LISP, USER, and KEYWORD packages).
%
\itemitem{\bf Extra return values}
Unless it is explicitly allowed in this standard,
an implementation is
not allowed to return extra values from {\word functions}
defined by this standard.
\itemitem{\bf Function behavior on non-standard data types}
An implementation does not define the behavior of {\word functions}
on data types not explicitly permitted by this standard.
\itemitem{\bf Unsolicited messages}
Unsolicited messages, such as garbage collector notifications
and autoload heralds, if
they are produced by an implementation, should not be directed to
@var[standard-output] or @var[error-output]\rm.
If an implementation produces them, they
may be produced on a {\datatype stream}
that is not shared with any of the {\datatype streams}
that a user might redefine or redirect. This means that an
implementation is allowed to
direct such notifications to @var[terminal-io] since a user may not redirect
@var[terminal-io]\rm.
Messages such as progress reports from {\function load} and
{\function compile} are solicited,
and are not covered here.
\itemitem{\bf Implementation of macros and special forms}
Operators that are defined as {\word macros} or
{\word special forms} may be defined as {\word
functions}
instead if the semantics can be preserved.
%or as follows:
%Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO
%
%The standard will remain silent on the issue of whether or not is
%is legal for an implementation to implemention "macros" and
%"special forms" as functions.
%or as follows:
%Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW
%
%A conforming implementation does not define "macros" and "special forms"
%as functions.
\endlist
∂01-Mar-89 1111 X3J13-mailer Section 5.2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:10:51 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00392; Wed, 1 Mar 89 11:08:46 PST
Message-Id: <8903011908.AA00392@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA00392; Wed, 1 Mar 89 11:08:46 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:25
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.2
%% Input/Output
It is possible to perform I/O to any device physically connected to
the machine on which the @xlisp\ system is running.
Some implementations, however, may not support the interfaces
to all possible physical devices. Some external
data sources
are treated specially in @clisp. The following sections describe the file
system interface, binary and character I/O, and the {\function load}ing process.
\beginsubSection{Files}
%% 23.0.0 5
@clisp\ assumes that files are named, that given a name a
{\datatype stream} can be constructed that
connects to a file of that name, and that the
names can be fit into a {\datatype pathname}.
%% 23.0.0 6
%Facilities are provided for manipulating {\datatype pathnames},
%for creating
%{\datatype streams}
%connected to files, and for manipulating the file system
%through {\datatype pathnames} and {\datatype streams}.
%Left out.
%% 23.1.0 1
In general, different
file systems have different naming formats for files.
There are two ways to represent file names:
namestrings, which are {\datatype strings}
in the implementation-dependent form
customary for the file system, and {\datatype pathnames}, which are
{\word objects} that represent file names in an implementation-independent
way. {\word Functions}
are provided to convert between these two representations,
and all manipulations of files can be expressed in machine-independent
terms by using {\datatype pathnames}. See ``Pathname''.
%% 23.1.0 2
%In order to allow code to operate in a network environment
%that may have more than one kind of file system, the pathname facility
%allows a file name to specify which file system (called the
%host) is to be used.
%Left out.
%%% 23.1.1 11
%Parsing is the conversion of a namestring
%into a {\datatype pathname}. This operation is
%implementation-dependent, because the format of namestrings
%is implementation-dependent.
%
%Merging takes a {\datatype pathname} with missing components
%and supplies values for those components from a source of defaults.
%This operation is also implementation-dependent because the
%set of valid {\datatype pathnames} that may result from merging is
%implementation-dependent.
%% 23.2.0 1
The basic operations for opening a file are {\function open} and
{\function with-open-file}. The basic operation for closing a file
is {\function close}.
Rules concerning file I/O follow:
\beginlist
%% 22.2.1 2
\itemitem{\bf Eof-error-p}
{\arg Eof-error-p} in I/O {\word forms}
controls what happens if input is from a file (or any other
input source that has a definite end) and the end of the file is reached.
If {\arg eof-error-p} is true (the default), an error will be signalled
at end of file. If it is false, then no error is signalled, and instead
the {\word form} returns {\arg eof-value}.
%% 22.2.1 4
\itemitem{\bf Recursive-p}
If {\arg recursive-p} is
supplied and not @nil\rm, it specifies that
this {\word form}
call is not a {\word top level} call to {\function read} but an embedded call,
typically from the {\word function} for a macro character.
It is important to distinguish such recursive calls for three reasons.
%% 22.2.1 5
\beginlist
\itemitem{1.}
A {\word top level} call establishes the context within which the
{\tt \#n=} and {\tt \#n\#} syntax is scoped. Consider, for example,
the expression
@lisp
(cons '#3=(p q r) '(x y . #3#))
@endlisp
If the single quote macro character were defined in this way:
@lisp
(set-macro-character #@bsl\ '
#'(lambda (stream char)
(declare (ignore char))
(list 'quote (read stream))))
@endlisp
then the expression could not be read properly, because there would be no way
to know when {\function read} is called recursively by the first
occurrence of @f['] that the label @f[\#3=] would be referred to
later in the containing expression.
There would be no way to know because {\function read}
could not determine that it was called by a macro character function
rather than from {\word top level}. The correct way to define the single quote
macro character uses {\arg recursive-p}:
@lisp
(set-macro-character #@bsl\ '
#'(lambda (stream char)
(declare (ignore char))
(list 'quote (read stream t nil t))))
@endlisp
%% 22.2.1 6
\itemitem{2.}
A recursive call does not alter whether the reading process
is to preserve whitespace or not (as determined by whether the
{\word top level} call was to {\function read} or {\function
read-preserving-whitespace}).
Suppose again that single-quote had the first, incorrect, macro character
definition shown above. Then a call to {\function read-preserving-whitespace}
that read the expression @f['foo ] would fail to preserve the space
character following the symbol @f[foo] because the single-quote
macro character function calls {\function read},
not {\function read-preserving-whitespace},
to read the following expression (in this case @f[foo]\rm).
The correct definition, which passes the value @true\ for {\arg recursive-p}
to {\function read}, allows the {\word top level} call to determine
whether whitespace is preserved.
%% 22.2.1 8
\itemitem{3.}
When end-of-file is encountered and the {\arg eof-error-p} argument
is not @nil\rm, the kind of error that is signalled may depend on the value
of {\arg recursive-p}. If {\arg recursive-p}
is not @nil\rm, then the end-of-file
is deemed to have occurred within the middle of a printed representation;
if {\arg recursive-p} is @nil\rm, then the end-of-file may be deemed to have
occurred between {\word objects} rather than within the middle of one.
\endlist
\endlist
\endsubSection%{Files}
\beginsubSection{Character and Binary Input/Output}
Figure {\chapno--\the\capno} lists reader and printer control variables.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[read-base] & @var[read-suppress] & @var[print-escape] \cr
@var[print-pretty] & @var[print-circle] & @var[print-base] \cr
@var[print-radix] & @var[print-case] & @var[print-gensym] \cr
@var[print-level] & @var[print-length] & @var[print-array] \cr
@var[read-default-float-format] & & \cr
\noalign{\vskip -9pt} }}
\caption{Reader and printer control variables}
\endfig
Figure {\chapno--\the\capno} lists character and binary input
stream {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt read }&{\tt read-preserving-whitespace }&{\tt read-delimited-list }\cr
{\tt read-line }&{\tt read-char }&{\tt unread-char }\cr
{\tt peek-char }&{\tt listen }&{\tt read-char-no-hang }\cr
{\tt clear-input }&{\tt read-from-string }&{\tt parse-integer }\cr
{\tt read-byte }&{\tt }&{\tt }\cr
\noalign{\vskip -9pt} }}
\caption{Character and binary input tools}
\endfig
Figure {\chapno--\the\capno} lists character and binary output
stream {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt write }&{\tt prin1 }&{\tt print }\cr
{\tt pprint }&{\tt princ }&{\tt write-to-string }\cr
{\tt prin1-to-string }&{\tt princ-to-string }&{\tt write-char }\cr
{\tt write-string }&{\tt write-line }&{\tt terpri }\cr
{\tt fresh-line }&{\tt finish-output }&{\tt force-output }\cr
{\tt clear-output }&{\tt write-byte }&{\tt format }\cr
\noalign{\vskip -9pt} }}
\caption{Character and binary output tools}
\endfig
{\function y-or-n-p} and
{\function yes-or-no-p} are used to query the user.
%% 2.2.2 6
When the character {\tt \#{\char '134}Newline} is written to an output file,
the implementation must take the appropriate action
to produce a line division. This might involve writing out a
record or translating {\tt \#{\char '134}Newline} to a CR/LF sequence.
\endsubSection%{Character and Binary Input/Output}
\beginsubSection{Loading}
%% 23.4.0 1
To {\function load} a file is to treat its contents as code and execute
that code. The file may contain character data or binary data. If it is
charater data, {\function load}ing
is accomplished essentially by sequentially reading
the {\word forms} in the file, evaluating each immediately after it is read.
%% 23.4.0 2
{\function Load}ing a compiled
(``fasload'') file is similar, except that the file does not
contain text but rather pre-digested expressions created by the
compiler that can be {\function load}ed more quickly.
See ``Compilation''.
\endsubSection%{Loading}
∂01-Mar-89 1136 X3J13-mailer Section 1.5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:36:49 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02677; Wed, 1 Mar 89 11:34:49 PST
Message-Id: <8903011934.AA02677@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02677; Wed, 1 Mar 89 11:34:49 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.5
%%Compliance
[{\it If the issue, CONFORMANCE-POSITION, undergoes radical modification
before passage, this section will change. Therefore, passage of this
section and CONFORMANCE-POSITION go hand in hand.}]
A conformity clause is a statement that is not part of
the language definition, but specifies requirements for compliance with the
language standard.
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
A conforming implementation is an implementation
that processes
code that is written
in the language defined by the language standard, and
that obeys all the conformity clauses for
implementations written in the language standard.
Requirements for a conforming implementation:
\beginlist
\itemitem{1.} A conforming implementation is one that correctly
translates and executes conforming code.
\itemitem{2.} A conforming implementation
is one that rejects all
code that contains errors whose detection is required by this standard.
\itemitem{3.} A conforming implementation is one that contains no
variation except where the language standard permits, and specifies all
such permitted variations in the manner prescribed by this standard.
See ``Language Extensions''.
\itemitem{4.} A conforming implementation includes the following
in its accompanying documentation:
\beginlist
\itemitem{a.} A list of all definitions or values for the
implementation-defined features in the standard language.
See ``Implementation-defined Features''.
\itemitem{b.} A list of all the features of this implementation
which are not part of the standard language but which could unexpectedly
interact with user code, including all package names
and nicknames the implementation
uses.
\itemitem{c.} A statement of conformity, giving the complete reference to
this standard.
\endlist
\itemitem{5.} A conforming implementation shall meet the technical
specification in its accompanying documentation when related to the
requirements of this standard.
\itemitem{6.} A conforming implementation shall treat an
error as is outlined in ``Errors''.
\endlist
The basic test for conformance will be that code written to the letter
of the standard will run in all conforming implementations.
The basic rules are as follows:
\beginlist
\itemitem{1.}
Conforming code uses only the syntax specified in the standard.
\itemitem{2.}
Conforming code is written in only the sequence specified in the standard.
\itemitem{3.}
Conforming code is written using only the {\word functions}, {\word macros},
{\word special forms}, variables, and constants specified in this standard.
Use of language extensions to the syntax specified
in the standard, or dependence upon the existence of those extensions,
is not allowed in conforming code.
\itemitem{3.}
The definitions of all other {\word functions}, {\word macros}, or
{\datatype symbols}
that are used by the code must accompany
the code.
\itemitem{4.}
Conformance will not be machine-checkable.
\endlist
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
It is possible for conforming code to
run in all conforming implementations, but to have allowable
implementation-dependent behavior that could make it non-portable.
∂01-Mar-89 1159 X3J13-mailer New versions of standard files available
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:59:21 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05099; Wed, 1 Mar 89 11:57:05 PST
Message-Id: <8903011957.AA05099@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05099; Wed, 1 Mar 89 11:57:05 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:02
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: New versions of standard files available
New versions of the standard files that will be voted on in March are available
on hudson.dec.com. There will probably still be changes to section 5.1 (Errors),
so plan to copy and review that last. All these files are contained in
march-27-ballot.dvi, if you can use that file type. If you want to build this
yourself, use march-27-ballot.tex as well as the other files necessary for
any build (kcamfont.tex, kcmacros.tex, macros2.tex, march-27-ballot.tc).
S1100.SCOPE-PURPOSE-AND-HISTORY
S1200.ORGANIZATION-OF-THE-DOCUMENT
S1300.REFERENCED-PUBLICATIONS
S1400.DEFINITIONS
S1500.COMPLIANCE
S1600.IMPLEMENTATION-DEFINED-FEATURES
S1700.LANGUAGE-EXTENSIONS
S2100.INTRODUCTION
S2200.TYPES
S5100.ERRORS
S5200.INPUT-OUTPUT
S5300.INTERFACE-WITH-PROGRAMMING-ENVIRONMENT
S5400.GENERALIZED-REFERENCE
Please let me know if you have trouble accessing these files.
I will be mailing the sources to you for review.
kathy chapman
∂01-Mar-89 1203 X3J13-mailer Section 1.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:03:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05782; Wed, 1 Mar 89 12:01:39 PST
Message-Id: <8903012001.AA05782@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05782; Wed, 1 Mar 89 12:01:39 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:22
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.3
%%Referenced Publications
\beginlist
\item{} {\it The Anatomy of Lisp}, John Allen, McGraw-Hill, 1978.
\item{} {\it Compile-time Evaluation and Code Generation for Semantics-directed
Compilers}, Andrew W. Appel, Carnegie-Mellon University, 1985.
\item{} {\it The Definition of Programming Languages}, Andrew D. McGettrick,
Cambridge University Press, 1980.
\item{} {\it Desiderata for the Standardisation of Lisp}, Julian Padget et.
al., 1986 ACM Conference on Lisp and Functional Programming, 1986.
\item{} {\it Formal Specification of Programming Languages - A Panoramic
Primer}, Frank G. Pagan, Prentice-Hall, Inc, 1981.
\item{} {\it $Revised↑3$ Report on the Algorithmic Language Scheme},
Jonathan Rees and William Clinger (editors), SIGPLAN Notices V21, \#12,
December, 1986.
%\item{} {\it Denotational Semantics}, David A. Schmidt, Allyn and Bacon,
%1986.
\item{} {\it Common LISP the Language}, Guy L. Steele, Jr., Digital Press,
1984.
%\item{} {\it Denotational Semantics: The Scott-Strachey Approach to Programming
%Language Theory}, Joseph E. Stoy, MIT, 1977.
\item{} {\it A Programmer's Guide to Common Lisp}, Deborah G. Tatar,
Digital Press, 1987.
\item{} {\it History of
Programming Languages}, edited by Richard Wexelblat, Academic Press,
1981.
\item{} {\it NIL -- A Perspective}, JonL White, MacSyma User's Conference,
1979.
\item{} {\it Common LISPcraft}, Robert Wilensky, W. W. Norton, 1986.
\endlist
∂01-Mar-89 1138 X3J13-mailer Section 1.6
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:38:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02703; Wed, 1 Mar 89 11:35:58 PST
Message-Id: <8903011935.AA02703@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02703; Wed, 1 Mar 89 11:35:58 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.6
%%Implementation-defined Features
The following sections contain lists of implementation-dependent
language characteristics.
For more
information about each of these implementation dependencies, see
Chapters 6 and 7 for the description of the {\word tool} being qualified.
\beginsubSection{Values}
%%\item{2.}
\beginlist
\item{1.}
An implementation determines the initial values of the {\word tools}
in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt boole-clr}&{\tt boole-set}\cr
{\tt boole-1 }& {\tt boole-2}\cr
{\tt boole-c1}&{\tt boole-c2}\cr
{\tt boole-and}&{\tt boole-xor }\cr
{\tt boole-eqv}&{\tt boole-nand}\cr
{\tt boole-nor }&{\tt boole-orc1}\cr
{\tt boole-orc2}& \cr
& \cr
{\tt array-dimension-limit }&{\tt array-rank-limit }\cr
{\tt array-total-size-limit }&{\tt call-arguments-limit }\cr
{\tt multiple-values-limit}&{\tt lambda-parameters-limit }\cr
{\tt char-bits-limit }&{\tt char-code-limit }\cr
& \cr
@var[features] & {\tt internal-time-units-per-second} \cr
& \cr
{\tt most-positive-fixnum }&{\tt most-negative-fixnum } \cr
{\tt most-positive-short-float }&{\tt least-positive-short-float }\cr
{\tt most-positive-double-float }&{\tt least-positive-double-float }\cr
{\tt most-positive-long-float }&{\tt least-positive-long-float }\cr
{\tt most-positive-single-float }&{\tt least-positive-single-float }\cr
{\tt most-negative-short-float }&{\tt least-negative-short-float }\cr
{\tt most-negative-single-float }&{\tt least-negative-single-float }\cr
{\tt most-negative-double-float }&{\tt least-negative-double-float }\cr
{\tt most-negative-long-float }&{\tt least-negative-long-float }\cr
{\tt short-float-negative-epsilon }&{\tt single-float-negative-epsilon }\cr
{\tt double-float-negative-epsilon }&{\tt long-float-negative-epsilon }\cr
& \cr
@var[load-verbose] & @var[print-array] \cr
@var[print-pretty] &@var[random-state] \cr
@var[read-default-float-format] & \cr
\noalign{\vskip -9pt}
}}
\caption{Implementation-defined values}
\endfig
%%\item{42.}
\item{2.} The implementation determines the defaults for the
@Kwd[rehash-size] and
@Kwd[rehash-threshold]
arguments for
{\function make-hash-table}.
%%\item{44.}
\item{3.} The implementation determines the way in which a
{\datatype sequence} is initialized if an @Kwd[initial-element]
argument is not supplied. See {\function make-sequence}.
The implementation determines the way in which a
{\datatype string} is initialized if an @Kwd[initial-element]
argument is not supplied. See {\function make-string}.
Also, the implementation determines the way in which an
{\datatype array\/} is initialized if @Kwd[initial-element]\rm,
@Kwd[initial-contents]\rm, or @kwd[displaced-to]
arguments are not supplied. See {\function make-array\/}.
%%\item{58.}
\item{4.} Valid values for the argument to
{\function char-bit} and {\function set-char-bit}
are implementation-dependent.
\endlist
\endsubSection%{Values}
\beginsubSection{Results}
\beginlist
\item{1.}
%%12.5.2 7
An implementation may return the result of the
absolute value of a {\datatype complex}
number composed of {\datatype integer}
real and imaginary parts as either a {\datatype floating}-point
number or an {\datatype integer}. See {\function abs}.
%%\item{7.}
\item{2.}
An implementation determines the result returned from
{\function lisp-implementation-type},
{\function type-of},
{\function
lisp-implementation-version}, and {\function software-version}.
%%\item{18.}
\item{3.} An implementation determines the result of {\function digit-char}
when more than one character object can encode the supplied weight in
the given radix.
%%\item{20.}
\item{4.} An implementation may determine the consequences in
{\function do} and
{\function do{\tt $*$}} when the index variable is changed within the iteration
loop.
%%\item{30.}
\item{5.} The result of {\function
file-position} for a character file is implementation-dependent.
%%\item{34.}
\item{6.} An implementation determines the order of elements in the results
of {\function intersection},
{\function set-difference}, and {\function
union} and derivatives of those functions.
Some element-processing aspects of sorting are implementation-dependent.
See {\function sort}.
%%\item{36.}
\item{7.} Whether or not {\function length}
or any sequence operation returns when given a circular
{\datatype list} is implementation-dependent.
%%\item{39.}
\item{8.} The implementation determines the {\word type} of
the result of {\function log} ({\datatype integer} or {\datatype
floating-point})
when its arguments are both {\datatype integers} and the result is a whole
number.
%%\item{41.}
\item{9.} The implementation determines the result of {\function make-char}.
%%\item{46.}
\item{10.} An implementation determines the result of
{\tt (eq (symbol-name (make-symbol x)) x)}.
%%\item{47.}
\item{11.}
An implementation determines the {\word type}
of the result of {\function
max} and {\function min} in the following cases.
\beginlist
\itemitem{a.}
If the arguments are a mixture of {\datatype rationals} and
{\datatype floating-point}
numbers and the largest argument
is a {\datatype rational}.
\itemitem{b.} If the largest argument is a {\datatype floating-point}
number of a smaller format
than the largest format of any {\datatype floating}-point argument.
\endlist
In addition, if one or more of the arguments are equal, then any one
of them may be chosen as the value to return.
%%\item{62.}
%\item{12.} {\function special-form-p} can return a non-@nil\ value,
%the identity of which is implementation-dependent.
%%\item{63.}
\item{12.} If the argument to {\function sqrt} is an {\datatype integer},
the result may be either an {\datatype integer}
or a {\datatype float}ing-point number depending on the
implementation. Also, if the argument to {\function sqrt} is a negative
{\datatype integer},
the result
may be either a
{\datatype complex} number with {\datatype integer} components or
a {\datatype complex} number with {\datatype floating}-point components.
%%\item{64.}
\item{13.} If no characters in the argument to {\function string-trim},
{\function string-left-trim}, {\function string-right-trim},
{\function string-upcase}, {\function string-downcase}, and
{\function string-capitalize} need to be changed, then the implementation can
either return the argument itself or a copy of it.
This is true for all destructive
{\datatype sequence} functions.
%%\item{71.}
\item{14.} When the arguments to
a mathematical {\word function} are
all {\datatype rational} and the true mathematical result
is also (mathematically) rational, then unless otherwise noted
an implementation is free to return either an accurate result of
{\word type} {\datatype rational}
or a {\datatype single-float} approximation.
If the arguments are all {\datatype rational}
but the result cannot be expressed
as a {\datatype rational} number, then a {\datatype single-float}
approximation is always returned.
\endlist
\endsubSection%{Results}
\beginsubSection{Data Representation and Typing}
\beginlist
%%\item{5.}
\item{1.}
An implementation determines the representation of a byte specifier.
%%\item{9.}
\item{2.}
An implementation determines the {\word type} of the {\word object} returned
from {\function coerce} when the result is specified to be a specialized
type.
%%\item{11.}
\item{3.}
An implementation can define declaration specifiers other than the ones
given in the description of {\function declare}.
%%\item{27.}
\item{4.} An implementation determines the format of the environment
argument to {\function evalhook} and
the argument that comes to {\function defmacro} via \&environment; the
{\function defmacro} and
{\function evalhook} environment arguments are not necessarily in the same
format.
%%\item{75.}
\item{5.} The existence of
{\word types} that are not {\word subtypes} of {\datatype common}
is implementation-dependent.
\endlist
\endsubSection%{Data Representation and Typing}
\beginsubSection{Program and Control Structure}
\beginlist
%%\item{13.}
%\item{1.}
%An implementation
%may or may not check for any dynamic {\word bindings}
%of the first argument to {\function defconstant} at the time
%{\function defconstant} is executed.
%%\item{14.}
\item{1.}
An implementation determines the way that {\function defmacro}
actually installs a macro function.
%%\item{15.}
\item{2.}
An implementation determines the code generated by {\function defsetf}.
%%\item{16.}
\item{3.}
The following are implementation-dependent features of {\function defstruct}:
\beginlist
\itemitem{a.} The initial contents of a slot, when they have not been provided,
are specified by the implementation.
\itemitem{b.} The access functions may be declared {\function inline}.
\itemitem{c.} The incorrect use of access functions may or may not be checked
by an implementation.
\itemitem{d.} For included slots, an implementation may or may not check
{\word type} assignments.
\itemitem{e.} If the {\keyword :type} option is not supplied, the implementation
determines the representation of the {\datatype structure}.
%%(see clean-up issue)
\endlist
%%\item{35.}
\item{4.} The permissibility of non-standard {\word lambda-list}
keywords is implementation-dependent.
%%\item{40.}
\item{5.}
An implementation is free
to implement as a {\word special form} any {\word construct}
described in this standard as a {\word macro},
if an equivalent {\word macro} definition is also provided.
See {\function macro-function}.
%%\item{60.}
\item{6.}
The exact expansion for any particular form given to {\function setf}
may be implementation-dependent.
%%\item{76.}
\item{7.} The internal representation of
a backquoted {\word form} is implementation-dependent.
\endlist
\endsubSection%{Program and Control Structure}
\beginsubSection{Comparisons}
\beginlist
%%\item{6.}
\item{1.}
An implementation determines the way font information is compared in the
functions {\function char-equal, char-not-equal, char-lessp, char-greaterp,
char-not-greaterp}, and {\function char-not-lessp}. Where not
specified by this standard, the ordering of
characters is implementation-dependent.
\endlist
\endsubSection%{Comparisons}
\beginsubSection{Numerical Calculations}
\beginlist
%%\item{8.}
\item{1.} {\function minusp},
{\function eql},
{\function float-sign}, and
{\function zerop}
are affected by the presence
of {\tt $-0.0$} in an implementation.
%%\item{24.}
\item{2.} Whether or not two {\datatype numbers} or {\datatype characters}
are {\function eq}
depends on the implementation.
%%\item{26.}
\item{3.} Whether two {\datatype floating}-point
numbers of different {\word types} are {\function eql} depends
on the implementation because it is possible for an implementation to
have less than four floating-point data types.
%%%\item{29.}
%\item{4.} An implementation may use different algorithms
%for the cases of a {\datatype rational} second
%argument and a {\datatype floating}-point
%second argument to {\function expt}.
%%\item{55.}
\item{4.} Random number generation is implementation-dependent.
%%\item{70.}
\item{5.} For the {\word operators} in Figure {\chapno--\the\capno},
an implementation may process the arguments in any manner consistent
with associative (and possibly commutative) rearrangement.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt + }&{\tt * }&{\tt max }\cr
{\tt min }&{\tt =}&{\tt /=}\cr
{\tt < }&{\tt >}&{\tt <=}\cr
{\tt >= }&{\tt gcd}&{\tt lcm}\cr
{\tt logior}&{\tt logxor}&{\tt logand}\cr
{\tt logeqv}&{\tt lognand}&{\tt lognor}\cr
{\tt logandc1}&{\tt logandc2}&{\tt logorc1}\cr
{\tt logorc2}&{\tt boole}&\cr
\noalign{\vskip -9pt}
}}
\caption{Mathematically associative operators}
\endfig
Implementations may differ in
which automatic coercions are applied because of differing
orders of argument processing.
%%\item{72.}
\item{6.}
The precise definitions of {\datatype short-float},
{\datatype long-float}, {\datatype single-float}, and
{\datatype double-float} are implementation-dependent.
\endlist
\endsubSection%{Numerical Calculations}
\beginsubSection{User Interface}
\beginlist
%%\item{.}
\item{1.}
An implementation determines the user interface for the read-eval-print loop
in the {\word
operators} and variables in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt break }&{\tt check-type }&{\tt describe }\cr
{\tt disassemble }&{\tt inspect }&{\tt step }\cr
{\tt warn }&{\tt y-or-n-p }&{\tt yes-or-no-p }\cr
{\tt error }&{\tt cerror }&{\tt ccase }\cr
{\tt ccase }&{\tt ctypecase }&{\tt Anything that uses cerror }\cr
\noalign{\vskip -9pt}
}}
\caption{User interface operators and variables}
\endfig
\endlist
\endsubSection%{User Interface}
\beginsubSection{Input/Output}
\beginlist
%%\item{17.}
\item{1.} An implementation determines whether an attempt by {\function
delete-file} to delete a non-existent file is considered to be successful.
%%\item{19.}
\item{2.} An implementation may define keywords to be used with
{\function directory}.
%%\item{31.}
\item{3.} An implementation determines the precise actions of
{\function finish-output}, {\function clear-output}, and {\function
force-output}.
%%\item{31a.}
\item{4.} {\datatype Streams}
may be implemented in an asynchronous or buffered manner.
%%\item{32.}
\item{5.} {\function format} has the following implementation-defined
features:
\beginlist
%% CLean-up item on this
\itemitem{a.} {\tt @tilde C} prints a character in an implementation-dependent
abbreviated format.
\itemitem{b.} The precise output for {\tt @tilde :{\char '100}C} depends
on the implementation.
\itemitem{c.} When rounding up and rounding down would produce printed values
equidistant from the scaled value of the argument, then the implementation
is free to use either one.
\itemitem{d.} For the {\tt @tilde \$} operation, if the magnitude of the argument is so large or small
that more than 100 digits would have to
be printed, then an implementation is free, at its discretion, to print
the number using exponential notation.
\itemitem{e.} For the {\tt @tilde \$} operation, if
the argument is a {\datatype rational} number,
then it is coerced to be a {\datatype single-float}
or processed by any other method that has essentially the
same behavior.
Only a finite number of digits may be printed.
\endlist
%%\item{37.}
\item{6.} The means by which a text (character file)
is distinguished from an object (binary) file is
implementation-dependent.
%%\item{38.}
\item{7.} The selection by {\function load} of a file type when there
is a choice is implementation-dependent.
%%\item{43.}
\item{8.} The implementation determines the internal representation
of a {\datatype pathname}. See {\function make-pathname}.
%%\item{48.}
\item{9.} The following aspects of {\function open}
are implementation-dependent:
\beginlist
\itemitem{a.} {\keyword :supersede}
\itemitem{b.} An implementation is required to recognize all of
the following {\keyword if-exists} keywords
and to do something reasonable in the context of the host operating
system:
{\keyword :error},
{\keyword :new-version},
{\keyword :rename},
{\keyword :rename-and-delete},
{\keyword :overwrite},
{\keyword :append},
{\keyword :supersede}, or
@false\rm.
\itemitem{c.} If it is impossible for an implementation to handle some option
in a manner close to what is specified in this manual, an error may be
signalled.
\endlist
%%\item{50.}
\item{10.} {\function parse-namestring}
may or may not signal an error if
the representation of a {\datatype pathname}
is surrounded on either side by
whitespace characters, depending on the implementation.
Whether or not {\function parse-namestring} supplies
the
standard default device as the device component
of the resulting {\datatype pathname} depends on the implementation.
%%\item{51.}
\item{11.} The {\datatype pathname} namestring
syntax is implementation-dependent.
The printed representation of a pathname
typically designates {\keyword :wild} by an asterisk; however, this is
implementation-dependent.
%%\item{52.}
\item{12.} A {\datatype character} name or a {\datatype pathname}
that is typed out
is acceptable as input in only the implementation which typed it.
Which names for characters are chosen to print is
implementation-dependent, although standard names are
chosen over non-standard names. See {\function write}.
%%\item{53.}
\item{13.} The printed representation of a
{\datatype random-state} object is implementation-dependent.
%%\item{54.}
\item{14.} {\word Objects} which do not have a specific syntax
specified in this manual are printed in an implementation-dependent manner.
%%\item{68.}
\item{15.} The {\arg host}
argument to {\function user-homedir-pathname}
defaults in an implementation-dependent manner.
%%\item{77.}
\item{16.} Whether the following
character names are supported is implementation-dependent:
@f[rubout]\rm, @f[page]\rm,
@f[tab]\rm,
@f[backspace]\rm,
@f[return]\rm, and
@f[linefeed]\rm.
%%\item{78.}
\item{17.} Whether
characters with non-zero {\arg bits} and {\arg font} attributes
syntax
descriptions are in the {\datatype readtable} is implementation-dependent.
\endlist
\endsubSection%{Input/Output}
\beginsubSection{Compiling}
\beginlist
%%\item{10.}
\item{1.}
An implementation determines the following for {\function compile-file}:
\beginlist
\itemitem{a.} The contents of the file created by {\function compile-file}.
\itemitem{b.} The file
specification (if one is not supplied)
for the file created by {\function compile-file}.
\endlist
%%\item{12.}
\item{2.}
An implementation's compiler can ignore declaration
specifiers except for {\tt declaration}, {\tt special}, and
{\tt notinline}.
%%\item{25.}
\item{3.} An implementation may ``collapse'' constants or portions of constants
in code to be compiled if they appear to be {\function eq}
or {\function eql} and are {\function equal}.
See ``Compilation''.
%%\item{79.}
\item{4.} The representation of the {\word object} produced by
the compiler, and the internals of the compiler
are implementation-dependent, except that {\function compile} produces
a {\datatype compiled-function}.
\endlist
\endsubSection%{Compiling}
\beginsubSection{Miscellaneous}
\beginlist
%%\item{4.}
\item{1.}
An implementation determines the specifics of the
debugger that {\function break} enters.
%%\item{74.}
\item{2.} Although functions that manipulate {\datatype packages}
generally signal
name conflict errors before making any change to the package structure, an
implementation may {\function export}
each of a given list of {\datatype symbols} separately.
%%\item{49.}
\item{3.} The contents of the @f[system] package are determined by
the implementation.
%%\item{57.}
\item{4.} The frequency of execution of test and key
functions for all sequence functions is implementation-dependent.
The implementation of
{\function search} may choose to search the {\datatype sequence} in any order.
%%\item{65.}
\item{5.} The manner in which a
hash code is computed by {\function sxhash}
is implementation-dependent.
%% clean-up pending for this
%%\item{69.}
\item{6.} The optional argument {\arg extension}
for {\function
vector-push-extend}
defaults to a ``reasonable'' implementation-dependent
value.
%%\item{73.}
\item{7.} A {\datatype symbol's} property list may have defined components.
\endlist
\endsubSection%{Miscellaneous}
\beginsubSection{Programming Environment}
\beginlist
%%\item{22.}
\item{1.} An implementation may or may not provide a resident editor.
See {\function ed}.
%%\item{23.}
\item{2.} An implementation determines the means by which
function text is obtained when {\tt (ed {\it symbol})} is invoked.
%%\item{33.}
\item{3.} An implementation determines the units used in representing
Internal Time.
See {\function get-internal-run-time}.
%%\item{56.}
\item{4.} The information {\function room} prints is
implementation-dependent.
%%\item{66.}
\item{5.} The nature and
format of the information printed by {\function time}
is implementation-dependent.
%%\item{67.}
\item{6.} The following are implementation dependencies of
tracing.
\beginlist
\itemitem{a.} {\function trace} and {\function untrace} may accept
implementation-dependent argument formats.
\itemitem{b.} The format of the {\function trace}
output is implementation-dependent.
\endlist
\endlist
\endsubSection%{Programming Environment}
∂01-Mar-89 1207 X3J13-mailer Section 2.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:06:27 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06314; Wed, 1 Mar 89 12:04:26 PST
Message-Id: <8903012004.AA06314@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06314; Wed, 1 Mar 89 12:04:26 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:24
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.1
%% Introduction to Objects and Types
%% 2.0.0 4
%% 6.2.1 1
A {\word data type} (a {\word type})
is a (possibly infinite) set of
{\word objects}. An {\word object} can belong to more than one
{\word type}. @Funref[typep] is used to determine
whether an {\word object} is of a given {\word type},
a set membership test, while {\function subtypep}
is a subset test.
@Funref[type-of] returns a {\word type}
to which an {\word object} belongs.
%% 9.1.0 1
Type declarations can be embedded in executable
code using {\function declare}.
Global type declarations are established by {\function proclaim}.
%% 9.3.0 1
%The special form {\function the} is used to declare
%the {\word type} of the value of an
%unnamed {\word form}.
%The form {\tt (the type form)} means
%that the value of {\tt form}
%is declared to be of type {\tt type}.
%% 1.1.0 4
%% 9.0.0 3
%All type declarations are optional
%and correct type declarations do not affect the meaning
%of a correct program.
%All type declarations are of an advisory nature, and may be used
%by the @xlisp\ system in performing error checking
%or producing more efficient compiled code.
%% 9.0.0 4
The consequences are undefined if a program violates a
type declaration (such as a {\function type} declaration),
but an implementation is
not required to detect such errors.
%% 9.2.0 1
%% 2.0.0 1
Data {\word objects}, not variables, are {\word typed}.
Normally, any variable
can have any @xlisp\ {\word object} as its value.
It is possible to make an explicit
type declaration that a variable will
take on one of only a limited set of values.
%% 2.0.0 5
@clisp\ {\word types} are arranged in a directed acyclic graph.
%Therefore,
%it is possible for an {\word object} to belong to more than one
%{\word type}.
%% 2.12.0 1
%%% 19.1.0 1
%{\word Structures} created by @Macref[defstruct]
%are instances of user-defined {\word types}.
%%% Beginning of CLOS stuff
%\beginSection{Introduction}
%
The \CLOS\ is based on
{\word generic functions}, multiple inheritance, declarative {\word method}
combination, and a meta-object protocol.
%
%The first two chapters of this specification present a description of
%the standard Programmer Interface for the \CLOS. The first chapter
%contains a description of the concepts of the \CLOS, and the second
%contains a description of the functions and macros in the \CLOS\
%Programmer Interface. The chapter ``The \CLOS\ Meta-Object
%Protocol'' describes how the \CLOS\ can be customized.
%
The fundamental {\word objects} of the \CLOS\
are {\word classes}, {\word instances},
{\word generic functions}, and {\word methods}.
A {\bit class\/} object determines the structure and behavior of a set
of other {\word objects}, which are called its {\bit instances}.
Every {\word object} is an {\bit
instance\/} of a {\word class}. The
{\word class} of an {\word object} determines the set of
operations that can be performed on the {\word object}.
See ``Generic Functions and Methods''.
%%\endSection%{Introduction}
∂01-Mar-89 1232 X3J13-mailer Section 1.2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:32:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09839; Wed, 1 Mar 89 12:30:26 PST
Message-Id: <8903012030.AA09839@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09839; Wed, 1 Mar 89 12:30:26 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:21
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.2
%%Organization of the Document
This document is divided into seven chapters:
\beginlist
\item{\bull} This introduction.
\item{\bull} A description of @clisp\ types and objects.
\item{\bull} A description of the syntax of @clisp\ objects.
\item{\bull} The @clisp\ evaluation and compilation processes.
\item{\bull} A description of the @clisp\ interfaces to
its environment and a description of the condition
system.
\item{\bull} A catalog of @clisp\ symbols (divided into two chapters).
\endlist
∂01-Mar-89 1232 X3J13-mailer Section 1.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:32:28 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09717; Wed, 1 Mar 89 12:30:00 PST
Message-Id: <8903012030.AA09717@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09717; Wed, 1 Mar 89 12:30:00 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:21
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.1
%%Scope, Purpose, and History
\beginsubSection{Scope and Purpose}
The standard specification set forth in this document
is designed to promote the portability of @clisp\ programs
among a variety of data-processing systems. It is intended for use
by implementors and knowledgeable programmers, and is not a tutorial.
This standard is intended to be a language specification
rather than an implementation specification.
An
implementation is free to achieve the semantics
specified in this standard by any means. The @clisp\ definitions
in Chapters 6 and 7 need not be reflected directly in the implementation.
\endsubSection%{Scope and Purpose}
\beginsubSection{History}
Lisp is the second oldest high-level programming language still in current use.
(The oldest high-level programming language still in widespread use
is Fortran.)
@clisp\ is a joint-venture language stemming from several
research and development projects in the late 1970's. Its
roots reveal why some of the features of the language were
added. From a short look at these roots, it can also be seen
how these features influence the architectural requirements
for a high-quality implementation.
From the mid-1960's through much of the 1970's, DEC's PDP10 computer
was the mainstay of Lisp work at MIT and Stanford's AI and Computer
Science Labs, at BBN in Cambridge, at CMU, and at selected other sites.
Designed in the early
1960's, the PDP10 had the unique advantage of being influenced by
John McCarthy, the ``Grandfather of Lisp'', and as a result has
half-word instructions suitable for {\word car} and {\word cdr}
instructions, and
stack instructions to facilitate recursive programming.
But the limitations of this old machine were painfully
evident by 1973, two of which were
the high cost to support a single researcher,
and the small address space available ($2↑{18}$ = 262,144 words).
To alleviate the latter problem, BBN Lisp (developed at Bolt, Bernak,
\& Newman in Cambridge, and later, with Xerox's
participation, called Interlisp)
added a ``black hole'' feature somewhat akin to ``paging''
on a function basis rather than on a page-boundary basis. MacLisp
(developed at the MIT AI Lab and Laboratory for Computer Science)
added an ``autoload'' feature, whereby only the functions actually used
would be loaded in to ``core''. Large applications such as the
symbolic algebra system MACSYMA and the Interlisp programing development
environment were driving forces for larger address space capabilities.
In the early 1970's, at Xerox's Palo Alto Research Center, L. Peter Deutch
conceived of a personal workstation with an architecture
tailored to the needs of Lisp. This architecture would allow
a machine to be affordable to an
individual researcher and to have sufficient power to run large Lisp
applications.
Soon thereafter, Richard Greenblatt began work
on a similar design at MIT's AI Laboratory.
Eventually, a dialect of Interlisp known as Interlisp-D became available
on
the ``D-series'' machines manufactured by Xerox, and an upward-compatible
extension of MacLisp became available on the early MIT ``Lisp'' machines.
Both of these efforts culminated in commercial Lisp machines that were
seen in laboratory prototype at about the time of the 1980 Lisp Conference
at Stanford, and were marketable by 1981.
In another direction, in the late 1970's the MacSyma group at MIT
began
a project called New Implementation of Lisp (NIL). In additon
to capitalizing on the large address space and other hardware
capabilities of the VAX, one of the stated goals of NIL was to fix many
of the historic, but annoying, little problems of the Lisp
language while still retaining an essentially upward-compatible
outlook. At about the same time, a research group
at Stanford University and Lawrence Livermore National Laboratory
began the design of a Lisp to run on the supercomputer,
S-1. Recognizing the similarity of
their goals to those of the MIT NIL project, the S-1 group
began to collaborate with the NIL group.
In a third direction, around 1980, Scott Fahlman and others at CMU
began work on a Lisp to run on the SPICE workstation.
The SPICE machine had a much weaker microcode capability
than the MIT Lisp Machine, so the goal was to emulate as much of the
MIT design as was feasible.
After a DARPA-sponsored meeting on the future of Lisp in April 1981,
representatives
of several of the post-MacLisp efforts (Gabriel, Steele, White, and Fahlman)
decided to join forces by
directing their efforts towards a common, portable dialect of Lisp.
Further design sessions were held at CMU in June 1981. Later that
fall, Symbolics Corporation representatives began assisting in
designing the new dialect.
After the name was chosen (@clisp) the task then turned to a
choice of how much of the design could be retained from the Lisp
machines, and how much seemed to pre-suppose special purpose hardware. Also
there was a task of sorting out which features of conventional
languages for conventional hardware architectures, like compile-time
typing, could be integrated into the new language without damaging
its essential Lisp character. The theorists of each
camp allowed some deviations from what they considered theoretically
best, and the result
was a language suitable for general purpose hardware, but with certain
particular implementational problems to be met.
@maclisp, @lmlisp, @scheme, @interlisp, @slisp, @s1lisp, @newlisp,
@stdlisp, and @psl\
were each considered during the design of
@clisp\rm, and the most useful features of each were incorporated.
{\it Common LISP the Language},
was written by members of the informal design group.
The semantics in {\it Common LISP the Language} were intentionally
underspecified in
places where it was felt that a tight specification would
unduly constrain @clisp\ research and use.
However, industrial use of @clisp\
mandates implementations to produce the same results given the same arguments
in order that code can be ported between implementations.
In addition, @clisp\ users recognized the need to agree on standard
object-oriented and condition systems, iteration facilities, and
a way to handle large character sets.
Therefore, a new language specification, this document, was created by
the X3J13 committee.
\endsubSection%{History}
∂01-Mar-89 1234 X3J13-mailer Section 1.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:34:33 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09935; Wed, 1 Mar 89 12:32:23 PST
Message-Id: <8903012032.AA09935@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09935; Wed, 1 Mar 89 12:32:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:22
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.4
%%Definitions
This section contains notational conventions used in this manual.
The font key to be used in Chapters 1-5
is as follows:
\beginlist
\itemitem{\datatype data-type}
Denotes
@clisp\ {\word data types}.
\itemitem{\word defined word}
Denotes the words whose
definitions appear in the ``Glossary''.
\itemitem{\function tools}
Denotes {\word tools}.
\itemitem{\keyword keywords}
Denotes {\word keywords}.
\endlist
%% 1.2.1 1
All numbers in this book are in decimal notation
unless otherwise noted.
%% 1.2.5 9
The dot appearing in the expression
@f[(sample-macro @i[var] {\char '056} @i[body])]
means that @f[body] stands
for a list of {\word forms},
not just a single {\word form}, at the end of a list.
The following notations are used in this document:
\beginlist
\itemitem{\word @EV\rm}
Indicates {\word evaluation}.
For example:
@Lisp
(+ 4 5) @EV 9
@Endlisp
means that the result of {\word evaluating} the code @f[(+ 4 5)] is @f[9]\rm.
%% 1.2.3 3
\itemitem{\word @EQ}
Indicates code
equivalence.
For example:
@Lisp
(gcd x (gcd y z)) @EQ (gcd (gcd x y) z)
@Endlisp
means that the results and observable
{\word side-effects} of {\word evaluating }
the {\word form}
@f[(gcd x (gcd y z))] are always the same as the results
and observable {\word side-effects} of
@f[(gcd (gcd x y) z)] for any
@f[x]\rm, @f[y]\rm, and @f[z]\rm.
%% 1.2.5 4
\itemitem{@t}
The canonical truth value.
Any {\word object} other than @false\ is construed to be Boolean
``not false,'' that is, ``true.'' The {\datatype symbol} @true\ is
used to mean ``true'' when no other value is more appropriate.
When a {\word function} is said to ``return @i[true]\rm'' or to ``be @i[true]\rm''
in some circumstance, this means that it returns some value other
than @false\rm, but not necessarily @true\rm.
\itemitem{@nil}
Represents the empty {\datatype list} and
the ``false'' value for Boolean tests.
The {\datatype symbol} @f[nil] evaluates to
itself, so @f['nil] and @f[nil] denote the same {\word object}
in terms of evaluation.
The former syntax is used to emphasize that the result is
a {\datatype symbol},
while the latter is used to emphasize that the result is
a boolean value. @f['()]
is used to denote the
empty {\datatype list}
in terms of evaluation. It is used in a quoted structure
or a program structure.
For example:
\screen!
(print ()) ;avoided
'(nil nil) ;list of symbols
'(()()) ;list of empty lists
(defun three () 3) ;Emphasize empty parameter list.
(append '() '()) @EV () ;Emphasize use of empty lists
(not @false) @EV @true ;Emphasize use as Boolean "false"
(get '@nil 'color) ;Emphasize use as a symbol
\endscreen!
When a function is said to ``return @i[false]\rm'' or to ``be @i[false]\rm''
in some circumstance, this means that it returns @false\rm.
\endlist
∂01-Mar-89 1240 X3J13-mailer Section 5.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:40:11 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA10373; Wed, 1 Mar 89 12:38:09 PST
Message-Id: <8903012038.AA10373@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA10373; Wed, 1 Mar 89 12:38:09 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:26
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.3
%% Interface with the Programming Environment
\beginSubsection{Top level loop}
%% 20.2.0 1
The {\function read}-{\function eval}-{\function print} loop
is the highest level of control and consists of an endless
loop that reads an expression, evaluates it, and prints the
results. The parts of the
{\function read}-{\function eval}-{\function print} loop are individually
referred to as the reader, the evaluator, and the printer.
%% 20.2.0 2
The precise nature of the {\function read}-{\function eval}-{\function print}
loop
is not rigorously specified; thus the user interface is
implementation-defined.
%% 20.2.0 3
The {\function read}-{\function eval}-{\function print} loop
traps all {\function throws} and recovers from them.
It prints all values resulting from the evaluation of a
{\word form}.
%% 20.2.0 4
The following variables are maintained by the
{\function read}-{\function eval}-{\function print} loop.
{\tt +, ++, +++, *, **, ***, /, //, ///, -}.
See Chapter 6 for the meanings of these variables.
\endSubsection%{Top level loop}
\beginSubsection{Environment inquiry}
%% 25.4.0 1
Environment inquiry {\word tools} provide information about the
system on which a @clisp\ program is being executed.
These {\word tools}
aid in querying the hardware and software configuration, and
in debugging.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to configuration inquiry.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt @var[features] } & {\tt long-site-name } & {\tt room } \cr
{\tt identity } & {\tt machine-instance } & {\tt short-site-name } \cr
{\tt lisp-implementation-type } & {\tt machine-type } & {\tt software-type }
\cr
{\tt lisp-implementation-version} & {\tt machine-version } & {\tt
software-version } \cr
\noalign{\vskip -9pt} }}
\caption{Configuration inquiry tools}
\endfig
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to debugging.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt apropos } & {\tt dribble } & {\tt step } \cr
{\tt apropos-list } & {\tt ed } & {\tt trace } \cr
{\tt describe } & {\tt inspect }& {\tt untrace } \cr
{\tt documentation } & & \cr
\noalign{\vskip -9pt} }}
\caption{Debugging tools}
\endfig
\endSubsection%{Environment inquiry}
\beginsubsubsection{Time}
%% 25.4.1 1
Time is represented in three different ways in @clisp\rm:
Decoded Time, Universal Time, and Internal Time.
The first two representations
are used primarily to represent calendar time, and are
precise only to one second.
Internal Time is used primarily to represent measurements of computer
time (such as run time) and is precise to some implementation-dependent
fraction of a second, as specified by @Conref[internal-time-units-per-second]\rm.
Decoded Time format is used only for absolute time indications.
Universal Time and Internal Time formats are used for both absolute
and relative times.
\beginlist
\itemitem{\bf Decoded time}
%% 25.4.1 2
Decoded Time format represents calendar time as a number of components:
%% 25.4.1 3
\beginlist
\itemitem{\bf Second}
An {\datatype integer} between 0 and 59, inclusive.
%% 25.4.1 4
\itemitem{\bf Minute}
An {\datatype integer} between 0 and 59, inclusive.
%% 25.4.1 5
\itemitem{\bf Hour}
An {\datatype integer} between 0 and 23, inclusive.
%% 25.4.1 6
\itemitem{\bf Date}
An {\datatype integer} between 1 and 31, inclusive (the upper limit actually
depends on the month and year, of course).
%% 25.4.1 7
\itemitem{\bf Month}
An {\datatype integer} between 1 and 12, inclusive; 1 means January,
12 means December.
%% 25.4.1 8
\itemitem{\bf Year}
An {\datatype integer} indicating the year A.D. However, if this
{\datatype integer}
is between 0 and 99, the ``obvious'' year is used; more precisely,
that year is assumed that is equal to the
{\datatype integer} modulo 100 and
within fifty years of the current year (inclusive backwards
and exclusive forwards).
Thus, in the year 1978, year 28 is 1928
but year 27 is 2027. (Functions that return time in this format always return
a full year number.)
%% 25.4.1 10
\itemitem{\bf Day-of-week}
An {\datatype integer} between 0 and 6, inclusive;
0 means Monday, 1 means Tuesday, and so on; 6 means Sunday.
%% 25.4.1 11
\itemitem{\bf Daylight-saving-time-p}
A flag that, if not @false\rm, indicates that
daylight saving time is in effect.
%% 25.4.1 12
\itemitem{\bf Time-zone}
%% should be a clean-up item about this
An {\datatype integer} specified as the number of hours west of GMT
(Greenwich Mean Time). For example, in Massachusetts the time zone is 5,
and in California it is 8. Any adjustment for daylight saving time is
separate from this.
\endlist
\itemitem{\bf Universal time}
%% 25.4.1 13
Universal Time represents time as a single non-negative {\datatype integer}.
For relative time
purposes, this is a number of seconds. For absolute time, this is the
number of seconds since midnight, January 1, 1900 GMT. Thus the time 1
is 00:00:01 (that is, 12:00:01 a.m.) on January 1, 1900 GMT.
Similarly, the time 2398291201 corresponds to time 00:00:01 on January 1,
1976 GMT.
Recall that the year 1900 was not a leap year; for the purposes of
@clisp\rm, a year is a leap year if and only if its number is divisible by 4, except
that years divisible by 100 are not leap years, except that years
divisible by 400 are leap years. Therefore the year 2000 will
be a leap year.
(Note that the ``leap seconds'' that
are sporadically inserted by the world's official timekeepers as an additional
correction are ignored; @clisp\ assumes that every day is exactly 86400
seconds long.)
Because the @clisp\ Universal Time representation uses only
non-negative integers, times before the base time of midnight,
January 1, 1900 GMT cannot be processed by @clisp\rm.
\itemitem{\bf Internal time}
%% 25.4.1 14
Internal Time also represents time as a single {\datatype integer},
in terms of an implementation-dependent unit.
Relative time is measured as a number of these units.
Absolute time is relative to an arbitrary time base.
\endlist
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to time.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt time }&{\tt get-decoded-time }\cr
{\tt get-universal-time }& {\tt decode-universal-time }\cr
{\tt encode-universal-time } & {\tt internal-time-units-per-second } \cr
{\tt get-internal-run-time }&{\tt get-internal-real-time }\cr
{\tt sleep } & \cr
\noalign{\vskip -9pt} }}
\caption{Time tools}
\endfig
\endsubsubsection%{Time}
∂01-Mar-89 1243 X3J13-mailer Section 5.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:43:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA10362; Wed, 1 Mar 89 12:41:24 PST
Message-Id: <8903012041.AA10362@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA10362; Wed, 1 Mar 89 12:41:24 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:27
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.4
%% Generalized Reference
When it is stated that an argument to a {\word function} or
{\word macro} must be
a generalized reference, this means that the argument must follow the
rules specified in this section. The definition for generalized reference
is given in terms of {\function setf},
which performs access and update operations within the
same {\word form}.
Figure {\chapno--\the\capno} contains examples of the use of {\function setf}.
Note that the values returned by evaluating the {\word forms} in column two
are not necessarily the same as those obtained by evaluating the {\word
forms}
in column three.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
\hfil\bf Access function & Update function & Update using {\function setf} \cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
{\tt x }&{\tt (setq x datum) }&{\tt (setf x datum) }\cr
{\tt (car x) }&{\tt (rplaca x datum) }&{\tt (setf (car x) datum) }\cr
{\tt (symbol-value x) }&{\tt (set x datum) }&{\tt (setf (symbol-value x) datum) }\cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf}
\endfig
Figure {\chapno--\the\capno} lists the {\word operators}
that are applicable to generalized reference. Some manipulate generalized
references and some manipulate {\function setf} methods.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt setf }&{\tt psetf }&{\tt shiftf }\cr
{\tt rotatf }&{\tt getf }&{\tt remf }\cr
{\tt incf }&{\tt decf }&{\tt push}\cr
{\tt pop }&{\tt assert }&{\tt ctypecase }\cr
{\tt ccase} &{\tt define-modify-macro }&{\tt defsetf }\cr
{\tt define-setf-method }&{\tt get-setf-method }&{\tt get-setf-method-multiple-value }\cr
\noalign{\vskip -9pt}
}}
\caption{Generalized reference operators}
\endfig
%% 7.2.0 29
%% 7.2.0 30
These {\word operators} must guarantee that
subforms of generalized references are
evaluated
exactly as many times as they appear in the source program, and
they are evaluated
in exactly the same order as they appear in the source
program
\issue{PUSH-EVALUATION-ORDER}
(left to right)
whenever possible. The left-to-right rule does not
remove the obligation on writers of {\word macros} and
users of {\function define-setf-method}
to ensure
left-to-right order, however.
\endissue{PUSH-EVALUATION-ORDER}
\issue{PUSH-EVALUATION-ORDER}
\beginlist
\itemitem{1.}
The evaluation ordering of subforms within a generalized reference
is determined by the order specified by the second value returned by
{\function get-setf-method}.
For all predefined generalized references ({\function getf}, {\function ldb}),
this order of evaluation is exactly left-to-right. When a generalized
reference is derived from a macro expansion, this rule is applied after the
macro is expanded to find the appropriate generalized reference.
If the user writes a {\function defmacro} or
{\function define-setf-method}
that does not preserve order, the order specified in the
user's code holds. For example, given
@lisp
(defmacro wrong-order (x y) `(getf ,y ,x))
@endlisp
then
@lisp
(push value (wrong-order place1 place2))
@endlisp
will evaluate {\tt place2} first and then {\tt place1}
because that is the order they
are evaluated in the macro expansion.
\itemitem{2.}
For the {\word macros}
that manipulate generalized references ({\function push},
{\function pushnew}, {\function getf\/}, {\function remf\/},
{\function incf\/}, {\function decf\/}, {\function shiftf\/}, {\function rotatef\/},
{\function psetf\/}, {\function setf\/}, {\function pop}, and those
defined by {\function define-modify-macro}) the subforms of the
macro call are evaluated exactly once
in left-to-right order, with the subforms of the generalized references
evaluated in the order specified in (1).
{\function push}, {\function pushnew}, {\function getf\/}, {\function remf\/},
{\function incf\/}, {\function decf}, {\function shiftf\/}, {\function rotatef\/},
{\function psetf\/}, {\function pop} evaluate all
subforms before modifying any of the generalized reference locations.
{\function setf\/} (in
the case when {\function setf\/} has more than two arguments)
performs its operation
on each pair in sequence, i.e., in
@lisp
(setf place1 value1 place2 value2 ...)
@endlisp
the subforms of {\tt place1} and {\tt value1} are evaluated, the location
specified by
{\tt place1} is modified to contain the value returned by
{\tt value1}, and
then the rest of the {\function setf\/} form is processed in a like manner.
\itemitem{3.}
For {\function check-type}, {\function ctypecase}, and
{\function ccase}, subforms of the generalized
reference are evaluated once as in (1), but may be evaluated again if the
type check fails in the case of {\function check-type}
or none of the cases hold in
{\function ctypecase} and {\function ccase}.
\itemitem{4.}
For {\function assert}, the order of evaluation of the generalized
references is not specified.
\endlist
Rules 2, 3 and 4 cover all macros defined in @clisp\ that manupulate
generalized references.
@lisp
(let ((ref2 (list '())))
(push (progn (princ "1") 'ref-1)
(car (progn (princ "2") ref2)))) @EV "12"
@endlisp
@lisp
(let (x)
(push (setq x (list 'a))
(car (setq x (list 'b))))
x) @EV (((a) . b))
@endlisp
{\function push} first evalutes {\tt (setq x (list 'a)) @EV\ (a)},
then evaluates {\tt (setq x (list 'b)) @EV\ (b)},
then modifies the {\word car} of this latest value to be {\tt ((a) . b)}.
\endissue{PUSH-EVALUATION-ORDER}
%% 7.2.0 31
For example, in
{\tt (setf {\arg reference} {\arg value})}
{\arg value}
must be evaluated after all the subforms of {\arg reference} because
{\arg value} appears to the right of them.
%% 7.2.0 32
The expansion of these {\word operators} must consist of code that follows these
rules or has the same effect as such code. This is accomplished by
introducing temporary variables bound to the
\issue{PUSH-EVALUATION-ORDER}
subforms of the macro call.
\endissue{PUSH-EVALUATION-ORDER}
As an optimization in the implementation,
temporary variables may be eliminated whenever it
can be proven that removing them has no effect on the semantics of the program.
For example, a constant need never be saved in a temporary variable.
A variable or any {\word form} that does not have side effects need not be
saved in a temporary variable if it can be proven that its value will
not change within the scope of the generalized reference.
%% 7.2.0 57
A {\function setf\/} method may be derived from any
generalized reference.
A {\function setf\/} method
describes how to store into that generalized reference and which subforms of
the macro call are evaluated.
%% 7.2.0 59
Given knowledge of the subforms of the macro call,
it is possible to avoid evaluating
them multiple times or in the wrong
order. A {\function setf\/}
method for a given access form can be expressed as
five values:
%% 7.2.0 60
\beginlist
%% 7.2.0 64
\itemitem{\bf List of temporary variables}
The temporary variables
will be bound to the {\word values} of
the value forms sequentially as if by @Specref[let*]\rm.
\itemitem{\bf List of value forms}
The values of the value forms (these are subforms of the access form)
are bound to the temporary variables.
%% 7.2.0 61
%% 7.2.0 65
\itemitem{\bf List of store variables}
The store variables (these are temporary variables)
are to be bound to the values of the generalized reference form,
that is, the values to be
stored into the variable.
%% 7.2.0 62
\itemitem{\bf Storing form}
The storing form modifies the value of the
generalized reference and guarantees to return the value of the
store variable as
its value; these are the correct values for {\function setf\/} to
return.
The storing form may contain references to the temporary and store variables.
%% 7.2.0 63
\itemitem{\bf Accessing form}
The accessing form returns the value of the
generalized reference.
It may contain references to the temporary variables.
\endlist
%% 7.2.0 66
The value returned by the accessing form is
affected by execution of the storing form, but either of these
forms may be evaluated any number of times.
%% 7.2.0 67
The temporary variables and the store variables are generated names,
as if by @Funref[gensym] or @Funref[gentemp]\rm.
It is possible
to do more than one {\function setf\/} in parallel via
{\function psetf\/}, {\function shiftf\/}, and {\function rotatef\/}.
Computation
of the {\function setf\/}
method must always create new variable names; it may not return
the same ones every time.
Examples of the contents of the constituents of {\function setf\/} methods
follow.
%% 7.2.0 69
For a variable {\arg x}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt () }&; list of temporary variables \cr
{\tt () }&; list of value forms \cr
{\tt (g0001) }&; list of store variables \cr
{\tt (setq {\arg x} g0001) }&; storing form \cr
{\arg x }&; accessing form \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 1}
\endfig
%% 7.2.0 70
For {\tt (car {\arg exp})}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt (g0002) }&; list of temporary variables \cr
{\tt ({\arg exp}) }&; list of value forms \cr
{\tt (g0003) }&; list of store variables \cr
{\tt (progn (rplaca g0002 g0003) g0003) }& ; storing form \cr
{\tt (car g0002) }&; accessing form \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 2}
\endfig
%% 7.2.0 71
For {\tt (subseq {\arg seq s e})}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt (g0004 g0005 g0006) }&; list of temporary variables \cr
{\tt ({\arg seq s e}) }& ; list of value forms \cr
{\tt (g0007) }& ; list of store variables \cr
{\tt (progn (replace g0004 g0007 :start1 g0005 :end1 g0006) }& \cr
{\tt g0007) }& ; storing form \cr
{\tt (subseq g0004 g0005 g0006) }&{\tt ; accessing form} \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 3}
\endfig
∂01-Mar-89 1305 X3J13-mailer Section 1.7
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 13:04:43 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 1 Mar 89 16:00:20 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 1 Mar 89 15:58:25 EST
Date: Wed, 1 Mar 89 16:01 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Section 1.7
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903011907.AA00298@decwrl.dec.com>
Message-Id: <19890301210123.2.BARMAR@OCCAM.THINK.COM>
Date: 1 Mar 89 07:23
From: chapman%aitg.DEC@decwrl.dec.com
A language extension is
any implementation-supplied {\word tool} that isn't explicitly defined
in this standard.
I don't like this definition. I suggest:
A language extension is any documented implementation-defined behavior
of a tool defined in this standard that varies from the behavior
described in this standard; or a documented consequence in a situation
that the standard defines as undefined, unspecified, or extendable by
the implementation.
This accomplishes several things:
- It restricts the definition to tools described in the standard.
Implementations are expected to provide their own tools in their own
packages, and I don't think these are considered extensions (this would
require an implementation to litter its documentation with "this is an
extension to Common Lisp" on nearly every page).
- It only talks about "behavior". Because of a cleanup issue voted on
in Hawaii, we already have specified that implementations are not
permitted to add tools with names in the standard-defined packages.
Because I don't think we want to consider tools in other packages as
extensions, the only thing left is the behavior of standard-defined
tools.
- It only refers to "documented" behavior. If the implementation varies
from the standard in an undocumented way it is a bug, not an extension.
And if the situation has an undocumented consequence in an undefined,
unspecified, or extendable situation, it is not an extension, it is just
an accident of the implementation.
barmar
∂01-Mar-89 1257 X3J13-mailer cs proposal and straw vote
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:53:49 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA20108; Wed, 1 Mar 89 15:51:57 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11442; Wed, 1 Mar 89 15:50:01 EST
Message-Id: <8903012050.AA11442@mist.>
To: baggins@ibm.com
Cc: x3j13@sail.stanford.edu
Subject: cs proposal and straw vote
Date: Wed, 01 Mar 89 15:49:59 EST
From: Dan L. Pierson <pierson@mist.encore.com>
General comments first.
I find the layout of the proposal, mainly Appendix A, confusing to the
point of uselessness. As I understand it, chapters 1 and 2 are
intended to be a general overview of the proposal, but the detailed
changes in Appendix A are what we are effectively voting on.
Unfortunately, I can't understand Appendix A without spending a long
time destroying a copy of CLtL per draft. All of the other committees
(and X3J13 as a whole) have accepted that we are writing a new
document, not rewriting Guy's book. Why do you insist on only doing
the later?
Before the Hawaii meeting, I was willing to reluctantly ignore all of
the above and just trust the Character Committee to see that Appendix
A accurately reflected the contents of chapters 1 and 2. The
combination of the revelation of deep disagreements within the
committee, and my own attempts to answer some questions by refering to
Appendix A have forced me to change my mind. I find that I cannot
understand the proposal as presented and thus cannot vote for the
contents of Appendix A. The straw ballot that follows represents my
willingness to vote for the specific issues as described in chapters 1
and 2 of the proposal provided that such a vote does not require
acceptance of the specific wording of Appendix A.
As an example of the above problems. I was unable to find anywhere in
the latest draft either the data types of character labels and
registry names or the predicates to be used to compare them. Your
replies to comments on the January draft state that these are symbols,
which seems correct, but the proposal does not appear to specify this.
Character Registries:
While the idea of character registries doesn't sound bad in principle,
I'm still not convinced that tying the first Common Lisp standard to
the output of an ISO committee which has not been (and may never be)
formed is wise. If nothing else, this approach would appear to
guarantee a period of major incompatibility for the users of any
Common Lisp implementation which provided its own set of character
registries in advance of an ISO standard.
By the way, I find the support of the ISO Prolog committee, which
seems to be being ignored by all major US and many international
Prolog implementors, rather meaningless. If you could get support from
a major, effective ISO language committee or two I might be convinced.
Moon is correct that it is (barely) possible to enumerate all the
characters in a registry without additional functionality. Never the
less, the method he proposes is far from desirable. Since I believe
that adding non-enumerable data types to Common Lisp is a bad thing, I
sould be much happier if a registry iterator were added. The following
would suffice; I'm sure that there are many acceptable alternatives:
(DO-ALL-CHARACTERS (char registry) [Macro]
body)
In particular, I would point out that requiring the available
characters to be documented is sufficient only for some users of
commercial implementations. Students, users of non-commercial
implementations, and an unfortunate number of business users have to
get by with little or no access to printed documentation.
Specific comments:
Page 8: paragraph 2 <The proposed ISO...>
Is this meant to be a proposal from X3J13 to the not-yet-existent ISO
working group? X3J13 certainly can't make a pronouncement about the
contents of a unwritten ISO Character Registry Standard.
Page 8: paragraph 3
In other words, implementations can subset character registries but
not expand them?
Straw Ballot:
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
Proposal:
Eliminate of font and bit attributes.
Add rules for an implementation supporting attributes.
The only reference I can find to implementation defined attributes is
footnote 3 at the bottom of page 6. Either the "rules" mentioned
above should be added to the proposal or this part of the issue should
be dropped.
Redefine STRING-CHAR as implementation defined.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
IF: see above
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
IF: Moon agrees that this is sufficient for hashing (or I'm convinced that
he's wrong :-)).
Issue: CHARACTER-TYPE-RESTRICTIVEC
Problem: CHARACTER type doesn't allow thin & fat characters.
Proposal:
Define BASE-CHARACTER as a subtype of STRING.
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
YES
Issue: STRING-TYPE-RESTRICTIVE
Problem: STRING type doesn't allow thin & fat strings.
Proposal:
Define STRING as a union type
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
What do STRING-LESSP, etc. mean for non-standard-character strings?
Extend the COERCE function to allow coercion from
base string to extended string.
IF: the above is resolved, possibly by explictly saying it's undefined.
Issue: STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal:
Add BASE-STRING
Add GENERAL-STRING
YES
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Problem: SIMPLE STRING type doesn't allow thin & fat strings.
Proposal:
Define SIMPLE-STRING as a union type
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
YES
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal:
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
YES
Issue: FILE-EXTERNAL-REPRESENTATION
Problem: can't specify external encoding even when there are lots
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
YES
Issue: STRING-BINARY-WIDTH
Problem: Can't find out how many bytes a string will take when
written as text
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
YES
I think that reference to "terminal screen templates" has confused
some people without adding to the content.
Issue: CHAR-CODE-NON-PORTABLE
Problem: no way to talk about well-known external coding methods, only
internal codes
Proposal:
Add CHAR-CCS-VALUE function
YES
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Problem: Can't portably talk about non-standard characters
Proposal:
Introduce the concept of Registries
Standardize on #\registry:id, add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
New syntax for CHARACTER type specifier
New #\label:registry character name syntax
New argument to CHARACTERP
NO: Unless the issues raised in the first part of this message are resolved.
∂01-Mar-89 1335 X3J13-mailer Re: Section 1.7
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 13:35:17 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA20628; Wed, 1 Mar 89 16:31:49 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11532; Wed, 1 Mar 89 16:29:55 EST
Message-Id: <8903012129.AA11532@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: "chapman%aitg.DEC@decwrl.dec.com"@Multimax.encore.com,
x3j13@sail.stanford.edu,
"skona%csilvax@hub.ucsb.edu"@multimax.encore.com
Subject: Re: Section 1.7
In-Reply-To: Your message of Wed, 01 Mar 89 16:01:00 -0500.
<19890301210123.2.BARMAR@OCCAM.THINK.COM>
Date: Wed, 01 Mar 89 16:29:54 EST
From: Dan L. Pierson <pierson@mist.encore.com>
- It restricts the definition to tools described in the standard.
Implementations are expected to provide their own tools in their own
packages, and I don't think these are considered extensions (this would
require an implementation to litter its documentation with "this is an
extension to Common Lisp" on nearly every page).
I'm not sure I agree with you here. Lucid certainly documents every
new "tool" as "a Lucid extension to Common Lisp" and this doesn't seem
to unduely clutter their documentation.
∂01-Mar-89 1526 X3J13-mailer minor comments on letter ballot material
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 89 15:26:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 548782; Wed 1-Mar-89 18:22:47 EST
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: minor comments on letter ballot material
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <19890301232245.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here are some minor comments about the material that you mailed out
with your letter ballot. This is not an official response to the
letter ballot.
I like the terms in the error-terminology proposal, however the
meanings of the terms are rather sloppily written. To take one
example, for "the consequences are unspecified", it says that
implementations are permitted to specify the consequences. However,
for "the consequences are undefined", it neither says that
implementations are permitted to specify the consequences, nor
that they are not. I noticed a few other things that might be
inconsistencies or ambiguities in these descriptions. I also
noticed that the reference sections in the letter ballot do not
actually use this error terminology, for the most part. I assume
these deficiencies are just due to the schedule, and will be
corrected before the final draft. I would certainly recommend
putting a lot of time into the exact wording of the definitions
of the error terminology, since that will have high leverage for
the understanding of the rest of the specification. CLtL suffered
greatly because we did not do this. I don't think it's effective
for the committee of the whole to argue over that exact wording,
I think it would be more appropriate for 2 or 3 people on the
editorial committee to write the whole set of descriptions at
one time in a consistent and unambiguous style. (On the subject
of implementations specifying the consequences, I see no advantage
to the standard forbidding implementations to say anything about
what the particular implementation will do in situations that
conforming programs are forbidden to depend upon.)
On page 2-12 of section 2.3, the second to last paragraph came from
something in 88-002R that said that CLtL doesn't specify some class
orderings but CLOS does. Now that CLtL and CLOS are not two separate
standards, this no longer makes sense. You don't need to talk about
classes being layered on top of a preexisting type system defined by
somebody else. Possibly you should delete all but the first sentence of
this paragraph.
The table of built-in classes on page 2-13 is missing a great many
entries. Now that cleanup issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED has
passed, the types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE should be added to this table. I also believe that the
passage of FUNCTION-TYPE means that FUNCTION should be added to this
table, although I'm less confident there. Each one of these classes
has a CPL consisting of just itself and T. Do you need a separate
cleanup issue to be passed to do this?
Page 2-24 says implementations are permitted to make certain
optimizations, but does not say what they are. This paragraph
came from page 1-42 of 88-002R, which did say (or pointed to
where it is said.) Note: I have not done a line by line
comparison of this document with 88-002R and I have no intention
of doing so. This is just a discrepancy that jumped out at me.
Page 2-9 says "Updating an instance does not change its identity as
defined by the EQ function". Page 2-24 does not say "Changing the class
of an instance does not change its identity as defined by the EQ
function". My belief is that it was the intent of the CLOS committee to
say that, although 88-002R fails to say it. Do you need a separate
cleanup issue to be passed to fix this?
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
∂01-Mar-89 1853 X3J13-mailer Re: minor comments on letter ballot material
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 18:53:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 MAR 89 18:46:12 PST
Date: Wed, 1 Mar 89 18:45 PST
From: Gregor.pa@Xerox.COM
Subject: Re: minor comments on letter ballot material
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@SAIL.STANFORD.EDU,
skona%csilvax@hub.ucsb.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890301232245.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890302024559.5.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
This change makes is impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
I agree that the other change you suggested (change-class vs. eq) is in
line with our original intent and we should go ahead and make it. I
hope it doesn't require a vote.
Page 2-9 says "Updating an instance does not change its identity as
defined by the EQ function". Page 2-24 does not say "Changing the class
of an instance does not change its identity as defined by the EQ
function". My belief is that it was the intent of the CLOS committee to
say that, although 88-002R fails to say it. Do you need a separate
cleanup issue to be passed to fix this?
-------
∂01-Mar-89 2340 X3J13-mailer Section 2.2, part 1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 23:38:50 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA07792; Wed, 1 Mar 89 23:36:51 PST
Message-Id: <8903020736.AA07792@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA07792; Wed, 1 Mar 89 23:36:51 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 02:32
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2, part 1
%% Types - part 1
%% Type Hierarchy and Relationships
\beginsubSection{Type Hierarchy and Relationships}
Figure {\chapno--\the\capno}
depicts the @clisp\ type hierarchy and relationships.
An explanation of the
relationships of data types to each other follows.
\beginlist
%% 2.15.0 4
\itemitem{\bull} {\datatype t} is a {\word supertype} of every type whatsoever.
Every {\word object} is of type {\datatype t}.
%% 2.15.0 5
\itemitem{\bull} {\datatype Nil} is a {\word subtype} of every type whatsoever.
No {\word object} is of type {\datatype nil}.
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
The following will be left out of the standard.
%% 2.15.0 6
\itemitem{\bull} {\datatype Cons}, {\datatype symbol},
{\datatype array}, {\datatype number}, and {\datatype character}
are pairwise {\word disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
%% 2.15.0 7
\itemitem{\bull} {\datatype Rational}, {\datatype float}, and {\datatype complex}
are pairwise {\word disjoint}
{\word subtypes} of {\datatype number}.
%% 2.15.0 8
\itemitem{\bull} {\datatype Integer}
and {\datatype ratio} are {\word disjoint subtypes }
of {\datatype rational}.
%% 2.15.0 10
\itemitem{\bull}
{\datatype Fixnum} and {\datatype bignum}
are {\word disjoint} {\word subtypes} of {\datatype integer}.
%% 2.15.0 12
\itemitem{\bull}
{\datatype Short-float}, {\datatype single-float}, {\datatype double-float}, and
{\datatype long-float} are {\word subtypes} of {\datatype float}.
Any two of them must be
either {\word disjoint} or identical;
if identical, then any other types between
them in the above ordering must also be identical to them
(for example, if {\datatype single-float} and {\datatype long-float}
are identical,
then {\datatype double-float} must be identical to them also).
%% 2.15.0 13
\itemitem{\bull} {\datatype Null} is a
{\word subtype} of {\datatype symbol}; the only {\word object} of
type
{\datatype null} is @nil\rm.
%% 2.15.0 14
\itemitem{\bull} {\datatype Cons} and {\datatype null}
form an {\word exhaustive partition} of
{\datatype list}.
%% 2.15.0 15
\itemitem{\bull} {\datatype Standard-char} is a {\word subtype}
of {\datatype string-char};
{\datatype string-char} is a {\word subtype} of {\datatype character}.
%% 2.15.0 16
\itemitem{\bull} {\datatype String} is a
{\word subtype} of {\datatype vector}.
{\datatype String}
is identical to {\tt (vector string-char)}, which in turn
is the same as {\tt (array string-char (*))}.
%% 2.15.0 17
\itemitem{\bull} {\datatype Bit-vector}
is a {\word subtype} of {\datatype vector}, for {\datatype bit-vector}
means {\tt (vector bit)}.
%% 2.15.0 18
\itemitem{\bull} {\tt (vector t)} and
{\datatype string}, and {\datatype bit-vector} are {\word disjoint}.
%% 2.15.0 19
\itemitem{\bull} {\datatype Vector} is a
{\word subtype} of {\datatype array};
for all types @f[x]\rm,
{\tt (vector x)} is the same as
{\tt (array x (*)).}
%% 2.15.0 20
\itemitem{\bull} {\datatype Simple-array} is a {\word subtype}
of {\datatype array}.
%% 2.15.0 21
\itemitem{\bull} {\datatype Simple-vector}, {\datatype simple-string}, and
{\datatype simple-bit-vector} are
{\word disjoint subtypes} of {\datatype simple-array}, for they
respectively mean
{\tt (simple-array t (*))}, {\tt (simple-array string-char (*))},
and {\tt (simple-array bit (*))}.
%% 2.15.0 22
\itemitem{\bull} {\datatype Simple-vector} is a {\word subtype}
of {\datatype vector},
and is
a {\word subtype} of {\tt (vector t)}.
%% 2.15.0 23
\itemitem{\bull} {\datatype Simple-string} is a
{\word subtype} of {\datatype string}.
%% 2.15.0 25
\itemitem{\bull} {\datatype Simple-bit-vector}
is a {\word subtype} of {\datatype bit-vector}.
%% 2.15.0 26
\itemitem{\bull} {\datatype Vector} and {\datatype list}
are {\word disjoint subtypes} of {\datatype sequence}.
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
The following will be left out of the standard.
%% 2.15.0 27
\itemitem{\bull} {\datatype Hash-table}, {\datatype readtable},
{\datatype package}, {\datatype pathname},
{\datatype stream}, and {\datatype random-state} are {\word pairwise disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
\itemitem{\bull} The types {\datatype cons},
{\datatype symbol}, {\datatype array},
{\datatype number}, {\datatype character}, {\datatype hash-table},
\issue{FUNCTION-TYPE:X3J13-MARCH-88}
{\datatype function},
\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
{\datatype readtable},
{\datatype package}, {\datatype pathname}, {\datatype stream},
{\datatype random-state}, and any single other type created
by {\function defstruct} or {\function defclass} are pairwise disjoint.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
%% 2.15.0 28
\itemitem{\bull} Any two types created by @Macref[defstruct] are {\word disjoint} unless
one is a {\word supertype} of the other by virtue of
the {\function defstruct} {\keyword :include} option.
\itemitem{\bull} Any two classes created by {\function defclass} are disjiont
unless one is a superclass of the other.
%% 2.15.0 29
\itemitem{\bull} An {\word exhaustive union} for {\datatype common} is formed by
{\datatype cons}, {\datatype symbol}, {\tt (array x)} where @f[x]
is either {\datatype t} or
a {\word subtype}
of {\datatype common}, {\datatype string}, {\datatype fixnum}, {\datatype
bignum}, {\datatype ratio},
{\datatype short-float}, {\datatype single-float}, {\datatype double-float},
{\datatype long-float},
{\tt (complex x)} where @f[x] is a
{\word subtype} of {\datatype common},
{\datatype standard-char}, {\datatype hash-table}, {\datatype readtable},
{\datatype package}, {\datatype pathname},
{\datatype stream}, {\datatype random-state}, and all types
created by the user
via @Macref[defstruct]\rm.
An implementation may not add {\word subtypes} to
{\datatype common}.
\endlist
%%kc2
\eject
\fig{
\def\IgnoreLineBreaks{\catcode'15=9 \catcode'12=9}
\def\IgnoreWhiteSpace{\catcode'11=9 \catcode'40=9 \IgnoreLineBreaks}
\def\DontIgnoreWhiteSpace{\catcode'12=\active\catcode'15=5\catcode'11=10\catcode'40=10}
\font \pipefont= circle10
\font \foofont = amr10 at 1sp
\IgnoreWhiteSpace
\let \adv=\advance
\def\he{height}
\def\wi{width}
\def\de{depth}
\newdimen \stroke
\stroke= \fontdimen8\pipefont % thickness of line in circles
\newdimen \radius \radius=6pt % radius of circles
\newdimen\irad \irad=\radius\advance\irad by -.5\stroke
\newdimen\orad \orad=\radius\advance\irad by .5\stroke
\newbox\BStrutbox
\setbox\BStrutbox\hbox{\vrule\wi0pt\he10pt\de10pt}
\def\BoxStrut{\unhcopy\BStrutbox}
!% Arrows
\newdimen\ArrowShift
\ArrowShift=\fontdimen22\tensy
\advance\ArrowShift by -0.5\stroke
\def\StrikeOut #1
{ \setbox0\hbox{#1}
\hbox to 1\wd0
{ \vrule \he\stroke\de0pt\wi\wd0
\hskip-\wd0
\unhbox0
}
}
\def\LeftArrow
{ \hskip 0.5\stroke
\StrikeOut{\lower\ArrowShift\hbox to 10pt{\tensy\char'40\hss}}
}
\def\RightArrow
{ \StrikeOut{\lower\ArrowShift\hbox to 10pt{\hss\tensy\char'41}}
\hskip 0.5\stroke
}
\def\ArrowLine
{ \StrikeOut{\hskip 10pt\hskip 0.5\stroke}
}
\def\LeftToRight
{ \let\RightSideArrow=\ArrowLine
\let\LeftSideArrow=\RightArrow
}
\def\RightToLeft
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\LeftArrow
}
\def\NoArrows
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\ArrowLine
}
!% boxes around tokens
\let\NonterminalFont=\tenrm
\newbox\TStrutbox
\setbox0\hbox{\NonterminalFont{Bg}}
\setbox\TStrutbox\hbox{\vrule\wi0pt\he\ht0\de\dp0}
\def\TextStrut{\unhcopy\TStrutbox}
\def\HorzLine{\hrule \he \stroke \de 0pt}
\def\HFil{\leaders\HorzLine\hfil}
\def\HFill{\leaders\HorzLine\hfill}
\def\Nonterminal#1
{\setbox1\vbox to 0pt{
\vss
\hbox{\TextStrut\NonterminalFont\space#1\space\hskip-\stroke}
\vss}
\hbox{
\BoxStrut
\LeftSideArrow
\lower\irad\vbox{
\TopSquare
\copy1
\BotSquare}
\RightSideArrow}
}
\def\TopSquare
{ \hbox{
\vrule\he\stroke\de\irad\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\stroke\de\irad\wi\stroke}
}
\def\BotSquare
{ \hbox{
\vrule\he\orad\de0pt\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\orad\de0pt\wi\stroke}
}
\def\\#1{\Nonterminal{#1}\HFil}
\def\last#1{{\def\RightSideArrow{}\Nonterminal{#1}}}
!% piping
\def\foo{\rlap{\foofont\char'40}}
\def\FulVert{\vrule \wi\stroke\foo\hskip-\stroke}
\def\TopVert{\vrule\de-\irad \wi\stroke\foo\hskip-\stroke}
\def\BotVert{\vrule\he-\orad \wi\stroke\foo\hskip-\stroke}
\def\Center#1,#2.
{\hskip\radius\foo#1\lower.5\stroke\hbox{\pipefont#2}\hskip\radius}
\def\ru{\char'10\hskip -2\radius}
\def\rd{\char'11\hskip -2\radius}
\def\ld{\char'12\hskip -2\radius}
\def\lu{\char'13\hskip -2\radius}
\def\thru{\hskip-\radius\vrule\he\stroke\de0pt\wi2\radius\hskip\radius\hskip-2\radius}
\def\Center#1,#2.
{\foo\hskip\radius#1{\pipefont#2\unskip}\hskip-\radius}
\def\LT{\Center\BotVert,\lu.}
\def\LU{\Center\FulVert,\lu.}
\def\LL{\Center\FulVert,\ld.}
\def\LB{\Center\TopVert,\ld.}
\def\LMid{\Center\TopVert\BotVert,\rd\ru\thru.}
\def\LMU{\Center\TopVert,\rd\thru.}
\def\LML{\Center\BotVert,\ru\thru.}
\def\LFD{\Center\FulVert,\ru\thru.}
\def\LS{\Center\TopVert\BotVert,\rd\ru.}
\def\RT{\Center\BotVert,\ru.}
\def\RU{\Center\FulVert,\ru.}
\def\RL{\Center\FulVert,\rd.}
\def\RB{\Center\TopVert,\rd.}
\def\RMid{\Center\TopVert\BotVert,\ld\lu\thru.}
\def\RMU{\Center\TopVert,\ld\thru.}
\def\RML{\Center\BotVert,\lu\thru.}
\def\Cross{\Center\FulVert,\thru.}
\def\LR{\Center,\thru.}
\def\TB{\Center\FulVert,.}
!% ShiftBox
\newbox\x
\newbox\y
\newbox\tempy
\newbox\z
\newbox\tempz
\def\ShiftBox#1{
\savemod
\saverulebox
\setbox\x
\vbox{ \everycr{\noalign{{\modifyrulebox\global\setbox\z\hbox{}}}}
\halign{&\setbox\x\hbox{##}
\global \setbox\z\hbox{\unhbox\z\vrule\he\ht\x\de\dp\x\wi0pt}
\unhbox\x
\cr
#1}}%
\lower\ht\y\box\x\HFil
\restoremod
\restorerulebox
}
\def\saverulebox{
\setbox\tempy\box\y
\global \setbox\y\vbox{}
\setbox\tempz\box\z
\global \setbox\z\hbox{}
}
\def\restorerulebox{
\global \setbox\y\box\tempy
\global \setbox\z\box\tempz
}
\def\topmod{}
\def\thisrow{\global\let\modifyrulebox\firstmod}
\def\firstmod{
\global\setbox\y\vbox{\hrule\he0pt\wi0pt\de\dp\z}
\global\let\modifyrulebox\latermod
}
\def\latermod{
\global\setbox\y\vbox{\unvbox\y\hrule\he\ht\z\de\dp\z\wi0pt}
}
\def\savemod{
\let\tempmod\modifyrulebox
\global \let\modifyrulebox\topmod
}
\def\restoremod{
\global\let\modifyrulebox\tempmod
}
\DontIgnoreWhiteSpace
!{\baselineskip0pt
\lineskip0pt
\LeftToRight
\IgnoreWhiteSpace
\def\ms{\os
\os\os\os}
\def\os{\omit\span}
\hbox{
\\{nil}
\ShiftBox{
\ms\ShiftBox{
\ShiftBox{
\ShiftBox{
\LT\\{fixnum}&\RT\cr
\LU\\{bignum}&\RMU\thisrow\cr
}\\{integer}&\RML\thisrow\cr
\LU\\{ratio}&\RB\cr
}\\{rational}&\RT\cr
\ShiftBox{
\LU\\{short-float}&\RT\cr
\LU\\{single-float}&\RMid\thisrow\cr
\LU\\{double-float}&\RL\cr
\LU\\{long-float}&\RB\cr
}\\{float}&\RMid\thisrow\cr
\LU\\{complex}&\RB\cr
}\\{number}&\RT\cr
\ms\LU\\{standard-char}\\{string-char}\\{character}&\RU\cr
\LU\\{null}&\os\os\os\LML\\{symbol}&\RU\cr
\LMid\\{cons}&\os\os\RMU\\{list}&\RML\\{sequence}&\RMid\thisrow\cr
\os\LL\\{simple-vector}&\LML\HFil&\RML\\{vector}&\LS&\TB\cr
\os\LL\\{simple-bit-vector}&\LFD\\{bit-vector}&\RL&\TB&\TB\cr
\os\LL\\{simple-string}&\LFD\\{string}&\RB&\TB&\TB\cr
\os\TB&\os\LB\HFil\\{simple-array}&\RMU\\{array}&\RL\cr
\ms\LL\\{function}\\{compiled-function}&\RL\cr
\ms\LL\\{stream}&\RL\cr
\ms\LL\\{hash-table}&\RL\cr
\ms\LL\\{readtable}&\RL\cr
\ms\LL\\{package}&\RL\cr
\ms\LL\\{pathname}&\RL\cr
\ms\LL\\{random-state}&\RL\cr
\ms\LB\\{structures}&\RB\cr
}
\last{t}}}
}\caption{Relationships among the Common Lisp data types}
\endfig
\eject
%%kc1
\endsubSection%{Type Hierarchy and Relationships}
\beginsubSection{Data Type Definition}
Following is a description of each @clisp\ {\word type}.
%% 2.0.0 6
\beginsubsubsection{\datatype t}
The set of all {\word objects} is specified
by @true\rm.
\beginsubsubsection{\datatype Number}
The type {\datatype number\/} is composed of the pairwise {\word disjoint}
{\datatype rational}, {\datatype float}, and {\datatype complex\/} subtypes\/.
An {\word object} of type {\datatype number\/} is called a {\datatype
number\/}.
%% 12.0.0 4
Two {\datatype numbers\/} that are {\function eql} or
{\function =} are not necessarily {\function eq}.
The contagion rules for implicit coercions of arguments in
{\word operations} follow:
\beginlist
\itemitem{\bull}
When a {\word shorter}
{\datatype floating-point} number is combined with a longer one in an
operation,
the result will be of the {\word type} of the longer
of the two {\datatype floating-point} numbers.
\issue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE)}
\itemitem{\bull}
For {\word functions} that combine arguments of different {\word types},
when one argument is a {\datatype rational} and the other is
a {\datatype floating-point} number,
the {\datatype rational} is first
converted to a {\datatype floating-point} number of
the same format.
For {\word functions} that compare arguments of different {\word types},
when one argument is a {\datatype rational} and the other is
a {\datatype floating-point} number, the function
{\function rational} is effectively
called to convert the {\datatype floating-point}
number to a {\datatype rational} and then an exact
comparison is performed. In the case of {\datatype complex\/}
numbers, the real and
imaginary parts are handled individually.
\endissue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE)}
\itemitem{\bull}
When a non-{\datatype complex\/}
number meets a {\datatype complex\/} number, the non-{\datatype complex\/}
number is in effect first converted to a
{\datatype complex\/} number by providing an
imaginary part of {\tt $0$}.
\endlist
%% 12.5.3 1
Many of the irrational and transcendental functions are multiply defined
in the complex domain; for example, there are in general an infinite
number of complex values for the logarithm function. In each such
case, a principal value must be chosen for the function to return.
In general, such values cannot be chosen so as to make the range
continuous; lines in the domain
called branch cuts must be defined, which in turn
define the discontinuities in the range.
%% 12.5.3 2
@clisp\ defines the branch cuts, principal values, and boundary
conditions for the complex functions following
@apl\rm.
%% 12.7.0 1
%% 12.7.0 2
Logical operations require {\datatype integers}
as arguments; an error of type {\datatype type-error}
is signalled if a non-{\datatype integer} is supplied
as an argument.
{\datatype Integer} arguments to logical operations are treated as if
they were represented in two's-complement notation.
Internally an implementation
may or may not use a two's-complement representation.
%% 12.8.0 2
The byte-manipulation {\word forms}
use {\word objects} called byte specifiers to
designate a specific byte position within an {\datatype integer}.
The representation of a byte specifier is implementation-dependent ---
it may or may not be a {\datatype number}.
The function {\function byte} will construct a byte specifier,
and the byte-manipulation {\word forms} will accept it.
The following figures contain lists of {\word tools} applicable to
{\datatype numbers}.
Figure {\chapno--\the\capno} lists the number predicate and comparison
{\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt zerop }&{\tt plusp }&{\tt minusp }\cr
{\tt oddp }&{\tt evenp } &{\tt = }\cr
{\tt /= }&{\tt < } &{\tt > }\cr
{\tt <= }&{\tt >= } &{\tt max }\cr
{\tt min} & & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools} for arithmetic operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt + }&{\tt - } &{\tt * }\cr
{\tt / }&{\tt 1+ } &{\tt 1- }\cr
{\tt incf }&{\tt decf } &{\tt conjugate }\cr
{\tt gcd }&{\tt lcm } & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 2}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for exponential, logarithmic, and trigonometric operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt exp }&{\tt expt } &{\tt log }\cr
{\tt sqrt }&{\tt isqrt } &{\tt abs }\cr
{\tt phase }&{\tt signum } &{\tt sin }\cr
{\tt cos }&{\tt tan } &{\tt cis }\cr
{\tt asin }&{\tt acos } &{\tt atan }\cr
{\tt pi }&{\tt sinh } &{\tt cosh }\cr
{\tt tanh }&{\tt asinh } &{\tt acosh }\cr
{\tt atanh }& &\cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 3}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for type conversion and component extraction operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt float }&{\tt rational} &{\tt rationalize } \cr
{\tt numerator} & {\tt denominator }& {\tt floor} \cr
{\tt ceiling} & {\tt truncate} & {\tt round} \cr
{\tt mod} & {\tt rem} & {\tt ffloor}\cr
{\tt fceiling} & {\tt ftruncate} & {\tt fround}\cr
{\tt decode-float} & {\tt scale-float} & {\tt float-radix}\cr
{\tt float-sign} & {\tt float-digits} & {\tt float-precision}\cr
{\tt integer-decode-float} & {\tt complex} & {\tt realpart}\cr
{\tt imagpart} & & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 4}
\endfig
Figure {\chapno--\the\capno} lists the logical operation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt logior} & {\tt logxor} & {\tt logand} \cr
{\tt logeqv} & {\tt lognand} & {\tt lognor} \cr
{\tt logandc1} & {\tt logandc2 }&{\tt logorc1 } \cr
{\tt logorc2 } & {\tt boole }&{\tt boole-clr }\cr
{\tt boole-set } & {\tt boole-1 }&{\tt boole-2 }\cr
{\tt boole-c1 } & {\tt boole-c2 }&{\tt boole-and }\cr
{\tt boole-ior } & {\tt boole-xor }&{\tt boole-eqv }\cr
{\tt boole-nand } & {\tt boole-nor }&{\tt boole-andc1 }\cr
{\tt boole-andc2 } & {\tt boole-orc1 }&{\tt boole-orc2 }\cr
{\tt lognot } & {\tt logtest }&{\tt logbitp }\cr
{\tt ash } & {\tt logcount} & {\tt integer-length }\cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 5}
\endfig
Figure {\chapno--\the\capno} lists the byte manipulation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt byte} &{\tt byte-size} & {\tt byte-position}\cr
{\tt ldb} & {\tt ldb-test} & {\tt mask-field} \cr
{\tt dpb} & {\tt deposit-field} & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 6}
\endfig
Figure {\chapno--\the\capno} lists the implementation-dependent parameters.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt most-positive-fixnum }& {\tt most-negative-fixnum }\cr
{\tt most-positive-short-float } &{\tt least-positive-short-float} \cr
{\tt least-negative-short-float} & {\tt most-negative-short-float} \cr
{\tt most-positive-single-float } & {\tt least-positive-single-float} \cr
{\tt least-negative-single-float} & {\tt most-negative-single-float} \cr
{\tt most-positive-double-float} & {\tt least-positive-double-float} \cr
{\tt least-negative-double-float} & {\tt most-negative-double-float} \cr
{\tt most-positive-long-float} &{\tt least-positive-long-float} \cr
{\tt least-negative-long-float} & {\tt most-negative-long-float} \cr
{\tt short-float-epsilon} & {\tt single-float-epsilon} \cr
{\tt double-float-epsilon} & {\tt long-float-epsilon} \cr
{\tt short-float-negative-epsilon} & {\tt single-float-negative-epsilon}\cr
{\tt double-float-negative-epsilon}& {\tt long-float-negative-epsilon} \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 7}
\endfig
\beginsubsubsection{\datatype Rational}
The type {\datatype
rational} is composed of the {\word disjoint}
{\datatype integer} and {\datatype
ratio} subtypes.
An {\word object} of type {\datatype rational\/} is called a {\datatype
rational}.
%% 12.1.0 2
The following rules apply to {\datatype rational} computations.
\beginlist
\itemitem {--} Rational computations cannot overflow in the usual sense
(though there may not be enough storage
to represent one), since
{\datatype integers} and {\datatype ratios}
may in principle be of any magnitude.
%% 2.1.2 1
\itemitem {--} The representation of a
{\datatype rational} number is as the ratio of two
integers, the numerator and denominator, where the greatest common divisor of
the numerator and denominator is one, and where the denominator is positive
and greater than one. If the value of a {\datatype rational} is
an {\datatype integer}, it is
represented as an integer.
%% 2.1.2 2
%% 12.1.0 5
\itemitem{--} If any computation produces
a result that is a {\datatype ratio} of
two {\datatype integers} such that the denominator evenly divides the
numerator, then the result is converted to the equivalent
{\datatype integer}.
%% 12.1.0 3
\itemitem{--} When
{\datatype rational} and {\datatype floating-point} numbers
are compared or combined by
a numerical {\word function},
the {\datatype rational}
is first converted to a {\datatype floating-point} number of
the same format. For {\word forms} such as {\function +}
that take more than two arguments,
it is permitted that part of the operation be carried out exactly using
{\datatype rationals}
and the rest be done using floating-point arithmetic.
%% 12.5.0 4
\itemitem{--}
When the arguments to
a mathematical
{\word function} are all {\datatype rational} and the true mathematical result
is also (mathematically) rational, then unless otherwise noted
an implementation is free to return either an accurate
{\datatype rational} result
or a {\datatype single-float} approximation.
If the arguments are all {\datatype rational}
but the result cannot be expressed
as a {\datatype rational} number, then a {\datatype single-float}
approximation is always returned.
\endlist
∂02-Mar-89 0008 X3J13-mailer Section 2.2 - part 3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 00:08:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09450; Thu, 2 Mar 89 00:06:40 PST
Message-Id: <8903020806.AA09450@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09450; Thu, 2 Mar 89 00:06:40 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 03:05
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 3
%%Types - part 3
\beginsubsubsection{\datatype Null}
The only {\word object} of type {\datatype null\/} is @nil\rm.
\beginsubsubsection{\datatype Sequence}
The type {\datatype sequence} has
{\datatype vector} and {\datatype list}
as {\word disjoint subtypes}.
An {\word object} of type {\datatype sequence\/} is called a {\datatype
sequence}.
Figure {\chapno--\the\capno} lists the {\datatype sequence} {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt elt }&{\tt subseq }&{\tt copy-seq }\cr
{\tt length }&{\tt reverse }&{\tt nreverse }\cr
{\tt make-sequence }&{\tt concatenate }&{\tt map }\cr
{\tt some }&{\tt every }&{\tt notany }\cr
{\tt notevery }&{\tt reduce }&{\tt fill }\cr
{\tt replace }&{\tt remove }&{\tt remove-if }\cr
{\tt remove-if-not }&{\tt delete }&{\tt delete-if }\cr
{\tt delete-if-not }&{\tt remove-duplicates }&{\tt delete-duplicates }\cr
{\tt substitute }&{\tt substitute-if }&{\tt substitute-if-not }\cr
{\tt nsubstitute }&{\tt nsubstitute-if }&{\tt nsubstitute-if-not }\cr
{\tt find }&{\tt find-if }&{\tt find-if-not }\cr
{\tt position }&{\tt position-if }&{\tt position-if-not }\cr
{\tt count }&{\tt count-if }&{\tt count-if-not }\cr
{\tt mismatch }&{\tt search }&{\tt sort }\cr
{\tt stable-sort }&{\tt merge }&\cr
\noalign{\vskip -9pt} }}
\caption{Sequence tools}
\endfig
%% 14.0.0 19
Whenever a {\datatype sequence} function must construct and return
a new {\datatype vector}, it always returns a {\datatype simple-vector}.
In particular, any {\datatype strings} constructed
will be {\datatype simple-strings}.
%% 2.5.1 1
\beginsubsubsection{\datatype Vector}
The type {\datatype vector} has {\word subtypes} {\datatype simple-vector,
string}, and {\datatype bit-vector}.
An {\word object} of type {\datatype vector}
(a {\datatype vector}) is a
one-dimensional {\datatype array\/}.
\beginsubsubsection{\datatype Simple-vector}
An {\word object} of type {\datatype simple-vector}
(a {\datatype simple-vector}) is
a {\datatype vector}
that is not displaced to another {\datatype vector},
has no
{\word fill pointer},
is able to hold elements of any {\word type},
and is not to have its size adjusted dynamically after
creation.
\beginsubsubsection{\datatype Bit-vector}
An {\word object} of type {\datatype bit-vector}
(a {\datatype bit-vector})
is a
{\datatype vector} composed of bits.
The type {\datatype bit-vector} has the type {\datatype simple-bit-vector}
as its {\word subtype}.
\beginsubsubsection{\datatype Simple-bit-vector}
An {\word object} of type {\datatype simple-bit-vector}
(a {\datatype simple-bit-vector}) is
a {\datatype bit-vector} that is not displaced to another
{\datatype bit-vector},
has no {\word fill pointer},
and is not to have its size adjusted dynamically after
creation.
%% 2.5.2 1
%% 18.0.0 3
\beginsubsubsection{\datatype String}
An {\word object} of type {\datatype string}
(a {\datatype string}) is
a {\datatype vector} whose
elements are {\datatype string-chars\/}.
{\datatype Simple-string} is a {\word subtype} of {\datatype string}.
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable to {\datatype strings}.
The following rules apply to {\datatype strings} and {\datatype string}
operations:
\beginlist
%% 18.0.0 7
\itemitem{--}
{\datatype Strings} may have {\word fill pointers}.
%% 18.0.0 4
\itemitem{--}
An {\word operator}
that uses the print name of an argument provided as a
{\datatype symbol} (most of
the operators in Figure {\chapno--\the\capno})
is not allowed to modify that {\datatype
symbol}.
%% 18.0.0 5
%% paragraph duplicated in descriptions of string-equal and string=
%% 18.0.0 6
%% paragraph duplicated in description of stringp
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char }&{\tt schar }&{\tt string= }\cr
{\tt string-equal }&{\tt string< }&{\tt string> }\cr
{\tt string<= }&{\tt string>= }&{\tt string/= }\cr
{\tt string-lessp }&{\tt string-greaterp }&{\tt string-not-greaterp }\cr
{\tt string-not-lessp }&{\tt string-not-equal }&{\tt make-string }\cr
{\tt string-trim }&{\tt string-left-trim }&{\tt string-right-trim }\cr
{\tt string-upcase }&{\tt string-downcase }&{\tt string-capitalize }\cr
{\tt nstring-upcase }&{\tt nstring-downcase }&{\tt nstring-capitalize }\cr
{\tt string }& & \cr
\noalign{\vskip -9pt} }}
\caption{String tools}
\endfig
\beginsubsubsection{\datatype Simple-string}
An {\word object} of type {\datatype simple-string}
(a {\datatype simple-string}) is
a {\datatype string} that is not displaced to another {\datatype string},
has no {\word fill pointer}, and is not to have its size adjusted
dynamically after
creation.
%% 2.4.0 2
%% 2.4.0 7
\beginsubsubsection{\datatype List}
The type {\datatype list} is
composed of {\word subtypes}
{\datatype cons} and {\datatype null}, which form an
{\word exhaustive partition}
of {\datatype list}.
An {\word object} of type {\datatype list}
(a {\datatype list})
is a chain of {\datatype conses}
linked by their {\word cdr} components
and terminated by @nil, the empty {\datatype list}.
The {\word car} components of the {\datatype conses}
are called the elements of the {\datatype list}.
For each element of the {\datatype list}
there is a {\datatype cons}. The empty {\datatype list}
has no elements at all.
A {\word dotted list}
is a chain of {\datatype conses}
linked by their {\word cdr} components
and not terminated by @nil.
Unless otherwise specified in this
standard, it is an error to pass a {\word dotted
list} to a {\word function}
that is specified to require a {\datatype list} as an argument.
The following figures contain lists of {\word tools} that are applicable to {\datatype
lists}.
Figure {\chapno--\the\capno} lists the {\datatype cons}
and {\datatype list} operation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt car }&{\tt cdr }&{\tt caar }\cr
{\tt cadr }&{\tt cdar }&{\tt cddr }\cr
{\tt caaar }&{\tt caadr }&{\tt cadar }\cr
{\tt caddr }&{\tt cdaar }&{\tt cdadr }\cr
{\tt cddar }&{\tt cdddr }&{\tt caaaar }\cr
{\tt caaadr }&{\tt caadar }&{\tt caaddr }\cr
{\tt cadaar }&{\tt cadadr }&{\tt caddar }\cr
{\tt cadddr }&{\tt cdaaar }&{\tt cdaadr }\cr
{\tt cdadar }&{\tt cdaddr }&{\tt cddaar }\cr
{\tt cddadr }&{\tt cdddar }&{\tt cddddr }\cr
{\tt cons }&{\tt tree-equal }&{\tt endp }\cr
{\tt list-length }&{\tt nth }&{\tt first }\cr
{\tt second }&{\tt third }&{\tt fourth }\cr
{\tt fifth }&{\tt sixth }&{\tt seventh }\cr
{\tt eighth }&{\tt ninth }&{\tt tenth }\cr
{\tt rest }&{\tt nthcdr }&{\tt last }\cr
{\tt list }&{\tt list* } & {\tt make-list }\cr
{\tt append } & {\tt copy-list }&{\tt copy-alist }\cr
{\tt copy-tree }& {\tt revappend }&{\tt nconc }\cr
{\tt nreconc }& {\tt push }&{\tt pushnew }\cr
{\tt pop }& {\tt butlast }&{\tt nbutlast }\cr
{\tt ldiff } & &\cr
\noalign{\vskip -9pt} }}
\caption{List tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the
{\datatype list} structure alteration and expression substitution {\word
tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt rplaca }&{\tt rplacd }&{\tt subst }\cr
{\tt subst-if }&{\tt subst-if-not }&{\tt nsubst }\cr
{\tt nsubst-if }&{\tt nsubst-if-not }&{\tt sublis }\cr
{\tt nsublis }& & \cr
\noalign{\vskip -9pt} }}
\caption{List tools - 2}
\endfig
Figure {\chapno--\the\capno} lists the set
operation and association list {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt member }&{\tt member-if } & {\tt member-if-not }\cr
{\tt tailp }&{\tt adjoin }& {\tt union }\cr
{\tt nunion }&{\tt intersection }& {\tt nintersection }\cr
{\tt set-difference }&{\tt nset-difference }& {\tt set-exclusive-or }\cr
{\tt nset-exclusive-or }&{\tt subsetp }& {\tt acons }\cr
{\tt pairlis }&{\tt assoc }& {\tt assoc-if }\cr
{\tt assoc-if-not }&{\tt rassoc }& {\tt rassoc-if }\cr
{\tt rassoc-if-not }&&\cr
\noalign{\vskip -9pt} }}
\caption{List tools - 3}
\endfig
\goodbreak
Following are examples of printed representations of {\datatype lists}:
\screen!
(a . b) ;A dotted pair of a and b
(a.b) ;A list of one element, the symbol named a.b
(a. b) ;A list of two elements a. and b
(a .b) ;A list of two elements a and .b
(a b . c) ;A dotted list of a and b with c at the end; two conses
.iot ;The symbol whose name is .iot
(. b) ;Illegal -- an error is signalled if an attempt is made to read
;this syntax.
(a .) ;Illegal -- an error is signalled.
(a .. b) ;Illegal -- an error is signalled.
(a . . b) ;Illegal -- an error is signalled.
(a b c ...);Illegal -- an error is signalled.
(a @bsl\ . b) ;A list of three elements a, ., and b
(a @vert\ .@vert b) ;A list of three elements a, ., and b
(a @bsl\ ... b) ;A list of three elements a, ..., and b
(a @vert\ ...@vert b) ;A list of three elements a, ..., and b
\endscreen!
∂01-Mar-89 2355 X3J13-mailer Section 2.2 - part 2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 23:55:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08620; Wed, 1 Mar 89 23:53:21 PST
Message-Id: <8903020753.AA08620@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA08620; Wed, 1 Mar 89 23:53:21 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 02:51
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 2
%%Types - part 2
\beginsubsubsection{\datatype Ratio}
An {\word object} of type {\datatype ratio\/} (a {\datatype ratio}) is the
mathematical ratio of two {\datatype integers}.
%% 2.1.1 1
\beginsubsubsection{\datatype Integer}
The type {\datatype integer} is composed of
{\word disjoint} {\datatype
fixnum} and {\datatype bignum} subtypes.
An {\word object} of type {\datatype integer\/} (an {\datatype integer}) is a
mathematical integer. There is no limit on the magnitude of an
{\datatype
integer}.
Properties of integers follow:
\beginlist
\itemitem{--} 0 = $-0$
\itemitem{--} The default printed
representation and interpretation for an {\datatype
integer} is decimal.
\endlist
%% 2.1.1 2
\beginsubsubsection{\datatype Fixnum}
An {\word object} of type {\datatype fixnum} (a {\datatype fixnum}) is an
an
{\datatype integer} whose value is between
{\function most-negative-fixnum} and
{\function most-positive-fixnum} inclusive.
Exactly which {\datatype integers} are
{\datatype fixnums} is implementation-dependent.
\beginsubsubsection{\datatype Bignum}
An {\word object} of type {\datatype bignum} (a {\datatype bignum})
is an
{\datatype integer} outside the {\datatype fixnum} range.
\beginsubsubsection{\datatype Float}
The type {\datatype float} is composed of the
{\word disjoint} or identical {\datatype short-float},
{\datatype single-float},
{\datatype double-float}, and {\datatype long-float} subtypes.
An {\word object} of type {\datatype float} (a {\datatype floating}-point
number)
is a (mathematical)
{\datatype rational} of the form
{\it s@centerdot f@centerdot $b↑{e-p}$},
where {\it s} is +1 or @minussign 1, the {\it sign}\rm;
{\it b} is an {\datatype integer}
greater than 1, the {\it base} or {\it radix} of the representation;
{\it p} is a positive {\datatype integer},
the {\it precision} (in base-{\it b} digits) of the floating-point {\datatype
number};
{\it f} is a positive {\datatype integer}
between {\it $b↑{p-1}$} and
{\it $b↑p-1$} (inclusive), the significand;
and {\it e} is an {\datatype integer}, the exponent.
The value of {\it p} and the range of {\it e}
depends on the implementation and on the type of {\datatype floating-point} number
within that implementation.
An {\word object} of type {\datatype short-float\/} is called a {\datatype
short-float}.
An {\word object} of type {\datatype single-float\/} is called a {\datatype
single-float}.
An {\word object} of type {\datatype double-float\/} is called a {\datatype
double-float}.
An {\word object} of type {\datatype long-float\/} is called a {\datatype
long-float}.
Properties of {\datatype floating-point} numbers follow:
\beginlist
\itemitem{--} There is a {\datatype floating-point} number
whose value is zero.
\itemitem{--} If the numeric representation of
{\datatype floating-point} numbers
allows ``minus zero'', it will exist.
\itemitem{--} {\tt $0.0$ = $-0.0$} if there is no minus zero.
\endlist
%% 2.1.3 6
Intermediate between {\datatype short-float} and {\datatype long-float}
are
{\datatype single-float} and {\datatype double-float}.
The precise definition of these categories is implementation-dependent.
The precision (measured in ``bits'', computed as {\it p} log$\sub 2${\it b}\rm)
and the exponent size (also measured in ``bits'', computed as
log$\sub 2$ (maximum exponent value + 1)) is recommended
to be at least as great
as the values in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip
\dimen0 plus .5 fil&#\hfil\cr
\noalign{\vskip -9pt}
\hfil\bf Format &Minimum Precision &Minimum Exponent Size \cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
Short&13 bits&5 bits\cr
Single&24 bits&8 bits\cr
Double&50 bits&8 bits\cr
Long&50 bits&8 bits\cr
\noalign{\vskip -9pt}
}}
\caption{Recommended Minimum Floating-Point Precision and Exponent Size}
\endfig
%% 2.1.3 10
%% 2.1.3 11
%% 2.1.3 18
There may be fewer than four internal
representations for {\datatype floating-point} numbers.
If there are fewer distinct representations, the following fules apply:
\beginlist
\itemitem{--} If there is only one, it is of
the type {\datatype single-float}.
In this representation, an {\word object} is simultaneously of types
{\datatype single-float, double-float, short-float}, and {\datatype
long-float}.
\itemitem{--} Two internal representations can be arranged in either of the
following ways:
\beginlist
\itemitem{\bull} Two {\word types} are provided: {\datatype single-float} and
{\datatype short-float}. An {\word object} is simultaneously of types
{\datatype single-float, double-float}, and {\datatype long-float}.
\itemitem{\bull} Two {\word types} are provided: {\datatype single-float} and
{\datatype double-float}. An {\word object} is simultaneously of types
{\datatype single-float} and {\datatype short-float}, or
{\datatype double-float} and {\datatype long-float}.
\endlist
\itemitem{--} Three internal representations can be arranged in either
of the following ways:
\beginlist
\itemitem{\bull} Three {\word types} are provided: {\datatype short-float},
{\datatype single-float}, and
{\datatype double-float}. An {\word object} can
simultaneously be of type {\datatype double-float} and {\datatype long-float}.
\itemitem{\bull} Three {\word types} are provided:
{\datatype single-float}, {\datatype double-float},
and {\datatype long-float}. An {\word object} can simultaneously
be of types {\datatype single-float} and {\datatype short-float}.
\endlist
\endlist
Figure {\chapno--\the\capno} contains
examples of printed {\datatype floating-point} numbers:
The following rules apply to floating point computations.
%% 12.1.0 1
%% 12.5.0 3
\beginlist
\itemitem{--}
Computations with {\datatype floating-point} numbers are only approximate,
although they are described as if the results
were mathematically accurate.
Two mathematically identical
expressions may be computationally different because of errors
inherent in the floating-point approximation process.
The precision of a {\datatype floating-point} number is not necessarily
correlated with the accuracy of that number.
For instance, 3.142857142857142857 is a more precise approximation
to $\pi$ than 3.14159, but the latter is more accurate.
The precision refers to the number of bits retained in the representation.
When an operation combines a {\datatype short-float} with a
{\datatype long-float},
the result will be a {\datatype long-float}.
@clisp\ {\word functions} assume that the accuracy of
arguments to them does not exceed their precision. Therefore
when two small {\datatype floating-point} numbers
are combined, the result is a small {\datatype floating-point} number.
@clisp\ {\word functions}
never convert automatically from a larger size to a smaller one.
%% 12.1.0 2
\itemitem{--} An error of type {\datatype floating-point-overflow}
or {\datatype floating-point-underflow} should be signalled if a
floating-point computation causes exponent overflow or underflow.
%% 12.1.0 5
\itemitem{--}
The result of a numerical function
is a {\datatype floating-point} number of the largest format among all the
floating-point arguments to the {\word function}.
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip
\dimen0 plus .5 fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt 0.0} & ;Floating-point zero in default format
\cr
{\tt 0E0 } & ;Also floating-point zero in default format
\cr
{\tt -.0 } & ;This may be a zero or a minus zero, \cr
& ; depending on the implementation \cr
{\tt 0.} & ;The integer zero, not a floating-point
number! \cr
{\tt 0.0s0 } & ;A floating-point zero in short format
\cr
{\tt 0s0 } & ;Also a floating-point zero in short format
\cr
{\tt 6.02E+23} & ;Avogadro's number, in default format
\cr
{\tt 602E+21} & ;Also Avogadro's number, in default format
\cr
%3.010299957f-1 & ;$log_10$2, in single format \cr
}}
\caption{Examples of Floating-point numbers}
\endfig
%% 2.1.4 1
%% 2.1.4 4
\beginsubsubsection{\datatype Complex}
An {\word object} of type {\datatype complex\/} (a {\datatype complex\/} number)
is represented in Cartesian form, with a real part and an imaginary
part each of which is not a
{\datatype complex\/} number
(i.e. an {\datatype integer}, {\datatype ratio}, or {\datatype floating-point}
number). The parts of a {\datatype complex\/} number
are not necessarily {\datatype floating-point} numbers
but both parts must
be of the same {\word type}: either both are
{\datatype rationals}, or both are
of the same {\datatype floating-point} number {\word subtype}.
When constructing
a {\datatype complex\/} number, if the specified parts are not the same
{\word type}, the parts will be converted to be the same {\word type}
internally (i.e. the {\datatype rational} part
will be converted to
a {\datatype floating-point} number).
An {\word object} of type
{\tt (complex rational)}
will be converted internally and represented thereafter as
a {\datatype rational}
if its imaginary part is an
{\datatype integer} whose value is 0.
%% 12.1.0 6
The following rules apply to {\datatype complex\/} computations:
\beginlist
\itemitem{--}
Except during the execution of irrational and
transcendental {\word forms}, {\datatype complex\/}
numbers never result from a numerical {\word form}
unless one or more of the
arguments is {\datatype complex\/}.
\itemitem{--}
When a non-{\datatype complex\/} number and
a {\datatype complex\/} number are both part of a computation,
the non-{\datatype complex\/}
number is first converted to a {\datatype complex\/} number by providing an
imaginary part of @f[0]\rm.
%% 12.1.0 8
\itemitem{--}
If the result of any computation would be a {\datatype complex\/}
number whose real part is of type {\datatype rational} and whose imaginary
part is zero, the result is
converted to a non-{\datatype complex\/} number
of type {\datatype rational} composed of the
real part.
This rule does not apply to {\datatype complex\/} numbers whose parts
are {\datatype floating-point} numbers.
For example, @f[\#C(5 0)] and @f[5] are not
distinct values in @clisp\ (they are always {\function eql});
@f[\#C(5.0 0.0)] and @f[5.0] are always distinct values in @clisp\
(they are never {\function eql}, although they are {\function equalp}).
\endlist
%% 12.5.3 17
Figure {\chapno--\the\capno} lists
the identities that are obeyed
throughout the applicable portion of the complex domain, even on
the branch cuts:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
sin i z = i sinh z & sinh i z = i sin z& arctan i z = i arctanh z \cr
cos i z = cosh z & cosh i z = cos z & arcsinhi z = i arcsin z \cr
tan i z = i tanh z & arcsin i z = i arcsinh z & arctanh i z = i arctan z \cr
\noalign{\vskip -9pt}
}}
\caption{Trigonometric Identities for Complex Domain}
\endfig
%% 2.2.4 1
\beginsubsubsection{\datatype Character}
The type {\datatype character} has a
{\word subtype}
of {\datatype string-char}.
An {\word object} of type {\datatype character} (a {\datatype character})
has three non-negative attributes: code, bits, and font.
%% 13.0.0 3
%% 13.0.0 4
The following rules apply to {\datatype characters}:
\beginlist
\itemitem{--} Two {\datatype characters}
that are {\function eql}, {\function char=}, or {\function char-equal}
are not necessarily {\function eq}.
%% 13.1.0 1
\itemitem{--} Every {\datatype character}
has three attributes: code, bits, and font.
The code attribute is intended to distinguish among the printed glyphs
and formatting functions for {\datatype characters}.
The bits attribute allows extra
flags to be associated with a {\datatype character}. The font attribute permits
a specification of the style of the glyphs (such as italics).
Each of these attributes is a non-negative
{\datatype integer}.
%% 13.5.0 1
\itemitem{--} Four bits of the bits attribute are defined:
Control, Meta, Hyper, and Super.
Each @clisp\ implementation provides these bit definitions for compatibility,
even if it does not support the bits.
\itemitem{--} The total ordering on
{\datatype characters} is guaranteed to have the following
properties:
\beginlist
%% 13.2.0 27
\itemitem{\bull} If two {\datatype characters}
have the same bits and font attributes,
then their ordering by {\function char<} is consistent with the numerical
ordering by the predicate {\function <} on their code attributes.
%% 13.2.0 28
\itemitem{\bull} If two {\datatype characters}
differ in any attribute (code, bits, or font), then they
are different.
%% 13.2.0 29
\itemitem{\bull} The total ordering is not necessarily the same as the total
ordering on the {\datatype integers}
produced by applying @Funref[char-int] to the
{\datatype characters}.
%% 13.2.0 30
\itemitem{\bull}
While alphabetic {\datatype characters} of a given case must be
properly ordered, they need not be contiguous; it is permitted for
uppercase and lowercase letters to be interleaved.
Thus @f[(char<= \#{\char '134}a x
\#{\char '134}z)] is not
a valid way of determining whether or not @f[x] is a
lowercase letter.
%% 13.2.0 34
\itemitem{\bull}
The ordering may depend on the font information. For example, an implementation
might decree that {\tt (char-equal \#{\char '134}p \#{\char '134}{\it p})}
be true, but that
{\tt (char-equal \#{\char '134}p \#{\char '134}$\pi$)}
be false (where {\tt \#{\char '134}$\pi$} is a
lowercase @f[p] in some font). Assuming italics to be in font 1
and the Greek alphabet in font 2, this is the same as saying that
{\tt (char-equal \#0{\char '134}p \#1{\char '134}p)}
may be true and at the same time
{\tt (char-equal \#0{\char '134}p \#2{\char '134}p)} may be false.
\endlist
%% 13.2.0 25
%% 13.2.0 26
The standard alphanumeric characters obey the following partial ordering:
@Lisp
A<B<C<D<E<F<G<H<I<J<K<L<M<N<O<P<Q<R<S<T<U<V<W<X<Y<Z
a<b<c<d<e<f<g<h<i<j<k<l<m<n<o<p<q<r<s<t<u<v<w<x<y<z
0<1<2<3<4<5<6<7<8<9
either 9<A or Z<0
either 9<a or z<0
@Endlisp
This implies that alphabetic ordering holds within each case (upper and
lower), and that the digits as a group
are not interleaved with letters. However, the ordering
or possible interleaving of
uppercase letters and lowercase letters is unspecified.
The following figures contain lists of {\word tools} applicable to {\datatype
characters}.
Figure {\chapno--\the\capno} lists the {\datatype character}
attribute and predicate {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char-code-limit }&{\tt char-font-limit }&{\tt char-bits-limit }\cr
{\tt standard-char-p }&{\tt graphic-char-p }&{\tt string-char-p }\cr
{\tt alpha-char-p }&{\tt upper-case-p }&{\tt lower-case-p }\cr
{\tt both-case-p }&{\tt digit-char-p }&{\tt alphanumericp }\cr
{\tt char= }&{\tt char/= }&{\tt char< }\cr
{\tt char> }&{\tt char<= }&{\tt char>= }\cr
{\tt char-equal }&{\tt char-not-equal }&{\tt char-lessp }\cr
{\tt char-greaterp }&{\tt char-not-greaterp }&{\tt char-not-lessp }\cr
\noalign{\vskip -9pt} }}
\caption{Character tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the
{\datatype character} construction, conversion, and control-bit {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char-code }&{\tt char-bits }&{\tt char-font }\cr
{\tt code-char }&{\tt make-char }&{\tt character }\cr
{\tt char-upcase }&{\tt char-downcase }&{\tt digit-char }\cr
{\tt char-int }&{\tt int-char }&{\tt char-name }\cr
{\tt name-char }&{\tt char-control-bit }&{\tt char-meta-bit }\cr
{\tt char-super-bit }&{\tt char-hyper-bit }&{\tt char-bit }\cr
{\tt set-char-bit }& & \cr
\noalign{\vskip -9pt} }}
\caption{Character tools - 2}
\endfig
%% 2.2.5 1
\beginsubsubsection{\datatype String-char}
The type {\datatype string-char} has a {\word subtype} of {\datatype
standard-char}.
An {\word object} of type {\datatype string-char} (a {\datatype string-char})
is a {\datatype character\/} whose bit and font
attributes are {\datatype integers}
whose values are 0.
\beginsubsubsection{\datatype Standard-char}
{\word Objects} of type {\datatype standard-char} ({\datatype standard-chars})
are listed
in ``Object Syntax''.
%% 2.3.0 1
%% 2.3.0 2
\beginsubsubsection{\datatype Symbol}
An {\word object} of type {\datatype symbol} (a {\datatype symbol})
is a data structure
composed of a print namestring,
a package name, and a
property list. A {\datatype symbol} may be retrieved from
a {\datatype package} given a print name.
{\datatype Symbols} can be interned or uninterned in a {\datatype package}.
%% 11.0.0 11
To intern a {\datatype symbol} in a {\datatype package} means to cause the
{\datatype symbol}
to be accessible in the {\datatype package} if it were not already.
See {\function intern}.
If the {\datatype symbol} were previously unowned, then the
{\datatype package} it is being
interned in becomes its owner (home package); but
if the {\datatype symbol}
was previously owned by another {\datatype package}, that other {\datatype
package}
continues to own the {\datatype symbol}.
%% 10.3.0 2
%% 10.3.0 3
Interned symbols are created automatically by {\function intern};
If a given print name does not have a corresponding
{\datatype symbol} in the specified or
inherited {\datatype packages}, a {\datatype symbol} is
created for that print name.
the first time
something (such as {\function read})
asks the package system for a {\datatype symbol} with a given print name,
that {\datatype symbol} is automatically created.
%% 11.0.0 12
To unintern a {\datatype symbol} from a
{\datatype package} means to cause it to be not
present and, additionally, to make the {\datatype symbol} uninterned if the
{\datatype package} is the {\datatype symbol's} home package.
See @Funref[unintern]\rm.
%% 10.3.0 1
{\datatype Symbols} have the following
components, the first three of which are user-visible.
%% 10.0.0 3
%% 10.0.0 4
%% 10.1.0 1
%% 10.1.0 2
%% 10.1.0 3
\beginlist
\itemitem{\bf Property list}
The property list is an even-length
{\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero)
are indicators (no duplicates on the same
property list are allowed)
and whose odd-numbered components are {\word objects}.
The property list of a {\datatype symbol}
may be destructively replaced.
A property-value pair in the property list may be added or updated.
%% 10.1.0 4
When a {\datatype symbol} is created, its property list is initially empty.
Properties are created by using {\function setf} of @Macref[get]\rm.
Any form acceptable to {\function setf\/}
as a {\word
generalized reference} can be used to store the property list.
%% 10.0.0 5
%% 10.2.0 1
\itemitem{\bf Print name}
The print name is a {\datatype string},
used to identify the {\datatype symbol}.
Every
{\datatype symbol} has a print name, and that
name can not be altered.
The print name is used as the external representation of the
{\datatype symbol}.
If the {\datatype characters} in the {\datatype string}
of the print name are typed in to {\function read}
(with suitable escape conventions for certain characters),
it is interpreted as a reference to that {\datatype symbol}
(if it is {\word interned}); and if the {\datatype symbol}
is printed, {\function print} outputs the
print name.
Given the print name of a {\datatype symbol}
as a {\datatype string} the
{\datatype symbol} can be obtained.
Every time a {\datatype symbol} with a certain print name is referenced,
the same ({\function eq}) {\datatype symbol } is returned.
{\datatype Symbols} are organized into
{\datatype packages}, and all the {\datatype symbols}
in a {\datatype package} are uniquely
identified by print name.
A {\datatype symbol\/}'s print name can be composed
of any {\datatype string-char}. Space and parenthesis characters
must be preceded by an
escape character in order to be a part of a {\datatype symbol\/}'s print name.
A {\datatype symbol\/}'s print name must contain escape characters if
\beginlist
\itemitem{\bull} It would be composed of only periods
(.).
\itemitem{\bull} It would be syntactically identical to a
{\datatype number}.
\endlist
Any double quote in the name
of a {\datatype symbol} written using vertical-bar notation need not be
preceded by a @bsl.
%% 10.0.0 4
%% 10.3.0 4
%% 11.0.0 8
%% 11.0.0 10
%% 11.0.0 28
\itemitem{Package cell}
The package cell
contains a pointer to the {\datatype symbol's}
home {\datatype package}, if
it is interned in and owned by any {\datatype package},
or @false\ if it is uninterned (not owned by a {\datatype package}).
The package cell
may be accessed by @Funref[symbol-package]\rm.
A {\datatype symbol} may
appear in many {\datatype packages}, but it can have at most
one home {\datatype package}.
The same print name may refer to different {\datatype symbols} in
different {\datatype packages}.
%% 10.0.0 8
\itemitem{Other components}
A {\datatype symbol} may have other components for use by the
implementation.
\endlist
Following is the list of
{\word tools} that are applicable to the property list of
{\datatype symbols}: {\tt get}, {\tt remprop},
{\tt symbol-plist}, {\tt getf}, {\tt remf}, and
{\tt get-properties}.
The function {\tt symbol-name} is used to access the print name of
a symbol.
Following is the list of
{\word tools} that are applicable to creating
{\datatype symbols}: {\tt make-symbol}, {\tt copy-symbol},
{\tt gensym}, {\tt gentemp}, {\tt symbol-package}, and
{\tt keywordp}.
∂02-Mar-89 0834 X3J13-mailer Section 2.2 - part 4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 08:33:46 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02028; Thu, 2 Mar 89 08:31:42 PST
Message-Id: <8903021631.AA02028@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02028; Thu, 2 Mar 89 08:31:42 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 07:40
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 4
%%Types - part 4
\beginsubsubsection{\datatype Cons}
An {\word object} of type {\datatype cons}
is called a {\word cons}.
%% 2.5.0 1
\beginsubsubsection{\datatype Array\/}
The type {\datatype array\/} has {\word subtypes} {\datatype vector}
and {\datatype simple-array}.
An {\word object} of type {\datatype array\/}
(an {\datatype array\/})
contains {\word objects} arranged according
to a Cartesian coordinate system.
%% 17.0.0 3
The following rules apply to {\datatype arrays\/}.
\beginlist
\itemitem{--} An {\datatype array\/} contains components arranged according
to a rectilinear coordinate system.
%% 17.0.0 4
An {\datatype array\/}
may be a general {\datatype array\/}, meaning each element may be any @xlisp\
{\word object}, or it may be a specialized {\datatype array\/},
meaning that each element
must be of a restricted {\word type}.
%% 2.5.0 3
%% 2.5.0 4
\itemitem{--}
In principle, an
{\datatype array\/} in @clisp\ may have any number of dimensions, including zero.
It is permissible for a dimension to be zero, in which case
the {\datatype array\/}
has no elements, and any attempt to access an element
is an error. However, other properties of the {\datatype array\/},
such as the
dimensions themselves, may be used.
If the rank is zero, then there are no dimensions, and the
product of the dimensions is then by definition 1.
A zero-rank {\datatype array\/} therefore has a single element.
\itemitem{--} An implementation of may impose a limit on the rank of an
{\datatype array\/},
but this limit may not be smaller than 7.
The value of @conref[array-rank-limit] is the implementation's limit on
{\datatype array\/} rank.
\itemitem{--}Each dimension is a non-negative
{\datatype integer}; if any dimension of an {\datatype array\/} is zero,
the {\datatype array\/} has no elements.
%% 17.0.0 5
\itemitem{--}
General {\datatype vectors} may contain
any @xlisp\ {\word object}. {\datatype Vectors}
whose elements are restricted to type
{\datatype string-char} are called {\datatype strings}.
{\datatype Vectors} whose elements are
restricted to type {\datatype bit} are called {\datatype bit-vectors}.
%% 17.5.0 4
\itemitem{--}
Only {\datatype vectors} may have {\word fill pointers};
multidimensional {\datatype arrays\/} may not.
A multidimensional {\datatype array\/}
that is displaced to a {\datatype vector} that has
a {\word fill pointer} can be created.
%% 2.5.0 8
\itemitem{--}
Multidimensional {\datatype arrays\/}
store their components in row-major order;
that is, internally a multidimensional {\datatype array\/}
is stored as a one-dimensional
{\datatype array\/},
with the multidimensional index sets ordered lexicographically,
last index varying fastest.
%% 2.5.0 5
\itemitem{--}
An {\datatype array\/} element is specified by a series of indices.
The length of the series must equal the rank of the {\datatype array\/}.
Each index must be a non-negative {\datatype integer} strictly less than
the corresponding {\datatype array\/} dimension. {\datatype Array\/}
indexing is zero-origin.
\itemitem{--}
%% 17.1.0 13
When an array A is given as
the @Kwd[displaced-to] argument to {\function make-array}
when creating array B,
then array B is said to be displaced to array A. The
total number of elements in an {\datatype array\/},
called the total size of the {\datatype array\/},
is calculated as the product of all the dimensions.
It is required that the total size of A be no smaller than the sum
of the total size of B plus the offset @f[n] supplied by
the @Kwd[displaced-index-offset]
argument. The effect of displacing is that array B does not have any
elements of its own, but instead maps accesses to itself into
accesses to array A. The mapping treats both {\datatype arrays\/} as if they
were one-dimensional by taking the elements in row-major order,
and then maps an access to element @f[k] of array B to an access to element
@f[k]+@f[n] of array A.
\itemitem{--}
When {\keyword displaced-to} is supplied to {\function make-array},
{\keyword displaced-index-offset} is made to be the
index offset of the \array.
If {\keyword displaced-index-offset} is not supplied,
the index offset is zero.
\endlist
The following figures contain lists of {\word tools} that are applicable to {\datatype
arrays}.
Figure {\chapno--\the\capno} lists the {\datatype array\/}
creation, access, and information {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-array }&{\tt array-rank-limit }&{\tt array-dimension-limit }\cr
{\tt array-total-size-limit }&{\tt vector }&{\tt aref }\cr
{\tt svref }&{\tt array-element-type }&{\tt array-rank }\cr
{\tt array-dimension }&{\tt array-dimensions }&{\tt array-total-size }\cr
{\tt array-in-bounds-p }&{\tt array-row-major-index }&{\tt adjustable-array-p }\cr
{\tt upgraded-array-element-type} & {\tt upgraded-complex-part-type} & \cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for operations on {\datatype arrays} of bits.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt bit }&{\tt sbit }&{\tt bit-and }\cr
{\tt bit-ior }&{\tt bit-xor }&{\tt bit-eqv }\cr
{\tt bit-nand }&{\tt bit-nor }&{\tt bit-andc1 }\cr
{\tt bit-andc2 }&{\tt bit-orc1 }&{\tt bit-orc2 }\cr
{\tt bit-not }&&\cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 2}
\endfig
Figure {\chapno--\the\capno} lists
the {\datatype array\/} {\word fill pointer}
and dimension modification {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt array-has-fill-pointer-p }&{\tt fill-pointer }&{\tt vector-push}\cr
{\tt vector-push-extend }&{\tt vector-pop }&{\tt adjust-array }\cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 3}
\endfig
%% 2.5.0 9
\beginsubsubsection{\datatype Simple-array}
The type {\datatype simple-array\/}
has {\word subtypes} {\datatype
simple-vector}, {\datatype simple-string}, and {\datatype simple-bit-vector}.
An {\word object} of type {\datatype simple-array\/}
(a {\datatype simple-array\/}) is
an {\datatype array\/}
that is not displaced to another {\datatype array\/},
has no {\word fill pointer}, and
is not to have its size adjusted dynamically after
creation.
%% 2.5.1 4
Implementations may provide certain specialized representations of
{\datatype arrays\/}
for efficiency in the case where all the components are of
the same specialized type.
All implementations are required to provide specialized {\datatype arrays\/}
of bits, that is, {\datatype objects} of type {\tt (array bit)};
the one-dimensional instances of
this specialization are called {\datatype bit-vectors}.
All implementations
provide specialized {\datatype arrays\/}
for the cases when the components
are {\datatype characters} (or rather,
a special subset of the {\datatype characters});
the one-dimensional instances of
this specialization are called {\datatype strings}.
%% 2.10.0 1
\beginsubsubsection{\datatype Stream}
An {\word object} of type {\datatype stream} (a {\datatype stream})
is a source or sink of data.
%% 21.0.0 3
%% 21.0.0 4
For example, character {\datatype streams}
produce or absorb {\datatype characters};
binary {\datatype streams} produce or absorb {\datatype integers}.
%% 21.0.0 3
A {\datatype stream}, whether a character stream or a binary
stream, may be input-only, output-only, or bidirectional.
What operations may be performed on a {\datatype stream} depends on which
type of {\datatype stream} it is.
%% 22.0.0 3
%All input/output operations are performed on {\datatype streams}
%of various kinds.
The following figures contain lists of {\word tools} that are applicable to {\datatype
streams}.
Figure {\chapno--\the\capno} lists the standard {\datatype streams}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[standard-input] & @var[standard-output] & @var[error-output] \cr
@var[query-io] & @var[debug-io] & @var[terminal-io] \cr
@var[trace-output] & &\cr
\noalign{\vskip -9pt} }}
\caption{Stream tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\datatype stream}
creation and manipulation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-synonym-stream }&{\tt make-broadcast-stream }\cr
{\tt make-concatenated-stream} & {\tt make-two-way-stream }\cr
{\tt make-echo-stream }&{\tt make-string-input-stream }\cr
{\tt make-string-output-stream }&{\tt get-output-stream-string }\cr
{\tt with-open-stream } & {\tt with-input-from-string }\cr
{\tt with-output-to-string }& {\tt streamp } \cr
{\tt input-stream-p }&{\tt output-stream-p }\cr
{\tt stream-element-type } & {\tt close } \cr
\noalign{\vskip -9pt} }}
\caption{Stream tools - 2}
\endfig
\beginsubsubsection{\datatype Hash-table}
An {\word object} of type {\datatype hash-table} (a {\datatype hash-table})
contains keys and values.
%% 16.0.0 3
A {\datatype hash-table} maps a given
@xlisp\ {\word object} to another @xlisp\ {\word object} via a hash
mechanism.
Each {\datatype hash-table}
has a set of entries, each of which associates a
key with a value.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to {\datatype hash-tables}.
The following rules apply to {\datatype hash-tables}.
%% 16.0.0 4
\beginlist
\itemitem{--}
A {\datatype hash-table} can only associate one value with a given
key. Adding a value to a {\datatype hash-table} is a destructive operation;
the {\datatype hash-table} is modified.
%% 16.0.0 5
\itemitem{--}
There are three kinds of {\datatype hash-tables} -- those whose keys
are compared with {\function eq}, those whose keys
are compared with {\function eql}, and those whose keys
are compared with {\function equal}.
%% 16.0.0 6
\itemitem{--}
{\datatype Hash-tables} are created by
{\function make-hash-table}.
{\function gethash} is used to look up a key and find
the associated value.
New entries are added
to {\datatype hash-tables} using @Macref[setf] with {\function gethash}.
{\function remhash} is used to remove an entry.
For example:
@Lisp
(setq a (make-hash-table)) @EV #<Hash Table...>
(setf (gethash 'color a) 'brown) @EV BROWN
(setf (gethash 'name a) 'fred) @EV FRED
(gethash 'color a) @EV BROWN T
(gethash 'name a) @EV FRED T
(gethash 'pointy a) @EV @false @false
@Endlisp
%% 16.0.0 7
In this example, the {\word symbols} @f[color] and @f[name] are being used as
keys, and the {\word symbols} @f[brown] and @f[fred] are being used as the
associated values. The {\datatype hash-table}
has two items in it, one of which
associates from @f[color] to @f[brown]\rm, and the other of which
associates from @f[name] to @f[fred]\rm.
%% 16.0.0 8
\itemitem{--}
A key or a value may be any {\word object}.
%% 16.0.0 9
\itemitem{--}
When a {\datatype hash-table}
is first created, it has a size, which is the
maximum number of entries it can hold. Usually the actual capacity of
the table is somewhat less, since the hashing is not perfectly
collision-free. If so many entries are
added that the capacity is exceeded, the {\datatype hash-table}
will automatically
grow, and the entries will be rehashed (new hash values will be
recomputed, and everything will be rearranged so that the fast hash
lookup still works). This is transparent to the caller; it all happens
automatically.
%% 16.0.0 10
\itemitem{--}
The cases
of @f[nil] as a value and no entry in the {\datatype hash-table}
can be distinguished by the second value returned by {\function gethash}.
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-hash-table }&{\tt hash-table-p }&{\tt gethash }\cr
{\tt remhash }&{\tt maphash }&{\tt clrhash }\cr
{\tt hash-table-count }&{\tt sxhash }&\cr
\noalign{\vskip -9pt} }}
\caption{Hash-table tools}
\endfig
%% 2.7.0 1
%% 22.1.5 2
\beginsubsubsection{\datatype Readtable}
An {\word object} of type {\datatype readtable} (a {\datatype readtable})
maps {\datatype
characters\/} into syntax
types for the {\word Lisp reader} (see ``Character Reader'').
A {\datatype readtable}
contains a macro
definition for
each {\datatype character} with macro character syntax.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to {\datatype readtables}.
See ``Object Syntax''.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[readtable] & {\tt copy-readtable} \cr
{\tt readtablep } & {\tt set-syntax-from-char }\cr
{\tt set-macro-character }&{\tt get-macro-character }\cr
{\tt make-dispatch-macro-character }&{\tt set-dispatch-macro-character }\cr
{\tt get-dispatch-macro-character} & \cr
\noalign{\vskip -9pt} }}
\caption{Readtable tools}
\endfig
∂02-Mar-89 0930 X3J13-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:30:00 PST
Date: Thu, 02 Mar 89 02:27:38 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.022738.baggins@almvma>
Subject: cs proposal comments
Just a reminder, please send comments/straw ballots to x3j13 and
not the characters mailing list.
Regards,
Thom
∂02-Mar-89 0928 X3J13-mailer forwarding note from gregor from larry
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:27:42 PST
Date: Wed, 01 Mar 89 13:15:48 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890301.131548.baggins@almvma>
Subject: forwarding note from gregor from larry
=========================================================================
Received: from Xerox.COM by ibm.COM on 02/23/89 at 10:00:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 FEB 89 09:56:23 PST
Date: Thu, 23 Feb 89 09:56 PST
From: Gregor.pa@Xerox.COM
Subject: [masinter.pa: Re: cs proposal straw vote]
To: baggins@IBM.com
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
Included-msgs: The message of 22 Feb 89 20:59 PST from masinter.pa
Included-References: The message of 22 Feb 89 12:08 PST from
baggins@IBM.com
Message-ID: <19890223175611.1.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Larry asked me to forward this to you as the official Xerox position on
the straw ballot.
Date: Wed, 22 Feb 89 20:59 PST
From: masinter.pa
My personal opinion:
CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE:
Eliminate of font and bit attributes.
**** Yes
Add rules for an implementation supporting attributes.
**** No. Attributes can be done as
attributes of subclass of CHARACTER.
Remove any description of
implementation-supported attributes.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
**** Yes.
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Proposal:
Remove CHAR-INT
**** YES
Issue: CHARACTER-TYPE-RESTRICTIVE
Define BASE-CHARACTER as a subtype of STRING.
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
**** NO.
Define (CHARACTER :STANDARD) in the same
way that STANDARD-CHAR used to be.
Define BASE-CHARACTER as
(upgraded-array-element-type '(CHARACTER :STANDARD)).
Remove the semi-standard characters.
<<You might argue that this has the same effect, but
it doesn't.>>
Issue: STRING-TYPE-RESTRICTIVE
Proposal:
Define STRING as a union type
*** YES
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
*** YES
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
*** NO. It is an error to insert an object in an
array where the object is not of the element type
of the array.
<<You might argue this has the same effect, but
my wording here is more general.>>
Extend the COERCE function to allow coercion from
base string to extended string.
*** NO. This is unnecesarry. COERCE already
coerces from one vector type to another.
Issue: STRING-TYPE-ABBREVIATIONS
Proposal:
Add BASE-STRING
Add GENERAL-STRING
*** NO. Unnecessary, confusing, clutter.
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Proposal:
Define SIMPLE-STRING as a union type
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
*** NO. Confusing. Poor performance model.
SIMPLE isn't simple.
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Proposal:
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
*** NO, even if SIMPLE-STRING-TYPE-RESTRICTIVE adopted.
Unnecessary. Useless clutter.
Issue: FILE-EXTERNAL-REPRESENTATION
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
*** NO, wrong name. Unspecified. Better to omit than to
add with unspecified or poorly specified behavior.
Better to add as "future direction" in standard than in current
state.
Issue: STRING-BINARY-WIDTH
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
*** NO, even if you meant to omit the :. CL currently doesn't
admit that text and binary can be intermixed. No standard
way to use information returned. No relation to
FILE-POSITION defined.
Issue: CHAR-CODE-NON-PORTABLE
Proposal:
Add CHAR-CCS-VALUE function
*** NO. Requires lots of implementation mechanism.
Of limited use in nearly all situations.
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Proposal:
Introduce the concept of Registries
*** IF modified; should only suggest names of
character repertoires, and name at least
STANDARD HIRAGANA KATAKANA
GREEK. Standardization of repertoire elements
to be specified in future.
Standardize on #\registry:id
*** YES, as suggestion
add all-implemented-registries
*** NO
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
*** NO
Add FIND-CHAR function
*** NO, NAME-CHAR will do
Add CHAR-LABEL function
*** NO, CHAR-NAME will do
Add CHAR-REGISTRY-NAME function
*** NO, string processing on CHAR-NAME will do
New syntax for CHARACTER type specifier
*** YES
New #\label:registry character name syntax
*** ??? This was already mentioned
New argument to CHARACTERP
*** YES.
-------
∂02-Mar-89 0928 X3J13-mailer forwarding mail from gray
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:28:08 PST
Date: Wed, 01 Mar 89 15:59:07 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890301.155907.baggins@almvma>
Subject: forwarding mail from gray
=========================================================================
Received: from dsg.csc.ti.com by ibm.COM on 03/01/89 at 10:29:25 PST
Received: from ti.com by RELAY.CS.NET id aa05395; 28 Feb 89 23:18 EST
Received: by ti.com id AA00500; Tue, 28 Feb 89 22:18:18 CST
Received: from Kelvin by tilde id AA21544; Tue, 28 Feb 89 22:08:43 CST
Message-Id: <2813717283-5615057@Kelvin>
Sender: GRAY%kelvin.csc.ti.com@RELAY.CS.NET
Date: Tue, 28 Feb 89 22:08:03 CST
From: David N Gray <Gray%dsg.csc.ti.com@RELAY.CS.NET>
To: Thom Linden <baggins@IBM.COM>
Cc: CL-Characters@SAIL.STANFORD.EDU, Bartley%mips.csc.ti.com@RELAY.CS.NET,
Waldrum%tilde.csc.ti.com@RELAY.CS.NET
Subject: Re: cs proposal straw vote
In-Reply-To: Msg of Wed, 22 Feb 89 12:08:15 PST from Thom Linden <baggins@IBM.com>
> I would like to take a straw vote on various components of
> the Characters proposal. The primary intent is to resolve the
> actual list of items to be voted upon at the March meeting.
> Let me know if you think some items should be separated or
> combined
...
> Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
> Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
> Proposal:
> Eliminate of font and bit attributes.
> Add rules for an implementation supporting attributes.
> Redefine STRING-CHAR as implementation defined.
> Remove CHAR-FONT-LIMIT
> Remove CHAR-BITS-LIMIT
> Remove INT-CHAR
> Remove CHAR-BITS
> Remove CHAR-FONT
> Remove MAKE-CHAR
> Remove CHAR-CONTROL-BIT
> Remove CHAR-META-BIT
> Remove CHAR-SUPER-BIT
> Remove CHAR-HYPER-BIT
> Remove CHAR-BIT
> Remove SET-CHAR-BIT
Yes, I can accept this.
---
> Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
> Problem: CHAR-INT behavior is CHAR-CODE unless implementation
> defined attributes are supported.
> Proposal:
> Remove CHAR-INT
I had to stop and think about why this wasn't part of the previous issue.
Perhaps the thought was that a portable way to turn all of a character into
a number (e.g. for a hash code) would be desirable even if only some
implementations support attributes? That sounds like a legitimate
concern, so I vote No.
--
> Issue: CHARACTER-TYPE-RESTRICTIVEC
> Problem: CHARACTER type doesn't allow thin & fat characters.
> Proposal: a
> Define BASE-CHARACTER as a subtype of STRING. a
> Standard characters are a subset of the base
> characters.
> STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
> Remove the semi-standard characters.
I have been unable to imagine the reason for linking semi-standard
characters with fat characters; these should be separate issues.
Yes to fat characters.
---
No to removing the semi-standard characters. I still have yet to hear a
-- plausible rationale for doing this.
> Issue: STRING-TYPE-RESTRICTIVE
> Problem: STRING type doesn't allow thin & fat strings.
> Proposal: a
> Define STRING as a union type a
> STRING used as a type specifier for object creation
> means (VECTOR CHARACTER)
> All string functions operate as specified on any a
> string object except it is an error to insert
> an extended character into a base string.
> Extend the COERCE function to allow coercion from a
> base string to extended string.
Yes.
---
> Issue: STRING-TYPE-ABBREVIATIONS
> Problem: new types are awkward to name, want abbreviations.
> Proposal: ne
> Add BASE-STRING
> Add GENERAL-STRING
Yes.
---
> Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
> Problem: SIMPLE STRING type doesn't allow thin & fat strings.
> Proposal: a
> Define SIMPLE-STRING as a union type a
> Define SIMPLE-STRING as a type specifier for object
> creation means (SIMPLE-ARRAY CHARACTER (size))
Yes.
---
> Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
> Problem: new types are awkward to name, want abbreviations.
> Proposal: ne
> Add SIMPLE-BASE-STRING
> Add SIMPLE-GENERAL-STRING
Yes.
---
> Issue: FILE-EXTERNAL-REPRESENTATION
> Problem: can't specify external encoding even when there are lots
> Proposal:
> Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Yes.
---
> Issue: STRING-BINARY-WIDTH
> Problem: Can't find out how many bytes a string will take when written as
> text
> Proposal:
> Add :EXTERNAL-CODED-STRING-LENGTH function
No; I'm not sure that this has been adequately thought out.
--
> Issue: CHAR-CODE-NON-PORTABLE
> Problem: no way to talk about well-known external coding methods, only
> internal codes
> Proposal:
> Add CHAR-CCS-VALUE function
Yes, although I'm not too happy about the name; "value" doesn't really say
--- much. Why not CHAR-CCS-INDEX ? Or CHAR-EXTERNAL-CODE ? Yes also to
the inverse function.
> Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
> Problem: Can't portably talk about non-standard characters
> Proposal:
> Introduce the concept of Registries
> Standardize on #\registry:id, add all-implemented-registries
> Add *ALL-CHARACTER-REGISTRY-NAMES* variable
> Add FIND-CHAR function
> Add CHAR-LABEL function
> Add CHAR-REGISTRY-NAME function
> New syntax for CHARACTER type specifier
> New #\label:registry character name syntax
> New argument to CHARACTERP
No. I'm not convinced that this approach is feasible or even necessary.
--- There appears to be a great deal of machinery being created solely to
support the premise stated in section 2.2 that all characters need to
be decomposable into one and only one name. I don't see the need for
that.
∂02-Mar-89 0929 X3J13-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:29:33 PST
Date: Thu, 02 Mar 89 02:20:21 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.022021.baggins@almvma>
Subject: cs proposal comments
>> But if we decide that "my alpha" _is_ the same as "your alpha", then which
>> of our languages' registry gets to include it? I can see a lot of
>> confusion over characters that are used the same in more than one
>> language.
I don't see the confusion. German, English, Italian, etc. have a large
overlap of characters. One would expect these to all be in a single
registry, eg. Latin. Again, the important factor is that a character
is uniquely named. There is no advantage of one registry over another.
>>
>> I'm not so much concerned with who decides this as with whether this
>> approach is even feasible. The lack of even a "for example" scenario of
>> how this might work leaves me with a lot of doubts about whether it _can_
>> work. Also, it is not apparent why anyone outside the Common Lisp
>> community would have any interest in participating in such a standards
>> effort.
I believe other languages have the same problems as Lisp. For example,
COBOL has standardized names for coded character sets in
their I/O interface. In particular, SC22 wants to address the
international character handling issues across all (prog.)languages.
I'm attending an SC22 ad hoc committee meeting on characters next
week (and will let this forum know what interest I find).
>>
>>
>> Page 7 of the draft dated February 21 says that
>>
>> "The proposed ISO Character Registry Standard is fixed; an
>> implementation may not extend a standard registry's constituent
>> set of characters beyond the standard definition."
>>
>> That says to me that if an implementation is going to add a character,
>> then it can only be added to an implementation-defined registry. What
>> happens then if a new edition of the registry standard includes that
>> character in one of the standard registries? Since a character is not
>> permitted to be a member of more than one registry, that immediately
>> becomes an incompatible change for anyone who has been using that
>> character. Consequently, even extensions by standards revision will be
>> discouraged. That seems quite non-extensible to me.
Nothing prevents the implementation from providing a warning message
and behaving properly for some period of time. Users are encouraged
to use a 'new' standardized name since that name has a portable
meaning.
But, what the statement says to me is that if I use a name in the
standard registry, I have a guarentee that it does not have an
implementation unique meaning. Also, it is impossible for an
implementation to add character names which conflict with any
'new' standardized character.
>>
>>
>> So CHAR< etc. have no portable meaning unless both arguments are standard
>> characters in one of the partial ordering groups on page 237 of CLtL?
>> If you are going to have a Greek alphabet that is required to be disjoint
>> from the Latin alphabet anyway, wouldn't you want to know that the Greek
>> letters could be sorted in the expected order?
Well, I don't know the 'expected' order for Greek. In general, the
expected order is culturally dependent and using CHAR< as a sorting
mechanism is not sufficient. If we take the Latin registry
as including accented characters, there are different orderings
depending on whether you are in a Spanish, German, Danish, etc.
context. For Common Lisp to impose a single one is certainly
be wrong. In general, I don't think the ordering of individual
characters by CHAR< is as important as standardized definitions
of ordering strings for culturally expected results (such as, dictionary
ordering).
>>
>> > >> Page 25 section A.4.5 doesn't specify the syntax of a registry name; did
>> > >> you intend it to be a string?
>> >
>> > These have been changed to be symbols.
>>
>> Fine, but it appears that the new draft still doesn't say that.
>>
>> > >> Page 29 - *ALL-REGISTER-NAMES* -- a list of strings?
>> >
>> > Now a list of symbols.
>>
>> Again, the document doesn't say that.
p24,26,28,33: Right. I actually said they are 'names'. This may be
too general and can be changed to 'keyword symbols' without any
difficulty.
>>
>> That sounds good, but don't we also need the inverse function, to
>> construct a character object given a CCS and index?
>>
>> >
>> > That really depends on the definition of a conforming program. Is
>> > this defined yet?
>>
>> Never mind that; the real question is why do you want the standard to not
>> specify the meaning of tabs and form-feeds in source files?
>>
I don't have my CLtL with me but I don't think a meaning is given
to the semi-standard characters (unless we consider them self defining?)
>>
>> In the character table on page 17, do the "graphic labels" have any
>> significance? I don't see that the document uses them or requires them to
>> be used in any way. If not, that column should be deleted. I hope that
>> this is _not_ an example of what character names in a registry would look
>> like.
It is simply an assist in uniquely identifing each standard character
since glyphs can be ambigious.
>>
>> Your message of January 24 said you were going to:
>>
>> -- modify char-name, name-char, and #\name to accept character
>> names of the form 'registry:label'
>>
>> but I can't see that this draft does that. In particular, it is not at
>> all apparent how this is supposed to affect CHAR-NAME. Should I expect
>> (CHAR-NAME #\NEWLINE) to return "NEWLINE" or something like
>> "CONTROL:NEWLINE"? Are #\SPACE and #\NEWLINE to be the only characters
>> that can be referenced by a name that does not included a registry prefix?
>> Since all characters will have a label in some registry, does that mean
>> that CHAR-NAME will never return NIL anymore?
The form label:registry is given on p38 where for #\, "In particular,
an implementation may support names of the form label:registry."
It could do with repeating on p35 (name-char, char-name).
If a 'control' registry is standardized, I would expect these names
to replace (eventually) the various names now used. Some revision
of the Common Lisp standard might deprecate the current forms once
(if) a Character Registry standard is adopted.
∂02-Mar-89 1000 X3J13-mailer Re: cs proposal and straw vote
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:59:49 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03605; Thu, 2 Mar 89 10:57:45 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03241; Thu, 2 Mar 89 10:57:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903021757.AA03241@defun.utah.edu>
Date: Thu, 2 Mar 89 10:57:40 MST
Subject: Re: cs proposal and straw vote
To: baggins@ibm.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Wed, 01 Mar 89 15:49:59 EST
I pretty much agree with the points Dan raised. I generally support
(with varying degrees of enthusiasm) all of the subissues except the
last one, dealing with character registries.
My major complaints at this point are:
- I also don't feel that I could vote for the document in its current
form. At the very least, there should be some kind of cross-reference
indicating which parts of the document correspond to which of the
subissues you've identified, so that we know exactly what language
we are voting on for each of them. And, I would still like to see
a rationale presented for each of the subissues.
- I really believe it would be premature to standardize on the idea of
character registries at this time. I don't think that the idea is
inherently bad and awful, but given that the specifics of the proposal
do not appear to have stabilized and nobody has implemented it yet, I
think we would be running an unacceptable risk of standardizing the
wrong thing.
A few other nits:
I'm confused about what happens to the STRING-CHAR type. There is a
definition for it on page 22 but on the bottom of page 23 it is
removed from the table of standard type specifiers. And, which
subissue would removing it fall under? It's not mentioned in any of
the ones you list.
On page 28, it says: "There may be unassigned codes between 0 and
char-code-limit which are not legal arguments to code-char." Don't
you really mean to say "... for which code-char returns NIL"?
Why do we need CHAR-CODE-LIMIT, CODE-CHAR, and CHAR-CODE anyway?
While bits and fonts were in the standard, these were useful for
things like creating a character with the same code but different bits
or font attributes, but now that's out. If we want a function to use
for hashing characters, that's what CHAR-INT is for. The only other
use I can think of is supporting iteration over characters, and it
seems like this could be extremely inefficient in implementations that
support user-defined character sets. (In such a case, I would imagine
that one would make CHAR-CODE-LIMIT correspond to the limit imposed by
the representation, perhaps the same as MOST-POSITIVE-FIXNUM, but in
actual practice, very few of those codes would have corresponding
characters.) I agree with Dan that we'd be better off having a
specialized iterator.
Should we consider extending MAKE-STRING-OUTPUT-STREAM to take an
:ELEMENT-TYPE keyword?
-Sandra
-------
∂02-Mar-89 0905 X3J13-mailer Section 2.2 - part 5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:05:12 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05377; Thu, 2 Mar 89 09:03:02 PST
Message-Id: <8903021703.AA05377@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05377; Thu, 2 Mar 89 09:03:02 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 07:42
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 5
%% 2.8.0 1
\beginsubsubsection{\datatype Package}
An {\word object} of type {\datatype package} (a {\datatype package})
is a namespace that holds collections
of {\datatype symbols\/}.
%% 10.0.0 7
%% 11.0.0 4
A {\datatype package} is a data structure
that establishes a mapping from print
names to {\datatype symbols}.
At any given time one
{\datatype package}
is current. The current {\datatype package} is
the one that is the
value of @var[package]\rm. It is possible to refer to
{\datatype symbols} in
{\datatype packages}
other than the current one through the use of
package qualifiers in the representation of the {\datatype symbol}.
%% 11.0.0 5
The mappings in a {\datatype package} are divided
into two classes, external and internal. The
{\datatype symbols} accessible via these different mappings are
called external and
internal {\datatype symbols}
of the {\datatype package}. Within a
{\datatype package},
a print name refers to one {\datatype symbol} or to none; if it does refer
to a {\datatype symbol}, then it is either external or internal in that
{\datatype package}, but not both.
%% 11.0.0 6
External {\datatype symbols} are part of the package's public interface to other
{\datatype packages}.
{\datatype Symbols} become external
if they appear in {\function export}.
%% 11.0.0 7
A {\datatype symbol}
will always have the same
print name no matter what {\datatype package}
it appears in, but it may be external in some {\datatype
packages}
and internal in others.
A {\datatype symbol}
will not necessarily always have the same
printed representation because of the presence of package qualifiers ({\tt
:} and {\tt ::}).
%% 11.0.0 9
{\datatype Packages}
may be built up in layers. From the point of view of a
{\datatype package's} user,
the {\datatype package} is a single collection of mappings from
{\datatype strings} into internal and external {\datatype symbols}.
However, some of these
mappings may be established within the package itself, while other
mappings are inherited from other packages via {\function use-package}.
A {\datatype symbol} is
accessible in a {\datatype package} if it can be referred to
without a package qualifier when that {\datatype package} is current,
regardless of whether the mapping occurs within
that {\datatype package}
or via inheritance. A {\datatype symbol} is
present in a {\datatype package}
if the mapping is in the {\datatype package} itself and is
not inherited from somewhere else.
%% 5.1.2 6
%% 11.3.0 5
The {\datatype package}
named @f[keyword] contains all keyword {\datatype symbols}
used by the
@clisp\ system and by user-written code. Such {\datatype symbols} must be
easily accessible from any {\datatype package};
name conflicts are not an issue
because these {\datatype symbols\/}
are used only as labels, not to carry package-specific
attributes.
When a {\datatype symbol} is added to the @f[keyword] package, it
is made external, declared to be a constant, and is
made to
have itself as its value.
%% 11.0.0 19
Each {\datatype package} has a name (a {\datatype string})
and perhaps some nicknames. These
are assigned when the {\datatype package} is created
and can be changed
later.
%% 11.0.0 20
There is a single namespace for {\datatype packages}.
The function @Funref[find-package] translates a package
name or nickname into the
associated {\datatype package}.
The function @Funref[package-name] returns the name of a
{\datatype package}.
The function @Funref[package-nicknames] returns a {\datatype list} of all
nicknames for a {\datatype package}.
@Funref[rename-package] removes a
{\datatype package's}
current name and nicknames and replaces them with new ones
specified by the caller.
%% 11.0.0 35
{\datatype Symbols} from one {\datatype package}
may be made accessible in another {\datatype package} in
two ways.
%% 11.0.0 36
\beginlist
\itemitem{--}
Any individual {\datatype symbol}
may be added to a {\datatype package} by use
of @Funref[import]\rm. After the call to
{\function import}
it is possible to refer to the {\datatype symbols}
in the importing package
without any qualifier. The status of the {\datatype symbol}
in the {\datatype package}
it came from
is unchanged, and home package
for
this {\datatype symbol } is unchanged.
Once imported, a {\datatype symbol} is present in the
importing package
and can be removed only by calling {\function unintern}.
%% 11.4.0 4
A {\datatype symbol} is shadowed by another {\datatype symbol} in
some {\datatype package}
if the first {\datatype symbol} would be accessible by inheritance
if not for the presence of the second {\datatype symbol}.
The function @Funref[shadowing-import] causes the first {\datatype symbol}
to be imported without error
even if the second {\datatype symbol} is accessible.
%% 11.4.0 39
%% 11.4.0 40
\itemitem{--}
The second mechanism for making symbols from one package accessible in another
is provided by @Funref[use-package]\rm.
The function {\function unuse-package}
undoes the effects of a previous {\function use-package}.
\endlist
%% 11.4.0
There is no way to inherit the internal {\datatype symbols}
of another {\datatype package};
to refer to an internal {\datatype symbol},
the {\datatype symbol's} home
package must be made current,
a qualifier must be used, or the {\datatype symbol}
must be imported into the current
{\datatype package}.
%% 11.4.0 8
When a {\datatype symbol} is to be located in a
given {\datatype package}
the following occurs:
\beginlist
\itemitem{--} The {\datatype symbol} is looked for among the external and
internal {\datatype symbols} of the
{\datatype package} itself.
\itemitem{--} The
external {\datatype symbols} of the used {\datatype packages} are looked through
in some unspecified order. The
order does not matter; see the rules for handling name
conflicts listed below.
\endlist
%% 11.0.0 46
Within one {\datatype package}
any particular print name can refer to at most
one {\datatype symbol}. A name conflict
is said to occur when there is more than one candidate {\datatype symbol}.
Any time
a name conflict is about to occur,
a continuable error is signalled.
The following rules apply to name conflicts:
%% 11.0.0 47
\beginlist
%% 11.0.0 49
\itemitem{--}
Name conflicts are detected when they become possible, that is, when the
package structure is altered. Name
conflicts are not checked for during every name lookup.
\itemitem{--}
If the same {\datatype symbol}
is accessible to a {\datatype package} through more than
one path, there is no name conflict.
The same identical {\datatype symbol} cannot conflict with itself.
Name conflicts occur only between distinct {\datatype symbols} with
the same print name.
%% 11.0.0 48
\itemitem{--} Every {\datatype package} has a
list of shadowing {\datatype symbols}.
A shadowing {\datatype symbol} takes precedence over any
other {\datatype symbol} of the same print name
that would otherwise be accessible in the
{\datatype package}.
A name conflict involving a shadowing symbol is always
resolved in favor of the shadowing {\datatype symbol},
without signalling an error
(except for one exception involving {\function import}).
See @Funref[shadow] and @Funref[shadowing-import]\rm.
%% 11.0.0 50
\itemitem{--}
The functions {\function use-package}, {\function import}, and {\function export}
check for name
conflicts.
%% 11.0.0 52
\itemitem{--}
{\function shadow} and {\function shadowing-import}
never signal a name-conflict error.
%% 11.0.0 53
\itemitem{--}
{\function unuse-package}, {\function unexport}, and {\function unintern}
(when the {\datatype symbol}
being
uninterned is not a shadowing symbol) do not need to do any
name-conflict checking.
%% 11.0.0 54
\itemitem{--}
Giving a shadowing symbol to {\function unintern}
can uncover a name conflict that had
previously been resolved by the shadowing.
%% 11.0.0 55
\itemitem{--}
Aborting from a name-conflict error leaves the original {\datatype symbol}
accessible.
\itemitem{--}
Package functions signal name-conflict errors before making any
change to the package structure. When multiple changes are to be made,
it is
permissible for the implementation to process each change separately,
so that aborting from a name
conflict caused by the second {\datatype symbol}
in the {\datatype list} will not unexport the
first {\datatype symbol} in the {\datatype list}.
Multiple changes could be made with {\function export}.
%% 11.0.0 56
\itemitem{--}
Continuing from a name-conflict error should offer the user a chance to
resolve the name conflict in favor of either of the candidates. The
{\datatype package}
structure should be altered to reflect the resolution of the
name conflict, via {\function shadowing-import},
{\function unintern}, or {\function unexport}.
%% 11.0.0 57
\itemitem{--}
A name conflict in {\function use-package}
between a {\datatype symbol} directly present in the
using {\datatype package}
and an external {\datatype symbol} of the used
{\datatype package} is resolved
in favor of the first {\datatype symbol}
by making it a shadowing {\datatype symbol}, or in favor
of the second {\datatype symbol}
by uninterning the first {\datatype symbol} from the using
{\datatype package}.
%% 11.0.0 60
\itemitem{--}
A name conflict in {\function export} or {\function unintern}
due to a {\datatype package's}
inheriting two distinct {\datatype symbols}
with the same print name from two other
{\datatype packages}
may be resolved in favor of either {\datatype symbol} by importing it into
the using {\datatype package}
and making it a shadowing symbol, just as with
{\function use-package}.
\endlist
%% 11.2.0 5
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable
to {\datatype packages}.
For the {\word operators} listed here, all optional arguments named
{\arg package} default to the current value of @var[package]\rm. Where an
{\word operator}
takes an argument that is either a {\datatype symbol} or a {\datatype list}
of {\datatype symbols},
an argument of @false\ is treated as an empty {\datatype list} of
{\datatype symbols}. Any {\arg package}
argument may be either a {\datatype string}, a {\datatype symbol}, or
a {\datatype package}.
If a {\datatype symbol}
is supplied, its print name will be used as the {\datatype package}
name.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[package] & {\tt make-package} & {\tt in-package} \cr
{\tt find-package }&{\tt package-name }&{\tt package-nicknames }\cr
{\tt rename-package }&{\tt package-use-list }&{\tt package-used-by-list }\cr
{\tt package-shadowing-symbols }&{\tt list-all-packages }&{\tt intern }\cr
{\tt find-symbol }&{\tt unintern }&{\tt export }\cr
{\tt unexport }&{\tt import }&{\tt shadowing-import }\cr
{\tt shadow }&{\tt use-package }&{\tt unuse-package }\cr
{\tt find-all-symbols }&{\tt do-symbols }&{\tt do-external-symbols }\cr
{\tt do-all-symbols }&{\tt modules }&{\tt provide }\cr
{\tt require }& & \cr
\noalign{\vskip -9pt}
}}
\caption{Package tools}
\endfig
%% 11.6.0 1
The following packages, at least, are built into every @clisp\ system:
%% 11.6.0 2
\beginlist
\itemitem{\tt lisp}
%% clean-up issue `contains all and only'
The package named @f[lisp] contains the primitives of the
@clisp\ system. Its external symbols include all of the
user-visible functions and global variables that are present in the
@clisp\ system, such as {\function car}, {\function cdr}, @var[package]\rm, etc.
%% 11.6.0 3
\itemitem{\tt user}
%% clean-up issue `lisp package and may use other packages as well'
The @f[user] package is the value of @var[package] when
a @clisp\ system starts up. This package uses the @f[lisp] package.
%% 11.6.0 4
\itemitem{\tt keyword}
This package contains all of the keywords used by built-in
or user-defined @xlisp\ functions. Printed symbol representations
that start with a colon are interpreted as referring to symbols
in this package, which are always external symbols. All symbols in this
package are treated as constants that evaluate to themselves.
The function {\function symbol-value} may be used to retrieve these values.
%% 11.6.0 5
\itemitem{\tt system}
This package name is reserved to the implementation,
uses the @f[lisp] package, and has the
nickname @f[sys]\rm.
\endlist
\beginsubsubsection{\datatype Pathname}
%% 23.1.1 1
All file systems dealt with by @clisp\ are forced into a common framework
in which files are named by an object of type {\datatype pathname},
a {\datatype pathname},
that can be translated by the underlying operating system to a file
name.
%% 23.1.1 3
A {\datatype pathname} always has six components, described below.
These components
are the common interface that allows programs to work the same way with
different file systems; the mapping of the pathname components into the
concepts peculiar to each file system is
implementation-dependent.
%% 23.1.1 4
\beginlist
%% 23.1.1 5
%% 23.1.1 17
\itemitem{\bf Host}
The name of the file system on which the file resides.
The host may be a
{\datatype string}, indicating a file system, or a
{\datatype list}
of {\datatype strings},
of which the first names the file system and the rest
may be used for inter-network routing.
\itemitem{\bf Device}
Corresponds to the ``device'' or ``file structure'' concept in many
host file systems: the name of a (logical or physical) device containing files.
%% 23.1.1 6
\itemitem{\bf Directory}
Corresponds to the ``directory'' concept in many host file systems:
the name of a group of related files.
%% 23.1.1 7
\itemitem{\bf Name}
The name of a group of files that can be thought of as
conceptually the ``same'' file.
%% 23.1.1 8
%% 23.1.1 15
\itemitem{\bf Type}
Corresponds to the ``filetype'' or ``extension'' concept in many host
file systems. This says what kind of file this is.
The type is always a {\datatype string}, @nil\ or {\keyword :wild}.
When the type is not supplied, its value is implementation-dependent.
%% 23.1.1 9
%% 23.1.1 16
\itemitem{\bf Version}
Corresponds to the ``version number'' concept in many host file systems.
The version is either a positive {\datatype integer}
or a {\datatype symbol } from the following list:
{\function nil}, {\keyword :wild}, or
{\keyword :newest} (refers to the largest version number
that already exists in the file system when reading a file, or to
a version number
greater than any already existing in the file system
when writing a new file). Implementations
may define other special version {\datatype symbols}.
\endlist
The following rules apply to the components of a {\datatype pathname}.
%% 23.1.1 12
\beginlist
\itemitem{--}
Not all of the components of a {\datatype pathname}
need to be supplied. If a
component of a {\datatype pathname}
is missing, its value is @nil\rm. Before the file
system interface can do anything with a file, such as opening the
file, all the missing components of a {\datatype pathname} must be filled in
from a set of defaults.
Parsing a namestring
that does not contain certain components will result in a
{\datatype pathname} with
missing components.
%% 23.1.1 13
\itemitem{--}
A component of a {\datatype pathname} can also be the keyword {\keyword
:wild},
which means that the {\datatype pathname}
component matches anything.
%% 23.1.1 14
\itemitem{--}
Except where otherwise specified, the values
for components of a {\datatype pathname} are
implementation-dependent.
%% 23.1.1 18
\itemitem{--}
The device, directory, and name components can each be a {\datatype string}
(with
implementation-dependent rules on allowed characters and length) or possibly
some other @clisp\ {\word object}
which has an implementation-dependent format.
Supplying a {\datatype string}
as a pathname component for a host that requires an {\word object} as a
component will cause conversion of the {\datatype string} to the appropriate
{\word object}.
\endlist
%% 23.1.1 10
A {\datatype pathname}
is not necessarily the name of a specific file.
Rather, it is a specification (possibly only a partial specification) of
how to access a file.
A {\datatype pathname}
need not correspond to any file that
actually exists, and more than one {\datatype pathname}
can refer to the same file.
For example, the {\datatype pathname}
with a version of {\keyword :newest} may refer to the
same file as a {\datatype pathname}
with the same components except a certain number
as the version. Indeed, a {\datatype pathname}
with version {\keyword :newest} may refer to
different files as time passes, because the meaning of such a {\datatype
pathname}
depends on the state of the file system.
%% 23.1.1 11
{\datatype Pathnames} that are specified by {\datatype strings}
(called namestrings) are parsed and
merged. Parsing is the conversion of a namestring
into a {\datatype pathname}. This operation is
implementation-dependent, because the format of namestrings
is implementation-dependent.
Merging takes a {\datatype pathname} with missing components
and supplies values for those components from a source of defaults.
%% 23.1.1 20
An implementation is free to accommodate other file system features in its
{\datatype pathname} representation and provide a parser that can process such
specifications in namestrings. A program that
depends explicitly on any such features will not be portable.
The following figures contain lists of {\word tools} that are applicable to the
file system interface.
Figure {\chapno--\the\capno} lists the {\datatype pathname} {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt pathname }&{\tt truename }&{\tt parse-namestring }\cr
{\tt merge-pathnames }& @var[default-pathname-defaults]&{\tt make-pathname }\cr
{\tt pathnamep }&{\tt pathname-host }&{\tt pathname-device }\cr
{\tt pathname-directory }&{\tt pathname-name }&{\tt pathname-type }\cr
{\tt pathname-version }&{\tt namestring }&{\tt file-namestring }\cr
{\tt directory-namestring }&{\tt host-namestring }&{\tt enough-namestring }\cr
{\tt user-homedir-pathname } & & \cr
\noalign{\vskip -9pt} }}
\caption{File System Interface tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the file and directory {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt directory} &{\tt open }&{\tt with-open-file }\cr
{\tt rename-file }&{\tt delete-file }&{\tt probe-file }\cr
{\tt file-write-date }&{\tt file-author }&{\tt file-position }\cr
{\tt file-length} & {\tt load} & @var[load-verbose] \cr
\noalign{\vskip -9pt} }}
\caption{File System Interface tools - 2}
\endfig
%% 2.11.0 1
\beginsubsubsection{\datatype Random-state}
An {\word object} of type {\datatype random-state} (a {\datatype random-state}
object)
contains state information used by the pseudo-random number generator.
%% 12.9.0 1
The pseudo-random numbers
in a random number series are implementation-dependent,
but the distribution of the numbers should
be machine-independent.
Figure {\chapno--\the\capno} lists
the {\word tools} that are applicable to {\datatype random-state}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt random} & @var[random-state] & \cr
{\tt make-random-state} & {\tt random-state-p} & \cr
\noalign{\vskip -9pt}
}}
\caption{Random-state tools}
\endfig
\issue{FUNCTION-TYPE:X3J13-MARCH-88}
\beginsubsubsection{\datatype Function}
An {\word object} of type {\datatype function\/} is called a {\datatype
function}.
A {\datatype function}
may be supplied as an argument without error to @Funref[funcall]
or @Funref[apply]\rm, and is
to be executed as code when arguments are supplied.
The functional computation produces one or more values, produces no
values, or
takes a non-local exit.
The type {\datatype function} has at least one {\word subtype} called
{\datatype compiled-function}.
Implementations are free to define other {\word subtypes} of
the type {\datatype function}.
\beginsubsubsection{\datatype Compiled-function}
An object of type {\datatype compiled-function} is a called a {\datatype
compiled-function}.
%% 2.13.0 2
A {\datatype compiled-function} is a compiled code {\word object}
that has been produced by the
compiler.
\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
\beginsubsubsection{\datatype Nil}
The empty data type, which contains no {\word objects}, is
denoted by @nil\rm.
\beginsubsubsection{\datatype Common}
The type {\datatype common} encompasses all the
{\word objects} required by the @clisp\ language. An implementation
is free to provide other
{\word types} that are not {\word subtypes} of the type {\datatype common}.
\endsubSection%{Data Type Definition}
%% Type Specifiers
\beginsubSection{Type Specifiers}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
%% 4.5.0 5
Type specifiers are used for two different purposes:
declaration and discrimination.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
There are two reasons that an {\word object}'s type is used:
\beginlist
\itemitem{1.} The consequences are undefined if an
{\word object} is an argument to an {\word operator}
and the argument
is not one of the {\word operator}'s required {\word types}.
\itemitem{2.} If run-time optimizations in compiled code are desired,
it is often necessary to reduce the number of {\word types} of {\word objects}
a variable can hold.
\endlist
%% 4.1.0 1
The type specifiers (they are {\datatype symbols})
defined by the system are those shown in Figure
{\chapno--\the\capno}.
%% 4.3.0 4
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt array}&{\tt integer}&{\tt short-float}\cr
{\tt atom}&{\tt keyword}&{\tt signed-byte}\cr
{\tt bignum}&{\tt list}&{\tt simple-array}\cr
{\tt bit}&{\tt long-float}&{\tt simple-bit-vector}\cr
{\tt bit-vector}&{\tt mod}&{\tt simple-string}\cr
{\tt character}&{\tt nil}&{\tt simple-vector}\cr
{\tt common}&{\tt null}&{\tt single-float}\cr
{\tt compiled-function}&{\tt number}&{\tt standard-char}\cr
{\tt complex}&{\tt package}&{\tt stream}\cr
{\tt cons}&{\tt pathname}&{\tt string}\cr
{\tt double-float}&{\tt random-state}&{\tt string-char}\cr
{\tt fixnum}&{\tt ratio}&{\tt symbol}\cr
{\tt float}&{\tt rational}&{\tt t}\cr
{\tt function}&{\tt readtable}&{\tt unsigned-byte}\cr
{\tt hash-table}&{\tt sequence}&{\tt vector}\cr
\noalign{\vskip -9pt} }}
\caption{Table of Atomic Type Specifiers}
\endfig
The syntax for type specifiers is illustrated in Figure {\chapno--\the\capno}.
\boxfig
{\advance\baselineskip by 2.5pt
\halign{\hskip\leftskip\hfil#&#\hfil\cr
{\it typespec\/}::$=\;$&{\it atomic-type-specifier\/}\cr
$\vert\;$& \paren {{\tt satisfies} predicate-name\/}\cr
$\vert\;$& \paren {{\tt member} \star{\curly{object}}}\cr
$\vert\;$& \paren {{\tt not} typespec\/}\cr
$\vert\;$& \paren {{\tt and} \star{\curly{typespec}}}\cr
$\vert\;$& \paren {{\tt or} \star{\curly{typespec}}}\cr
$\vert\;$& \paren {{\tt array} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{dimensions}}}}\cr
$\vert\;$& \paren {{\tt simple-array} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{dimensions}}}}\cr
$\vert\;$& \paren {{\tt vector} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{\curly{size $\vert$ {\tt *}}}}}}\cr
$\vert\;$& \paren {{\tt simple-vector} \ttbrac{\it size\/}}\cr
$\vert\;$& \paren {{\tt string} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt simple-string} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt bit-vector} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt simple-bit-vector} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt integer} \ttbrac{integer-limit \brac{integer-limit}}}\cr
$\vert\;$& \paren {{\tt fixnum} \ttbrac{fixnum-limit \brac{fixnum-limit}}}\cr
$\vert\;$& \paren {{\tt mod} \ttbrac{\it integer\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt signed-byte} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt unsigned-byte} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt rational} \ttbrac{rational-limit \brac{rational-limit}}}\cr
$\vert\;$& \paren {{\tt float} \ttbrac{float-limit \brac{float-limit}}}\cr
$\vert\;$& \paren {{\tt short-float} \ttbrac{short-float-limit \brac{short-float-limit}}}\cr
$\vert\;$& \paren {{\tt single-float} \ttbrac{single-float-limit \brac{single-float-limit}}}\cr
$\vert\;$& \paren {{\tt double-float} \ttbrac{double-float-limit \brac{double-float-limit}}}\cr
$\vert\;$& \paren {{\tt long-float} \ttbrac{long-float-limit \brac{long-float-limit}}}\cr
$\vert\;$& \paren {{\tt complex} \ttbrac{typespec $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt function} \ttbrac{arg-typespec-list \brac{value-typespec}}}\cr
}}
\caption{Syntax for Type Specifiers}
\endfig
Figure {\chapno--\the\capno} gives the definitions
applicable to the syntax for type specifiers.
\boxfig
{\advance\baselineskip by 2.5pt
\halign{#\hfil&#\hfil\cr
{\it arg-typespec-list\/}::$=$ \vtop{\hbox{\star{(\curly{typespec}}
\ttbrac{{\opt} {\star{\curly{typespec\/}}}}
\ttbrac{{\rest} {\it typespec\/}}
\hbox{\quad\ttbrac{{\key{}} \star{\curly{\it typespec\/}}}{\rm )}}}} & \cr
{\it value-typespec\/}::$=$ {\it typespec\/} $\vert$ \paren{{\tt values} . {\it arg-typespec-list\/}} & \cr
{\it dimensions\/}::$=$ {\it integer\/} $\vert$ {\tt *} $\vert$
\paren{\star{\curly{integer $\vert$ {\tt *} }}} & \cr
{\it size\/}::$=$ {\it integer\/} & \cr
{\it integer-limit\/}::$=$ {\it integer\/} $\vert$ {\tt *}
$\vert$ ({\it integer\/}) & \cr
{\it fixnum-limit\/}::$=$ {\it fixnum\/} $\vert$ {\tt *}
$\vert$ ({\it fixnum\/}) &\cr
{\it rational-limit\/}::$=$ {\it rational\/} $\vert$ {\tt *} $\vert$ ({\it rational\/})\cr
{\it float-limit\/}::$=$ {\it float\/} $\vert$ {\tt *} $\vert$ ({\it float\/})\cr
{\it short-float-limit\/}::$=$ {\it short-float\/} $\vert$ {\tt *} $\vert$ ({\it short-float\/})\cr
{\it single-float-limit\/}::$=$ {\it single-float\/} $\vert$ {\tt *} $\vert$ ({\it single-float\/})\cr
{\it double-float-limit\/}::$=$ {\it double-float\/} $\vert$ {\tt *} $\vert$ ({\it double-float\/})\cr
{\it long-float-limit\/}::$=$ {\it long-float\/} $\vert$ {\tt *} $\vert$ ({\it long-float\/})\cr
}}
\caption{Definitions for Syntax for Type Specifiers}
\endfig
%% 4.2.0 1
If a type specifier is a {\datatype list}, the {\word car}
of the {\datatype list}
is a {\datatype symbol}, and the rest of the {\datatype list}
is subsidiary
{\word type} information. The subsidiary items may be
unspecified. The unspecified subsidiary items are indicated
by writing @f[*]\rm. For example, to completely specify
a {\datatype vector}, the {\word type} of the elements
and the length of the {\datatype vector}, must be present.
@lisp
(vector double-float 100)
@endlisp
To leave the length unspecified:
@lisp
(vector double-float *)
@endlisp
To leave the element type unspecified:
@lisp
(vector * 100)
@endlisp
Suppose that two type specifiers are the same except that the first
has a @f[*] where the second has a more explicit specification.
Then the second denotes a {\word subtype}
of the {\word type} denoted by the first.
%% 4.2.0 2
If a {\datatype list}
has one or more unspecified items at the end, those items
may be dropped.
If dropping all occurrences of @f[*] results in a singleton {\datatype list},
then the parentheses may be dropped as well (the list may be replaced
by the {\datatype symbol} in its {\word car}).
For example,
{\tt (vector double-float *)}
may be abbreviated to {\tt (vector double-float)},
and {\tt (vector * *)} may be abbreviated to {\tt (vector)}
and then to
{\tt vector}.
A list of possible type specifier {\datatype lists} follows:
\beginlist
%% 4.3.0 1
\itemitem
{\tt (satisfies {\arg predicate-name})}
This denotes
the set of all {\word objects}
that satisfy the predicate {\arg predicate-name},
which must be a {\datatype symbol}
whose global {\word function} definition is a one-argument
predicate.
A name is required for {\arg predicate-name}; {\word lambda-expressions}
are not allowed.
For example, the type {\tt (satisfies numberp)} is the
same as the type {\datatype number}.
The call {\tt (typep x '(satisfies p))}
results in applying @f[p] to @f[x]
and returning @f[t] if the result is true and @nil\ if the result is false.
%% 4.3.0 2
For example, the type {\datatype string-char} could be defined as
@lisp
(deftype string-char () '(and character (satisfies string-char-p)))
@endlisp
%% 4.4.0 3
\itemitem
{\tt (member {\arg object1} {\arg object2} ...)}
This denotes the set
containing the named {\arg objects}. An {\word object} is of
this {\word type}
if and only if it is @Funref[eql] to one of the specified {\arg objects}.
%% 4.4.0 4
\itemitem
{\tt (not {\arg type})}
This denotes the set of all {\word objects} that
are not of the type {\arg type}.
%% 4.4.0 5
\itemitem{\tt (and {\arg type1} {\arg type2} ...)}
This denotes the set of all {\word objects} of the
{\word type} determined by the intersection of
{\arg type1}, {\arg type2},....
%% 4.4.0 7
\itemitem{\tt (or {\arg type1} {\arg type2} ...)}
This denotes the set of all {\word objects} of the
{\word type} determined the union of {\arg type1}, {\arg type2},....
For example, the type {\datatype list}
by definition is the same as
{\tt (or null cons)}. Also, the value
returned by
@Funref[position] is of type {\tt (or null (integer 0 *))}
(either @nil\ or a non-negative {\datatype integer}).
%% 4.6.0 3
\itemitem{\tt (integer {\arg low} {\arg high})}
This denotes the {\datatype integers} between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be {\datatype integers}, a {\datatype list}
of an {\datatype integer}, or unspecified.
An {\datatype integer} is an inclusive limit,
a {\datatype list} of an {\datatype integer} is an exclusive limit, and
@f[*] means that a limit does not exist
and so effectively denotes minus or plus infinity, respectively.
{\datatype Fixnum} is a name
for {\tt (integer {\arg smallest} {\arg largest})}
for implementation-dependent
values of {\arg smallest} and {\arg largest}.
The type {\tt (integer 0 1)}
has the name {\datatype bit}.
%% 4.6.0 4
\itemitem{\tt (mod {\arg n})}
This denotes the set of non-negative {\datatype integers} less than {\arg
n}.
This is equivalent to {\tt (integer 0 {\it n}-1)}
or to {\tt (integer 0 ({\it n}))}.
%% 4.6.0 5
\itemitem{\tt (signed-byte {\arg s})}
This denotes the set of {\datatype integers} that can be represented
in two's-complement form in a byte of {\arg s} bits. This is
equivalent to
{\tt (integer $-2↑{s-1} 2↑{s-1}-$1)}.
The type {\datatype signed-byte} or the type {\tt (signed-byte *)}
is the same as the type {\datatype integer}.
%% 4.6.0 6
\itemitem{\tt (unsigned-byte {\arg s})}
This denotes the set of non-negative {\datatype integers} that can be
represented in a byte of {\arg s} bits. This is equivalent to
{\tt (mod $2↑s$)},
that is, {\tt (integer 0 $2↑s-$1)}.
The type {\datatype unsigned-byte} or
the type {\tt (unsigned-byte *)} is the same as
the type {\tt (integer 0 *)}, the set of non-negative {\datatype integers}.
%% 4.6.0 7
\itemitem{\tt (rational {\arg low} {\arg high})}
This denotes the {\datatype rationals} between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be a {\datatype rational}, a {\datatype list} of a {\datatype
rational}, or unspecified.
A {\datatype rational} is an inclusive limit,
a {\datatype list} of a {\datatype rational} is an exclusive limit, and
@f[*] means that a limit does not exist
and so denotes minus and plus infinity, respectively.
%% 4.6.0 8
%% 4.6.0 9
\itemitem{\tt (float {\arg low} {\arg high})}
\itemitem{\tt (short-float {\arg low} {\arg high})}
\itemitem{\tt (single-float {\arg low} {\arg high})}
\itemitem{\tt (double-float {\arg low} {\arg high})}
\itemitem{\tt (long-float {\arg low} {\arg high})}
These denote the set of {\datatype floating}-point numbers between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be a {\datatype floating}-point number,
a {\datatype list} of a {\datatype floating}-point number,
or unspecified. A {\datatype floating}-point number
is an inclusive limit, a {\datatype list} of a
{\datatype floating}-point number is an exclusive limit, and
@f[*] means that a limit does not exist
and so denotes minus and plus infinity, respectively.
In the case of the types {\tt short-float}, {\tt single-float},
{\tt double-float}, or {\tt long-float},
if a limit is a {\datatype floating}-point
number (or a {\datatype list} of one),
it must be one of the appropriate format.
%% 4.6.0 10
\itemitem{\tt (string {\arg size})}
This denotes the same type as
the type {\tt (array string-char ({\arg size}))}:
the set of {\datatype strings} of size {\arg size}.
%% 4.6.0 11
\itemitem{\tt (simple-string size {\arg size})}
This denotes the same type
as the type {\tt (simple-array string-char ({\arg size}))}: the set of
{\datatype simple-strings} of size {\arg size}.
%% 4.6.0 12
\itemitem{\tt (bit-vector {\arg size})}
This denotes the same type as the type {\tt (array bit ({\arg size}))}:
the set of {\datatype bit-vectors} of size {\arg size}.
%% 4.6.0 13
\itemitem{\tt (simple-bit-vector {\arg size})}
This denotes the same type as the type
{\tt (simple-array bit ({\arg size}))}: the set of
{\datatype simple-bit-vectors} of size {\arg size}.
%% 4.5.0 6
%% 4.5.0 7
\itemitem{\tt (array {\arg element-type dimensions})}
This denotes the set
of {\datatype arrays\/}
whose elements are all of type {\arg element-type}
and whose dimensions are {\arg dimensions}.
{\arg Element-type} must be a valid type specifier or unsupplied.
{\arg Dimensions} must be a non-negative {\datatype integer},
which is the number
of dimensions, or a {\datatype list} of non-negative {\datatype integers}
representing the length of each dimension (any dimension
may be unsupplied instead), or it may be unsupplied.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be left out:
For declaration purposes, this {\word type} encompasses those
{\datatype arrays\/}
that can result by supplying {\arg element-type} as the element type
to the function @Funref[make-array]\rm; this may be different
from what the {\word type} means for discrimination purposes.
For example:
@lisp
(array integer 3) ;Three-dimensional arrays of integers
(array integer (* * *)) ;Three-dimensional arrays of integers
(array * (4 5 6)) ;4-by-5-by-6 arrays
(array character (3 *)) ;Two-dimensional arrays of characters that have
;three rows
(array short-float @empty) ;Zero-rank arrays of short-floats
@Endlisp
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (array *)} refers to all {\datatype arrays\/}
regardless of element type, {\tt (array {\arg type-specifier})}
refers only to those {\datatype arrays\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
Note that the type {\tt (array t)}
is a subset of the type {\tt (array *)}.
The reason is that the type {\tt (array t)} is the set of {\datatype arrays\/}
that can
hold any {\word object} (the elements are of type
{\datatype t},
which includes all {\word objects}).
On the other hand, the type {\tt (array *)}
is the set of all {\datatype arrays\/} whatsoever, including for example
{\datatype arrays\/} that can hold only {\datatype characters}.
Now
the type {\tt (array character)} is not a subset of the type {\tt (array t)};
the two sets
are {\word disjoint} because the type {\tt (array character)} is not the
set of all {\datatype arrays\/} that can hold
{\datatype characters}, but rather the set of
{\datatype arrays\/}
that are specialized to hold precisely {\datatype characters} and no
other {\word objects}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
The following expression cannot be used to determine if
array @f[foo] can hold a {\datatype character}:
@lisp
(typep foo '(array character))
@endlisp
The following expression can be used to determine if
array @f[foo] can hold a {\datatype character}:
@lisp
(subtypep 'character (array-element-type foo))
@endlisp
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 8
\itemitem{\tt (simple-array {\arg element-type dimensions})}
This is equivalent
to the type {\tt (array {\arg element-type} {\arg dimensions})}
except that it additionally
specifies that the {\datatype array\/}
{\word objects} are {\datatype simple-arrays}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (simple-array *)} refers to all {\datatype simple-arrays\/}
regardless of element type, {\tt (simple-array {\arg type-specifier})}
refers only to those {\datatype simple-arrays\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 9
\itemitem{\tt (vector {\arg element-type} {\arg size})}
This denotes the set of specialized
one-dimensional {\datatype arrays\/}
whose elements are all of type {\arg element-type}
and whose lengths are size {\arg size}. This is equivalent to
the type {\tt (array {\arg element-type} ({\arg size}))}.
For example:
@lisp
(vector double-float) ;Vectors of double-format floating-point numbers
(vector * 5) ;Vectors of length 5
(vector t 5) ;General vectors of length 5
(vector (mod 32) *) ;Vectors of integers between 0 and 31
@Endlisp
The types {\tt (vector string-char)} and {\tt (vector bit)}
have the names {\datatype string} and {\datatype bit-vector}.
Every implementation of @clisp\ must provide distinct representations for
these as distinct specialized {\word types}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (vector *)} refers to all {\datatype vectors\/}
regardless of element type, {\tt (vector {\arg type-specifier})}
refers only to those {\datatype vectors\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 10
\itemitem{\tt (simple-vector {\arg size})}
This is the same
as the type {\tt (vector t {\arg
size})} except that it additionally specifies
that its elements are {\datatype simple-vectors}.
%% 4.5.0 11
\itemitem{\tt (complex {\arg type})}
Every element of this {\word type} is a
{\datatype complex\/} number whose real part
and imaginary part are each of type {\arg type}.
This {\word type} encompasses those
{\datatype complex\/} numbers
that can result by giving numbers of the specified {\word type}
to @Funref[complex]\rm.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
This may be different
from what the {\word type} means for discrimination purposes.
For example, Gaussian integers might be
described as the type {\tt (complex integer)}, even in implementations
where giving two {\datatype integers} to {\function complex\/} results
in an {\word object} of type {\tt (complex rational)}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 2.1.4 3
The type of a specific {\datatype complex\/} number is indicated by a list
of the word @f[complex] and the type of the components; for example,
a specialized representation for {\datatype complex\/}
numbers with {\datatype short-float}
parts would be of type {\tt (complex short-float)}. The type
{\datatype complex\/}
encompasses all complex representations.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (typep {\arg object} '(complex {\arg type-specifier}))}
refers to all {\datatype complex\/} numbers that can result from
giving {\datatype numbers} of type {\arg type-specifier}
to the function {\function complex\/}, plus all other
{\datatype complex\/} numbers
of the same specialized representation.
Both the real and the imaginary parts of any such
{\datatype complex\/} number must
satisfy:
{\tt (typep {\arg realpart}|{\arg imagpart} '{\arg type-specifier})}
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 12
\itemitem{\tt (function ({\arg arg1-type} {\arg arg2-type} ...)
{\arg value-type})}
\issue{FUNCTION-TYPE}
The list form of the type {\datatype function}
may be used only for declaration and not for discrimination.
\endissue{FUNCTION-TYPE}
Every element of this {\word type} is
a {\word function} that accepts arguments at least of the
types
specified by the {\arg argj-type} forms and returns a value that is a
member of the types specified by the {\arg value-type} form. The
@optional, @rest, @key,
\issue{FUNCTION-TYPE-KEY-NAME}
and @allowotherkeys\
\endissue{FUNCTION-TYPE-KEY-NAME}
markers may appear in the list of argument
types.
\issue{FUNCTION-TYPE-KEY-NAME}
The @key\ parameters
should be supplied as lists of the form {\tt (keyword type)}.
The {\tt keyword} must
be a valid keyword-name
symbol and must be supplied in the actual arguments of a
call. This is usually a {\datatype symbol} in the {\tt keyword} package
but can be any {\datatype symbol}.
The @allowotherkeys\ declarations are interpreted as follows:
when @key\ is given in a
{\tt function} type specifier lambda list,
it is safe to assume that the @key s given
are exhaustive unless @allowotherkeys\ is present.
@allowotherkeys\ is an indication
that other keyword arguments may actually be
supplied and, if supplied, may be used.
For example,
the type of the function {\function make-list} could be declared as:
@lisp
(function make-list ((integer 0) &key (:initial-element t)) list)
@endlisp
\endissue{FUNCTION-TYPE-KEY-NAME}
The {\arg value-type} may be a {\tt values}
type specifier in order to indicate the
{\word types} of multiple values.
%% 4.5.0 13
For example, the function @Funref[cons] is of type
{\tt (function (t t) cons)},
because it can accept any two arguments and always returns a {\word
cons}.
{\function cons} is
also of type {\tt (function (float string) list)},
because it can
accept a {\datatype floating}-point number
and a {\datatype string} (among other things), and its
result is always of type {\datatype list}
(in fact a {\word cons} is never {\datatype null},
but that does not matter for this type declaration).
@Funref[truncate] is of type
{\tt (function (number number) (values number number))},
as well as of type
{\tt (function (integer (mod 8)) integer)}.
%% 4.5.0 14
\itemitem{\tt (values {\arg value1-type} {\arg value2-type} ...)}
This type specifier may be used only
as the {\arg value-type} in a {\tt function} type specifier or in
@Specref[the]\rm. It is used to specify individual {\word types} when
multiple values are involved.
The
@optional, @rest, and @key\ markers may appear in the {\arg value-type} list;
they indicate the parameter list of a
{\word function} that,
when given to @Specref[multiple-value-call] along with
the values, would be suitable for receiving those values.
\endlist
%% 4.7.0 1
New type specifiers can come into existence in two ways.
\beginlist
\itemitem{\bull} Defining a structure or class
with @Macref[defstruct] or {\function defclass} automatically
causes the name of the structure or class to be a new type specifier
{\datatype symbol}.
\itemitem{\bull} {\function deftype} can be used to define new type specifier
abbreviations.
\endlist
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable to types and declarations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt deftype }&{\tt coerce }&{\tt type-of }\cr
{\tt declare }&{\tt locally }&{\tt proclaim }\cr
{\tt the }&{\tt defstruct }&\cr
\noalign{\vskip -9pt} }}
\caption{Type and declaration tools}
\endfig
\beginsubsubsection{Type Upgrading}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
When type specifiers are used to declare {\word objects} to be of a certain
{\word type}, they are said to be used
for declaration. A type specifier used for declaration
can be the
{\tt :element-type} argument to
{\function make-array}, the {\arg result-type}
argument to {\function coerce},
an argument to the special form {\function the},
or an argument to {\function declare}.
An {\word object} declared to be of a certain
{\word type} may not satisfy
{\function typep} with that type specifier.
This is permissible because an implementation
is required only to construct the
result out of the most specialized {\word type} that can
accommodate elements of the {\word type} supplied as the argument
to the {\tt :element-type} named argument to {\function make-array}.
That is, an implementation may only provide a
very small number of {\word types} for storing
{\datatype arrays\/},
and it is permitted to upgrade any {\word type} request into
one of its built-in repertoire.
One type specifier with
this property is {\tt (array {\arg type-specifier})}
for various implementation-dependent values of {\arg type-specifier}.
Another type specifier with this property is
{\tt (complex {\arg type-specifier})}.
{\word Type} upgrading implies a movement upwards in the type
hierarchy lattice. In the case of {\datatype arrays\/}
the {\arg type-specifier} must be
a {\word subtype} of
{\tt (upgraded-array-element-type '{\arg type-specifier})}.
In the case of {\datatype complex\/} numbers, the
{\arg type-specifier} must be a {\word subtype} of
{\tt (upgraded-complex-part-type {\arg type-specifier})}.
If {\arg type-specifier1} is a {\word subtype} of {\arg type-specifier2}, then
{\tt (upgraded-array-element-type '{\arg type-specifier1})}
must also be a {\word subtype} of
{\tt (upgraded-array-element-type '{\arg type-specifier2})}.
Two {\word disjoint types} can be upgraded into
the same thing.
See {\function array-element-type}.
Upgrading an {\datatype array\/} element {\word type} is independent of any
other property of {\datatype arrays\/},
such as {\word rank}, adjustability, {\word fill-pointers}, or
displacement.
The reason {\word rank} is included is because
it would not be consistently possible to displace {\datatype arrays\/}
to those of
differing {\word rank} if {\word rank} were not included.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
\endsubsubsection%{Type Upgrading}
\endsubSection%{Type Specifiers}
∂02-Mar-89 1151 X3J13-mailer Re: cs proposal comments
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 11:51:39 PST
Received: by ti.com id AA08145; Thu, 2 Mar 89 13:50:34 CST
Received: from Kelvin by tilde id AA05068; Thu, 2 Mar 89 13:39:29 CST
Message-Id: <2813859524-5211323@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 2 Mar 89 13:38:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Thom Linden <baggins@IBM.com>
Cc: x3j13@sail.stanford.edu
Subject: Re: cs proposal comments
In-Reply-To: Msg of Thu, 02 Mar 89 02:20:21 PST from Thom Linden <baggins@IBM.com>
> >> Never mind that; the real question is why do you want the standard to not
> >> specify the meaning of tabs and form-feeds in source files?
> >>
> I don't have my CLtL with me but I don't think a meaning is given
> to the semi-standard characters (unless we consider them self defining?)
I'm talking about page 336 of CLtL which specifies that the reader treats
#\TAB and #\PAGE as whitespace. Section A.22.1.1 of the February 21 document
specifies deleting the mention of these.
> The form label:registry is given on p38 where for #\, "In particular,
> an implementation may support names of the form label:registry."
> It could do with repeating on p35 (name-char, char-name).
"_may_ support"? It seems like either this should be part of the standard or
not. What does CHAR-NAME return for non-standard characters if the
implementation doesn't support this? If you are going to permit referencing
names that way, then what do we need registries for? Also, the sentence
quoted is in the context of non-graphic characters. What about names for
non-standard graphic characters? Do standard graphic characters have names?
∂02-Mar-89 1632 X3J13-mailer minor comments on the character proposal
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 16:31:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549744; Thu 2-Mar-89 19:29:32 EST
Date: Thu, 2 Mar 89 19:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: minor comments on the character proposal
To: Thom Linden <baggins@IBM.com>
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <890222.120815.baggins@almvma>
Message-ID: <19890303002938.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
These comments are not an official response to your request for a vote.
Here are some comments on the character proposal version of 21 Feb 89.
I believe these are all merely editorial, but if they are matters of
disagreement I'd like to know.
p.29, describing character attributes: It needs to be clarified that
these notes apply to all implementation-defined character attributes,
not just to attributes that might be provided for compatibility with
the earlier version of Common Lisp.
Some of these notes have not been consistently reflected elsewhere in
the proposal, for example, page 31 seems to say that the only difference
between char-equal and char-= involves alphabetic case, whereas page 29
says that char-= compares all attributes but char-equal compares an
implementation-defined set of attributes (page 29 is correct).
Similarly, where p.31 says "if the codes of two characters differ, then
they are different", it should instead say "if the codes or
implementation-defined attributes (if any) of two characters differ,
then they are different."
Two of the notes on p.29 refer to char-int and int-char, which you are
proposing to remove, so those notes should be removed.
p.33, 35: Under find-char, char-registry-name, and char-label you
indicate that registry names and labels are strings. In fact they
are symbols now, these places need to be updated.
p.38: Where it says "an implementation may support names of the
form label:registry", I believe this to be a typo for "registry:label".
The colon is evidently being used by analogy to packages, so the
registry name should precede the label, just as the package name
precedes the symbol name.
∂02-Mar-89 1909 X3J13-mailer cs proposal and straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:09:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549840; Thu 2-Mar-89 22:06:27 EST
Date: Thu, 2 Mar 89 22:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal and straw vote
To: Dan L. Pierson <pierson@mist.encore.com>
cc: baggins@ibm.com, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903012050.AA11442@mist.>
Message-ID: <19890303030636.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 01 Mar 89 15:49:59 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
IF: Moon agrees that this is sufficient for hashing (or I'm convinced that
he's wrong :-)).
This is actually an interesting issue. I was going to say that CHAR-INT
is not needed, because you can use SXHASH. After all, in any reasonable
implementation SXHASH of a character would just return the CHAR-INT, and
the only difference would be the extra cost of a type dispatch, which
might even be compiled out in some cases. Then I tried the most
reasonable implementation I know and found that SXHASH and CHAR-INT did
not return the same value. So then I did what I should have done at the
beginning, and read the documentation of SXHASH. SXHASH doesn't just
return any useful hash code, it returns one that remains constant for
all time, within "the same" implementation. This means that in any
implementation that dynamically assigns numeric encodings of any
character attribute, SXHASH cannot be the same as CHAR-INT. Genera, for
example, allows user-defined character registries and user-defined
character style attributes, and thus dynamically assigns the numeric
encoding of both character code and character style.
There are many applications of hashing for which the perpetual equality
properties of SXHASH are unwanted, and the associated efficiency cost
is undesired.
So now my opinion is that CHAR-INT should be retained, but INT-CHAR
and its shadow in the COERCE function should be removed.
What do STRING-LESSP, etc. mean for non-standard-character strings?
Isn't STRING-LESSP defined in terms of CHAR-LESSP? CHAR-LESSP has "the
results are unspecified" for two characters in different registries, I
assume, which means that STRING-LESSP of two strings of extended
characters in the same registry is perfectly well defined, and of
characters in different registries returns either true or false, but is
harmless.
∂02-Mar-89 1929 X3J13-mailer answer to request for comments on comments on comments on characters
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:28:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549853; Thu 2-Mar-89 22:26:02 EST
Date: Thu, 2 Mar 89 22:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: answer to request for comments on comments on comments on characters
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890222.100432.baggins@almvma>
Message-ID: <19890303032620.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
In your comments on my comments on the 1 Jan 89 character proposal,
you asked some questions. Here are my answers. These are personal
answers rather than Symbolics' official position.
Date: Wed, 22 Feb 89 10:04:32 PST
From: Thom Linden <baggins@IBM.com>
>> From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>> Subject: Comments on the Character proposal dated January 1, 1989
>>
>> The default for :ELEMENT-TYPE has two viable choices that I can see
>> both and let people vote:
>>
>> (1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
>> (2) The most natural type for the particular pathname being opened.
>> The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
>> already exists in Common Lisp) needs to be clarified. Perhaps they
>> are the same.
The same? I don't understand. For example, I can imagine the
element-type default as base-character and the external format
defaulted to either an ASCII or EBCDIC encoding.
I think you misunderstood. I was suggesting that perhaps the default
value for the :ELEMENT-TYPE option to OPEN should be the symbol
:DEFAULT. This doesn't relate to the external coding format as far as I
can see, except for whatever niceness we see in having the default
value for both :ELEMENT-TYPE and :EXTERNAL-CODED-CHARACTER-FORMAT be the
symbol :DEFAULT.
I see that in the 21 Feb 89 proposal you have made the default value for
the :ELEMENT-TYPE option to OPEN be implementation dependent, but not
:DEFAULT. In fact they are different, because :DEFAULT can open in
either a character type or an integer type, but (the unnamed) default
can only open in a character type. I can live with what you have
proposed, although I still believe that requiring :ELEMENT-TYPE to
default to CHARACTER might be better, and I'm a little concerned about
having a default for which there is no name within the language. I'd
also like to hear opinions on whether we need two different ways to say
"the most natural type for the particular pathname being opened", with
one of them restricted to subtypes of CHARACTER and the other
unrestricted.
More importantly, though, I think people should be given the choice
of voting between the two options mentioned above (as well as any other
options that garner some support, if there are any). As it stands
the :ELEMENT-TYPE option to OPEN isn't in the straw ballot at all,
there's just a change in the back of the proposal.
>> Also the following promise from 14 November did not show up in the report:
>>
>> >> There should be a name for the "natural" encoding and there should be a
>> >> specification of the properties of the natural encoding that a programmer
>> >> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> >> :INTERCHANGE. The definition probably involves the concept of data
>> >> interchange with non-Lisp programs on the same system.
>>
>> This will be added to the revision.
I lied. No one came up with the 'properties' of such an encoding.
Do you have some text to suggest?
I'm not sure if your :DEFAULT for :EXTERNAL-CODED-CHARACTER-FORMAT is
intended to be "natural" as well as "default", or not. I'm afraid
I haven't been able to come up with a good description of what it
means to be "natural", though. Perhaps I'm familiar with too many
oddball systems, which makes me more scared of trying to define the
concept than would be someone who only knew Unix. I think we can
safely drop this issue without much harm to the language.
>> No particular page -- We agree with the deprecation or deletion of the two
>> particular character attributes defined by CLtL, but not with the
>> deprecation of the whole concept of character attributes. In fact on page
>> 20 you say "characters are uniquely distinguished by their codes," which
>> makes it impossible to have character attributes at all. The language must
>> define how conforming programs should be written so that they will work
>> both in implementations with character attributes and in implementations
>> without them. For example, the value of (eql x (code-char (char-code x)))
>> is unspecified. Another thing that needs to be said is that the exact
>> character operations (char=, string=, etc.) respect all character
>> attributes, while the inexact character operations (char-equal,
>> string-equal, etc.) respect or ignore each character attribute in an
>> implementation-defined but consistent fashion.
This has improved in the 21 Feb 89 version, but I think more a explicit
statement is still required. You are welcome to borrow the language
("exact", "inexact") that I used just above.
Some of what you say on
>> page 44 about attributes in general needs to be part of the spec, not
>> deprecated. I would retain everything on that page except for INT-CHAR and
>> the last bullet (referring to bits and fonts), and I would add a remark
>> that FIND-SYMBOL and INTERN respect character attributes. If you want,
>> perhaps I or someone else at Symbolics can provide exact text for what
>> to say about character attributes that you could insert into your report.
I moved the attribute list previously in Appendix B back into the
description of characters. Let me know what text you would like
to see for FIND-SYMBOL and INTERN and I'll add it to the list.
After "It is implementation dependent whether attributes are removed
from symbol names by READ" (and by the way, in this and the preceding
bullet I believe "whether" shoudl be changed to "which", since an
implementation with several character attributes might have good reason
to remove some and retain others), I would add "The functions FIND-SYMBOL
and INTERN do not remove character attributes."
∂02-Mar-89 1941 CL-Characters-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:41:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 549857; 2 Mar 89 22:39:01 EST
Date: Thu, 2 Mar 89 22:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
To: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
cc: Jon L White <jonl@lucid.com>, Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU,
X3J13@SAIL.STANFORD.EDU, Common-Lisp-Implementors@Symbolics.COM, KMP@Symbolics.COM,
Palter@Symbolics.COM
In-Reply-To: <19890204142708.2.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Supersedes: <19890303023922.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Removed % signs
Message-ID: <19890303033902.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 4 Feb 89 09:27 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Legitimate operations on BASE-CHARACTER do not
produce characters in (AND CHARACTER (NOT BASE-CHARACTER)).
I'm not sure which programs written using symbols in the LISP package
are "legitimate operations" and which are not. However, I didn't see
anything in the 21 Feb 89 proposal that says that CHAR-UPCASE of
a BASE-CHARACTER is necessarily a BASE-CHARACTER, for example.
That doesn't sound unreasonable, though; should it be added?
∂03-Mar-89 0004 X3J13-mailer cs comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 00:03:57 PST
Date: Thu, 02 Mar 89 17:19:25 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.171925.baggins@almvma>
Subject: cs comments
>> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>> Subject: minor comments on the character proposal
>>
>> These comments are not an official response to your request for a vote.
>>
>> Here are some comments on the character proposal version of 21 Feb 89.
>> I believe these are all merely editorial, but if they are matters of
>> disagreement I'd like to know.
>>
>> p.29, describing character attributes: It needs to be clarified that
>> these notes apply to all implementation-defined character attributes,
>> not just to attributes that might be provided for compatibility with
>> the earlier version of Common Lisp.
Ok.
>>
>> Some of these notes have not been consistently reflected elsewhere in
>> the proposal, for example, page 31 seems to say that the only difference
>> between char-equal and char-= involves alphabetic case, whereas page 29
>> says that char-= compares all attributes but char-equal compares an
>> implementation-defined set of attributes (page 29 is correct).
>> Similarly, where p.31 says "if the codes of two characters differ, then
>> they are different", it should instead say "if the codes or
>> implementation-defined attributes (if any) of two characters differ,
>> then they are different."
The intent was that p29 defined all the modified behaviors when
implementation-defined attributes were supported. I could repeat these
notes (through modified text) at each of the referenced locations or
make the intent of p29 stronger. Which do you feel is clearer?
>>
>> Two of the notes on p.29 refer to char-int and int-char, which you are
>> proposing to remove, so those notes should be removed.
Correct.
>>
>> p.33, 35: Under find-char, char-registry-name, and char-label you
>> indicate that registry names and labels are strings. In fact they
>> are symbols now, these places need to be updated.
Right.
>>
>> p.38: Where it says "an implementation may support names of the
>> form label:registry", I believe this to be a typo for "registry:label".
>> The colon is evidently being used by analogy to packages, so the
>> registry name should precede the label, just as the package name
>> precedes the symbol name.
>>
Ok.
∂03-Mar-89 0913 X3J13-mailer cs comments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 89 09:13:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550140; Fri 3-Mar-89 12:10:42 EST
Date: Fri, 3 Mar 89 12:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs comments
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890302.171925.baggins@almvma>
Message-ID: <19890303171050.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 02 Mar 89 17:19:25 PST
From: Thom Linden <baggins@IBM.com>
>> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>> Subject: minor comments on the character proposal
>>
>> Some of these notes have not been consistently reflected elsewhere in
>> the proposal, for example, page 31 seems to say that the only difference
>> between char-equal and char-= involves alphabetic case, whereas page 29
>> says that char-= compares all attributes but char-equal compares an
>> implementation-defined set of attributes (page 29 is correct).
>> Similarly, where p.31 says "if the codes of two characters differ, then
>> they are different", it should instead say "if the codes or
>> implementation-defined attributes (if any) of two characters differ,
>> then they are different."
The intent was that p29 defined all the modified behaviors when
implementation-defined attributes were supported. I could repeat these
notes (through modified text) at each of the referenced locations or
make the intent of p29 stronger. Which do you feel is clearer?
I feel strongly that in the eventual language standard, it will not be
acceptable to have two sections that speak inconsistently about the same
thing, with the reader told that one section takes precedence over the
other. Thus in the eventual document, this kind of information must be
repeated (at least by reference) at each occurrence. For example, you
can't say in one place "char-equal is the same as char-= except it ignores
alphabetic case" and then say in another place "the other description
of char-equal was simplified for your comfort and convenience, the real
description is char-equal is the same as char-= except it ignores
alphabetic case and some implementation-defined character attributes."
I'm not sure what this says about your document, which is so far from
being in the form of the eventual language standard. It is very
difficult to know whether we are voting on chapters 1 and 2 of the
document, on appendix A of the document, or on the abbreviated "cleanup
issues" in your straw poll. If we're not voting on Appendix A there
is little advantage in spending time making it self-consistent.
Some observers may be wondering why I want implementation-defined
attributes to be discussed in the standard, instead of merely being
defined by the implementations. The issue is to make it possible to
write programs that are both conforming and portable among
implementations with varying implementation-defined attributes, without
the programmer first having to study and compare the documentation of
all the implementations. In other words, the Common Lisp language
standard should define the framework for implementation-defined
character attributes, and the individual implementations should just
fill in that framework. If the language didn't mention the possible
existence of implementation-defined character attributes, it would
be too easy to write a program that at first seemed conforming, but
in fact would not behave as desired on an implementation with
character attributes.
∂03-Mar-89 1006 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 10:06:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03990g; Fri, 3 Mar 89 10:00:10 PST
Received: by challenger id AA20493g; Fri, 3 Mar 89 09:55:26 PST
Date: Fri, 3 Mar 89 09:55:26 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903031755.AA20493@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue: ERROR-TERMINOLOGY
I looked at the error terminology section as if I were the editor of
the specification, and I made some further changes. I had made an
earlier pass over the material that was intended to tighten it up, but
one can almost always continue to improve things. I showed this draft
to Moon and he said ``I am entirely happy with your proposed rewording
of the error terminology.''
The remainder of this message contains the proposed rewording:
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
21-FEB-89, Version 5 by Chapman, added van Roggen, RPG comments
3-MAR-89, Version 6 by Gabriel, rewrite prompted by Moon
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code shall not use any constructions
that are prohibited by the standard.
(2) Conforming code shall not depend on extensions
included in an implementation.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necesarily code that does
not do error checking: Implementations are
permitted to treat all code as safe code all the time.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not
accessible in the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might be signalled in unsafe code.
Every implementation is required to detect the error
at least in safe code. When the error is not
signalled, the "consequences are undefined" (see
below). For example, "an error should be signalled
if ENDP is given a non-list argument."
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the
results and effects of this situation as unpredictable
but harmless. For example, ``the consequences of the
garbage collector when invoked are unspecified.''
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The
consequences may range from harmless to fatal. No
conforming code can depend on the results or
effects. Conforming code must treat the results and
effects as unpredictable. In places where the
words "must", "must not" or "may not" are used,
then "the consequences are undefined" if the stated
requirement is not met, and no specific consequence
is explicitly stated. For example: "Once a name
has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable has undefined consequences."
RETURN VALUES ARE UNSPECIFIED Only the number and nature of the return values
of a construct are not well specified but any
side-effect and transfer-of-control behavior is well
specified. For example, if the return values of some
function F are unspecified, then an expression such as
(length (list (F))) is still well-specified because it
does not rely on any particular aspect of the value or
values returned by F.
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
situation in ANY ONE of the following ways: (1)
When the situation occurs, an error is signalled at
least in safe code, OR (2) When the situation
occurs, the "consequences are undefined", OR (3)
When the situation occurs, the consequences are
defined. Also, no conforming code can depend on
the results or effects of this situation, and all
conforming code must treat the results and effects
of the situation as undefined. For example,
"implementations may be extended to define other
type specifiers to have a corresponding class."
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
WARNING IS ISSUED A warning is issued, as described in WARN, in both
safe and unsafe code and when the situation is
detected by the compiler. Conforming code may rely
on the fact that a warning will be issued in both
safe and unsafe code and when the situation is
detected by the compiler. Every implementation is
required to detect this situation in both safe and
unsafe code and when the situation is detected by
the compiler. The presence of a warning will in no
way alter the value returned by the form which
caused the situation to occur. For example, "a
warning is issued by the compiler if a declaration
specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not
rely on the fact that a warning will be issued. If
the situation is detected by the compiler, a
warning may or may not be issued, depending on the
implementation. The presence of a warning will in
no way alter the value returned by the form which
caused the situation to occur. For example, "a
warning should be issued by a compiler if a
variable declared to be ignored is referenced
or is also declared special, or if a variable is
lexical, never referenced, and not declared to be
ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
∂03-Mar-89 1130 X3J13-mailer Re: Section 1.7
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 11:30:17 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA13011; Fri, 3 Mar 89 11:28:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA12864; Fri, 3 Mar 89 11:24:49 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26139; Fri, 3 Mar 89 11:27:58 PST
Date: Fri, 3 Mar 89 11:27:58 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903031927.AA26139@clam.sun.com>
To: barmar@Think.COM, pierson@mist.encore.com
Subject: Re: Section 1.7
Cc: chapman%aitg.DEC@decwrl.dec.com@Multimax.encore.com,
skona%csilvax@hub.ucsb.edu@multimax.encore.com,
x3j13@sail.stanford.edu
I agree with Barry. Packages not named in the standard belong
to software developers. Otherwise every name defined by anyone
becomes an extension to Common Lisp, and I don't think we want
to define "extension" that way.
∂03-Mar-89 1202 X3J13-mailer Common Lisp
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 12:02:33 PST
Received: from fafnir.think.com by Think.COM; Fri, 3 Mar 89 14:56:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 3 Mar 89 14:58:31 EST
Received: by verdi.think.com; Fri, 3 Mar 89 14:55:18 EST
Date: Fri, 3 Mar 89 14:55:18 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903031955.AA21691@verdi.think.com>
To: moore@cli.com
Cc: x3j13@sail.stanford.edu
Cc: Steele@Think.COM
In-Reply-To: J Strother Moore's message of Fri, 3 Mar 89 10:44:34 CST <8903031644.AA08035@client13.CLI.COM>
Subject: Common Lisp
Date: Fri, 3 Mar 89 10:44:34 CST
From: J Strother Moore <moore@cli.com>
I just wanted to let you know that I love Common Lisp.
I have used it a lot this past year extending Boyer's and
my theorem prover and the more I've used it the more I
like it. You guys really did a great job.
J
Thank you very much for the compliment. ANSI committee X3J13
is working to clean up the rough spots and fill in the gaps;
I hope you like the revision as much as the current definition.
And of course lots of credit must go to the implementors.
This mail made my day.
--Guy Steele
∂03-Mar-89 1221 X3J13-mailer KMP's personal comments on 22-Feb-89 Character Proposal
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 89 12:21:23 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550353; Fri 3-Mar-89 15:17:40 EST
Date: Fri, 3 Mar 89 15:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: KMP's personal comments on 22-Feb-89 Character Proposal
To: Baggins@IBM.COM
cc: X3J13@SAIL.Stanford.EDU
References: <19890303165649.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890303201737.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Please find below my personal comments on the hardcopy character
proposals of 22-Feb-89 which I received from you by US Mail.
This is not the Symbolics official position. Moon will send that
at a later date.
Note that this will be my only mailing to this large list on this
issue prior to the meeting. If I have anything further to say, I
will bring it up on CL-Characters or some smaller list. I expect,
however, that my attention will be focused on other issues.
By the way, you still have my old address (11 Cambridge Center).
The correct new address for me, Moon, and Symbolics R&D is:
8 New England Executive Park, East
Cambridge, MA 01803-5007
----- Comments on the Isolated Proposals (hardcopy of 22-Feb-89) -----
Presentational Comments
- This doesn't follow the normal proposal format being used by
other groups. As a consequence...
- there are no examples to make certain sticky points clearer
- there is no impact analysis
- there is no rationale for some of the questionable changes
I think it is unreasonable to expect people to just infer this
kind of thing. Reasoning about these things takes a lot of time.
Writing down your thoughts once you've reasoned about something
takes much less time than asking someone to repeat your entire
process in order to decide if they approve.
Also, there is precedent for making decisions in language design
that later are suggested to be mistakes. Often it is hard to
distinguish `changing goals' from `poor communication' from
`oversight' from `typo.' Our normal proposal format is designed
to avoid some of these symptoms by making explicit some things
that would not be explicit in the final document, and by adding
redundancy that helps catch typos, miscommunication, etc.
- The proposal descriptions are far too brief. They are prone to
misinterpretation. Worse, an `expansion' does not occur elsewhere.
Often to disambiguate you have to do a lot of digging around and
assembling things from pieces here and there.
At the very least, there should be index information from these
short punchy phrases to something less ambiguous. Better still
would be to really spell out the details in the proposal so that
they can be examined in the abstract.
Breaking this big proposal up into little ones should have
accomplished two things: it should have allowed us to understand
the parts of the proposal in isolation, and it should have allowed
independent voting. I think it currently allows neither, because
you can't understand the individual proposals without understanding
the whole and if you vote No on any particular part, you aren't left
with a document that Kathy can usefully work with.
Technical Comments
- Regarding defining that STRING-CHAR must be either BASE-CHAR or
CHARACTER -- This seems unmotivated and I am suspicious of it.
It seems, somehow, unnecessarily restrictive.
- I don't mind if INT-CHAR is removed, but I don't think CHAR-INT
should be removed. It may be useful in some hashing applications.
- Regarding the problem description in CHARACTER-TYPE-RESTRICTIVE,
I don't think that I believe that CHARACTER doesn't allow both fat
and thin characters. Is this claim motivated somewhere.
- The proposal CHARACTER-TYPE-RESTRICTIVE suggests replacing
STANDARD-CHAR by (CHARACTER :STANDARD), but since STANDARD-CHAR
is not really going away, this wording is misleading.
- Proposals STRING-TYPE-RESTRICTIVE and SIMPLE-STRING-TYPE-RESTRICTIVE
refer to making STRING and SIMPLE-STRING (respectively) union types.
The details of this are never spelled out. The consequences are not,
I think, appropriately analyzed. I would like to better understand the
relationship between this and the new array TYPEP situation to make
sure there are no bad interactions.
- I do not understand from the description of
SIMPLE-STRING-TYPE-ABBREVIATIONS why adding SIMPLE-BASE-STRING
and SIMPLE-GENERAL-STRING is an answer to the problem that new types
are awkward to name.
Aesthetic Comments
- I think the terms `coded character format' and `coded character set'
are ok for a concept description, but inappropriate for a language spec.
They are too long for convenient lunch table discussion, note taking,
etc. If you want something to be part of a language that people use in
a serious way, you have to either truncate the terms to manageable
size or expect people to do it for you. If you do it, at least that
visitors from other companies will be able to participate in lunch
table discussions. If you let your users do it, there will be lots of
gratuitous variation. The impact of this is that...
- In FILE-EXTERNAL-REPRESENTATION, :EXTERNAL-CODED-CHARACTER-FORMAT
is far too long. In any situation, such as with OPEN, where the
space of keywords is not user-extensible, the need for
extraordinarily long names is very low because short names can
adequately disambiguate. I see no reason why some much shorter
keyword cannot be devised. (Just for your reference, even
:IF-DOES-NOT-EXIST tries my patience.)
I suggest :EXTERNAL-ENCODING as a straw man, but all I really care
about is that it be a minimal number of words, and I don't think
the proposed choice is short enough.
- In STRING-BINARY-WIDTH, I think the name EXTERNAL-CODED-STRING-LENGTH
is again too long. It's not like people will ever add symbols to
the LISP package, so it's not like a shorter name would be ambiguous.
I suggest STRING-ENCODED-LENGTH (to match my :EXTERNAL-ENCODING above).
- In CHAR-CODE-NON-PORTABLE, I very strongly dislike abbreviations except
in extraordinary circumstances like `char' where the abbreviation is
nearly ripe for adoption as an English word due to its extremely wide,
or where the word is used so often that spelling it out would be too
awful.
However, if you spell it out, I'll complain that it is too long a term.
I propose you call the thing CHAR-ENCODING.
- In CHARACTER-IDENTIFICATION-NONPORTABLE, I don't think you've necessarily
solved anything if you say that (a) all characters must come from some
registry and (b) all registries must be dicated by an ISO group that doesn't
exist. It necessarily follows that there can be no correct implementation
until that working group finishes. What are people to do in the interim?
It either needs to be spelled out, or it needs to be explained why what they
do doesn't matter. [And, indeed, if it doesn't matter, then it's going to be
hard to make the case that a lot of the existing rules are really necessary.]
Typos
- In CHARACTER-TYPE-RESTRICTIVE, defining BASE-CHARACTER as a subtype
of STRING seems like an extraordinarily bad idea. :-)
- In STRING-BINARY-WIDTH, presumably the function name does not want
to be in the KEYWORD package.
----- Comments on the Concept Part (hardcopy of 22-Feb-89) -----
Presentational Comments
- The proposal uses the term "removed" a lot but that sometimes seems to
mean "gets totally rid of", sometimes means "deprecates", sometimes
means "adds something that's really better". Maybe I'm just misreading,
but it would be helpful in terms of being a proposal that people have to
vote on, to clearly define these terms.
- I am actually offended by the use of these tags like ISO8859/2-1987
with no exposition. This gives a `snobby' look to the paper and amounts
to jargon because it is not intelligible by people who are on in on
ISO affairs. I feel forced to write to ISO to get these documents just
to know what you're talking about. I have no sense for whether you are
talking about something I'm familiar with under another name, or
something totally irrelevant to me. I made annotations all over the
document about this. It was really starting to bug me.
- p9, last two paragraphs before 2.3 should be a single paragraph.
- I found it hard to read about REGION-SPECIALIZED-STRING, GENERAL-STRING,
etc. and then to think that you weren't in fact proposing it. Someone
skimming would probably miss the word `hypothetical' ... Especially since
my vague recollection is that this stuff was really in a previous proposal,
I think this stuff either be much more clearly set off as an example.
Technical Comments
- From a human interface standpoint, I think it would be desirable for
character repertoires to have more than one possible name. My guess
is -- though I have no way of proving it since no hint is given about
what names these things refer to -- that these things have more common
nicknames that would be more programmer-friendly if allowed. Names made
up of mostly digits are not appealing to me.
- If people can add non-stanard registries, there is a potential for
confusion. If I add a private registry named FOO and then at a later
time ISO votes in a registry named FOO, mine will suddenly appear to
be the official one. If there a way to tell official ones from unofficial
ones, that might avoid some problems down the road. Alternatively, if
a portion of the registry namespace were allocated for ISO (or,
conversely, reserved for private use), that would solve the problem.
- The fact that character labels must be uniquely named using only
standard-char-p characters strikes me as having funny bootstrap
implications. I don't know what if anything to do about that, but I
thought I'd mention it.
- The issue of character labels also makes me wonder about uses of
special chars like colon, backslash, semicolon, dollarsign which often
have special meaning to Lisp and other languages. Further, the use
potential to use underscore and hyphen seems like a bad idea, too,
because some systems prefer underscore to hyphen -- and vice versa.
Personally, I think we ought to say that character labels have to be
made of A to Z, a to z, and 0 to 9 (with preference for alphabetics
over numerics -- i.e., they should try to be actual words).
- Also, who will assign character labels? Will they not be standard
across implementations? This is a place where examples of sample uses
would help a lot.
- I couldn't make sense of the cryptic phrase `Reader Canonicalization'
in a bullet item at bottom of chap 2, page 8. I think this should
be elaborated.
- I've wrestled with this business of (and character (not base-character))
a lot and come to the conclusion that you should give this a name
in the language itself. e.g., you should deftype the name
extended-character. The reasons are these:
- so it can be used in discussions, bug reports, etc.
- so that there is a term that could be common between lisp and some
other language -- where the other language was non-lispy and a lisp
AND expression would not be welcome.
- When the external encoding is not reliably using a single-byte format,
you need to specify the consequences for the functions FILE-POSITION
and FILE-LENGTH.
- Is $ really what is replaced by the British pound sign on British
displays? I had always thought that # was what was replaced. My point,
though, is that there may be more than one axis on which to view
`equivalent functionality.'
I don't think I'm disagreeing with you on the details here, but I am
saying that I don't think it's as pretty a picture as you paint it,
and that (like the `pathnames' section in CLtL) you risk making people
think they're getting a more comfortable solution than they're really
getting.
I think the real point here should be that this is a thing which
gratuitously varies in the marketplace and in the world, that we don't
have a prayer of standardizing it, and we're leaving it up to vendors
to do the best they can.
I have a couple of specific questions, though:
- What if a program that on American terminals types out:
That will cost $4.00
types out
That will cost L4.00
on a british screen. I'm not so sure I'm happy with that.
- What about _ vs -. Some computer systems seem to take languages
that are defined to distinguish case (and be all uppercase) and
invert the case (make it all lowercase), often flipping hyphen
and underscore, and single and doublequote in the process. Are
these valid transformations?
- top of p13, you say that the COERCE function is extended to allow
for coercion from base string to extended string. Be explicit about
how this is done.
- Regarding footnote 18 on p13, my personal feeling is that either all
conventions should be itemized or none should. If none are, you can
pick obviously hypothetical names. However, I think that to mention
one or two encodings and not others amounts at best to advertising
and at worst can either pin an implementation unnecessarily (by having
an external document such as CLtL or the ANSI CL spec define something
which might want to vary over time) or can cause a market bias toward
implementations which have their convention mentioned over implementations
which do not have their conventions mentioned.
- The whole issue of non-graphic characters is almost totally omitted
from the discussion. I think more should have been said. A parenthetical
remark about #\Newline at top of p14 of chap 2 is about all there seemed
to be.
- I think the reason that EXTERNAL-CODED-STRING-LENGTH does not address
the problem of screen width in proportional fonts should be addressed.
Is an implication also that Huffman coding (is that how you spell it)
in stream output is also not addressed (or possibly illegal) because
it is context sensitive?
Typos
- You've put some function names in italic where you meant code-font.
e.g., in Section 2.1
-----
Due to time constraints, I only skimmed the editorial modifications to
CLtL in trying to get answers to specific questions I ran into in the
other parts. The absence of remarks about those changes shouldn't
necessarily be construed at this time as approval on my part.
∂03-Mar-89 1427 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 14:27:24 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA19379; Fri, 3 Mar 89 14:27:47 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA21544; Fri, 3 Mar 89 14:23:46 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26314; Fri, 3 Mar 89 14:27:06 PST
Date: Fri, 3 Mar 89 14:27:06 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903032227.AA26314@clam.sun.com>
To: rpg@lucid.com, x3j13@sail.stanford.edu
Subject: Re: Issue: ERROR-TERMINOLOGY
The terminology "CONSEQUENCES ARE UNSPECIFIED" is still a
trap in my opinion. The example, ``the consequences of the
garbage collector when invoked are unspecified'', is not
as appropriate as it might be, because there is no explicit
way to invoke the garbage collector in Common Lisp and the
example is not taken from the specification of the language
as far as I know.
But, what the heck, let's look at this example. Are the
results and effects of this situation "unpredictable but
harmless"? Not in my book. Running the garbage collector
is supposed to have (essentially) *no* visible effects.
It can't change the value of any variable or data structure
in any observable way. It can issue messages, I guess, and
change the report from "ROOM", but that is likely to change
with every call anyway.
Let's pick a few actual examples where the language definition is
proposed to say "consequences are unspecified". (Go ahead, I challenge
you.) I think we will find that the description will have to be more
specific than that. It can make sense to say that "effect X may or may
not occur". It can make sense to say that "data structure Y may be
modified arbitrarily". If we can define a set of effects that we
consider harmless, and change "unpredictable but harmless" to just
"harmless", or some such, that could also make sense, but not the current
language.
∂03-Mar-89 1539 X3J13-mailer What is a FUNCTION?
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Mar 89 15:39:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07284; Fri, 3 Mar 89 16:37:18 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04478; Fri, 3 Mar 89 16:37:16 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903032337.AA04478@defun.utah.edu>
Date: Fri, 3 Mar 89 16:37:14 MST
Subject: What is a FUNCTION?
To: x3j13@sail.stanford.edu
From section 2.2 of the working draft:
A FUNCTION may be supplied as an argument without error to FUNCALL or
APPLY, and is to be executed as code when arguments are supplied. The
functional computation produces one or more values, produces no
values, or takes a non-local exit.
Is this *really* the best definition of what a FUNCTION is that we can
come up with? I've talked to some other people here and while we are
all having a remarkably hard time coming up with some specific words,
we are all agreed that this definition really misses the boat.
Surprisingly, none of the Lisp texts I have handy have much discussion
on what a function is, and the R**3 Scheme report says almost nothing
about what a procedure object is either. I really had no idea that
there was such a gaping hole in our understanding of such an
apparently fundamental concept....
To me, it seems like the definition of the FUNCTION type ought to
incorporate at least the following four notions:
- encapsulation of process as object
- capture of lexical environment
- generalization via parameters
- evaluation of body delayed until funcall
Also I would expect to see a statement that FUNCTION objects are
created by the evaluation of a (FUNCTION (LAMBDA ...)) form.
Would anybody like to take a stab at putting together a better
definition?
-Sandra
-------
∂03-Mar-89 1548 X3J13-mailer Error Terminology
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 15:48:06 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00688g; Fri, 3 Mar 89 15:41:25 PST
Received: by challenger id AA21289g; Fri, 3 Mar 89 15:36:54 PST
Date: Fri, 3 Mar 89 15:36:54 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903032336.AA21289@challenger>
To: x3j13@sail.stanford.edu
Subject: Error Terminology
Ok Cris, here is the example. It is from CLOS chapter 1.
The description is of the system-supplied method for
SHARED-INITIALIZE. The second argument specifies a list of
slots that will be dealt with in certain cases.
``There is a system-supplied primary method for {\bf
shared-initialize} whose first parameter specializer is the class {\bf
standard-object}. This method behaves as follows on each slot,
whether shared or local:
...
\item{\bull} Any slots indicated by the second argument that are still
unbound at this point are initialized according to their {\bf
:initform} forms. For any such slot that has an {\bf :initform} form,
that form is evaluated in the lexical environment of its defining {\bf
defclass} form and the result is stored into the slot. For example,
if a {\bf :before} method stores a value in the slot, the {\bf
:initform} form will not be used to supply a value for the slot. If
the second argument specifies a name that does not correspond to any
slots accessible in the instance, the results are unspecified.''
Now, should this say that if the second argument specifies a name that
does not correspond to an accessible slot that it is ignored? Well,
that is what it does in some sense, but there may be processing that
goes on to discover the fact that it should be ignored, so supplying
exactly exactly one slot that appears nowhere in the hierarchy might
take an arbitrary amount of time to discover. For example, if there
are 100,000 classes, the CPL might need to be calculated, which could
take up to 40 seconds and involve CONSing 5mbytes, possibly
side-effecting each class object in certain ways. Or while the
programmer is getting coffee, the multitasking system might have
noticed inactivity and woken up the CPL calculation process, computing
the CPL for the right classes, so when the programmer returns and
causes shared-initialize to happen, this effect doesn't happen. Or
the search for the slot might invoke other internal initialization
procedures or protocols that should be harmless. Or maybe some
programming environment structures are altered. Or maybe some other
processes are started.
Right now I don't know even what the odd effects of the CPL
computation will be in any particular Common Lisp, and the CPL
computation might be involved in the effects of shared-initialize.
I wasn't sure what Cris meant by this argument regarding the garbage
collector:
``But, what the heck, let's look at this example. Are the
results and effects of this situation "unpredictable but
harmless"? Not in my book. Running the garbage collector
is supposed to have (essentially) *no* visible effects.
It can't change the value of any variable or data structure
in any observable way. It can issue messages, I guess, and
change the report from "ROOM", but that is likely to change
with every call anyway.''
I might point out that rehashing can happen as a result of GC, and in
parallel processing extensions to Common Lisp, running processes (such
as those behind futures) could be killed. Output in output buffers
might be shipped to their final destinations. Weak pointer arrays
could be altered. Dispatch tables for generic functions could be
recalculated, and instances whose structure had been redefined by
forward-referencing could be re-optimized, and possibly some metaobject
protocol could be triggered.
But, ignoring these, it sounds offhand like he wasn't sure what
effects GC might have or whether they would happen (``essentially'';
``I guess''), but he was certain there would be no visible effects.
Maybe he thought the results were unpredictable but harmless?
Cris suggests:
``If we can define a set of effects that we consider harmless, and
change "unpredictable but harmless" to just "harmless"....''
My point is that it is very hard to enumerate or classify all possible
effects in all possible implementations with all possible legal
extensions on all possible hardware at all future times. And it is
much easier to define terminology that captures our intent and use it.
-rpg-
∂03-Mar-89 1632 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Mar 89 16:32:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09474; Fri, 3 Mar 89 17:30:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04518; Fri, 3 Mar 89 17:30:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903040030.AA04518@defun.utah.edu>
Date: Fri, 3 Mar 89 17:30:32 MST
Subject: Re: Issue: ERROR-TERMINOLOGY
To: rpg@lucid.com
Cc: x3j13@sail.stanford.edu
I've been bothered by "the consequences are unspecified" too, although
I've kept my mouth shut on the issue up until now in the hopes that
the problem would resolve itself.
First some background. We've had problems deciding on error
terminology for some of the compiler issues because it seems like none
of the standard error terms really say what we want, which is
something to the effect of: You can't depend on being able to compile
code that does this. In any particular implementation, the behavior
will be well-defined, but that behavior may be (for the compiler
and/or loader) to signal an error. Conforming programs cannot rely on
any particular behavior in this situation, but simply compiling code
that does this will not cause a crash-and-burn situation.
Saying "the consequences are undefined" doesn't seem like the right
thing, because it permits the possibility of random crash-and-burn
errors. I am not sure if "the consequences are unspecified" is really
right either, because I'm not sure if "harmless" was intended to
include signalling an error.
So far, in situations where it is reasonable to signal an error (for
example, issue COMPILE-FILE-SYMBOL-HANDLING), I have been using
"unspecified" but explicitly saying that it is OK to signal an error.
I would feel more confortable with this if the definition of the term
"unspecified" said that signalling errors or warnings is permissible,
at least in those situations where the standard explicitly says it is.
A further problem with "the consequences are unspecified" is that I
think the word "consequences" is too unspecific about is being left
unspecified. :-) We ought to be very careful about using this phrase
and instead try to state exactly which "consequences" are unspecified.
-Sandra
-------
∂03-Mar-89 1704 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 17:03:58 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA00803g; Fri, 3 Mar 89 16:57:17 PST
Received: by pitney-bowes id AA11422g; Fri, 3 Mar 89 16:55:51 PST
Date: Fri, 3 Mar 89 16:55:51 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903040055.AA11422@pitney-bowes>
To: sandra%defun@cs.utah.edu
Cc: rpg@lucid.com, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 3 Mar 89 17:30:32 MST <8903040030.AA04518@defun.utah.edu>
Subject: Issue: ERROR-TERMINOLOGY
Why can't we use phrases like:
"the consequences might be fatal"
"the consequences might signal an error"
"the consequences won't signal an error"
For me, saying "the consequences are undefined" is a bit like saying
"slow, construction ahead" when in fact the bridge might be out.
jlm
∂04-Mar-89 1159 X3J13-mailer Error Terminology
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The error terminology is useful for explaining general behavior
in various situations where we do not wish to state explicitly what could
happen, but ordinary English description is not forbidden.
That is, if you want to say that something is unspecified but might
signal an error, we don't need special terminology for that since that
phrase itself is perfectly fine. (Note: ``unspecified'' allows implementations
to specify what happens, and signalling an error is a fine specification.)
In addition, if people feel that we should elaborate on the possible
consequences of some action, we should simply spell them out. The fact we
have error terminology doesn't mean that we cannot use our judgement in
particular situations.
-rpg-
∂06-Mar-89 1133 X3J13-mailer Re: KMP's personal comments on 22-Feb-89 Character Proposal
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 6 Mar 89 11:32:45 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02296; 6 Mar 89 18:55 GMT
Date: Mon, 6 Mar 89 19:22:51 GMT
Message-Id: <19790.8903061922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: KMP's personal comments on 22-Feb-89 Character Proposal
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Baggins@ibm.com
In-Reply-To: Kent M Pitman's message of Fri, 3 Mar 89 15:17 EST
Cc: X3J13@sail.stanford.edu
> - Is $ really what is replaced by the British pound sign on British
> displays? I had always thought that # was what was replaced.
It is often the case that hash is replaced by the british pound sign.
For example, I soon learned to recognize L'(lambda ...). Indeed,
ASCII-based systems (machines, terminals, etc) seem to do this,
though some other things (ICL 1900 series machines, say) may replace
dollar sign with pound.
-- Jeff
∂06-Mar-89 1322 X3J13-mailer Re: minor comments on letter ballot material
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:22:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551534; Mon 6-Mar-89 16:19:23 EST
Date: Mon, 6 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: minor comments on letter ballot material
To: Gregor.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
In-Reply-To: <19890302024559.5.GREGOR@SPIFF.parc.xerox.com>
Message-ID: <19890306211857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 1 Mar 89 18:45 PST
From: Gregor.pa@Xerox.COM
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
This change makes it impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
We could say that MAKE-INSTANCES-OBSOLETE "affects" all the slots, rather
than saying that it "affects" none of the slots. However, I'm willing to
just drop the issue.
∂06-Mar-89 1348 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:48:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551584; Mon 6-Mar-89 16:45:08 EST
Date: Mon, 6 Mar 89 16:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Feb. 21 Letter Ballot: editorial issues
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902211607.AA09708@decwrl.dec.com>
Message-ID: <19890306214441.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is the official response of Symbolics to the Feb 21 1989
letter ballot on Common Lisp editorial issues.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | I | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
Accompanying comments:
ERROR-TERMINOLOGY: The version included with the ballot is inadequate
(details criticisms in comments mailed earlier from Moon and from Pitman).
The more recent draft mailed out by Gabriel is better. We intend to
vote yes when we see a draft that is precise, self-consistent, and
doesn't contain examples that contradict the rest of the definition of
Common Lisp; we believe the most recently mailed draft is quite close to
that and would be surprised not to see an acceptable draft at the March
meeting.
The five numbered sections: We approve these in principle, but aren't
ready to cast them in concrete. We haven't had time to review them with
the extreme care warranted for a language standard, and don't know who
else, if anyone, has reviewed them that thoroughly. We intend to vote
yes when we know that these have been reviewed with good judgement and
attention to detail, or if informed that voting yes does not mean that
these sections will be put into the standard without permitting an
opportunity for further review and correction.
∂06-Mar-89 1355 X3J13-mailer minor comments on letter ballot material
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:55:10 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02303g; Mon, 6 Mar 89 13:46:42 PST
Received: by challenger id AA25811g; Mon, 6 Mar 89 13:41:55 PST
Date: Mon, 6 Mar 89 13:41:55 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8903062141.AA25811@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gregor.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com,
x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
In-Reply-To: David A. Moon's message of Mon, 6 Mar 89 16:18 EST <19890306211857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: minor comments on letter ballot material
Date: Mon, 6 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Line-Fold: No
This change makes it impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
We could say that MAKE-INSTANCES-OBSOLETE "affects" all the slots, rather
than saying that it "affects" none of the slots. However, I'm willing to
just drop the issue.
I think it's hard to do. It is specified that class redefintion will call
make-instances-obsolete. So all the slots would be affected whenever a class
redefinition makes the instances obsolete.
We could do it by changing make-instances-obsolete to take a list of slots to
mark as affected.
Patrick.
∂06-Mar-89 1453 X3J13-mailer Re: cs proposal comments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:53:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551649; Mon 6-Mar-89 17:51:21 EST
Date: Mon, 6 Mar 89 17:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: cs proposal comments
To: David N Gray <Gray@DSG.csc.ti.com>, Thom Linden <baggins@IBM.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <2813859524-5211323@Kelvin>
Message-ID: <19890306225107.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 2 Mar 89 13:38:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> >> Never mind that; the real question is why do you want the standard to not
> >> specify the meaning of tabs and form-feeds in source files?
> >>
> I don't have my CLtL with me but I don't think a meaning is given
> to the semi-standard characters (unless we consider them self defining?)
I'm talking about page 336 of CLtL which specifies that the reader treats
#\TAB and #\PAGE as whitespace. Section A.22.1.1 of the February 21 document
specifies deleting the mention of these.
I think I saw several messages complaining about this. I think it would
actually be okay to remove the semi-standard characters, and that this would
not mean that portable programs could not be written with tabs and form-feeds.
It's already the case that when porting a program between implementations one
may have to do character set translation on the source text of the program.
When porting to an implementation that does not have tab or formfeed (which
is already legal), the character set translation must change those into
spaces, or something.
On the other hand, a nice thing about CLtL is the way it said that an
implementation doesn't have to support tabs, but if it does have tabs,
this is how they should work. Thus the programmer can rely on having
only two tab stories to deal with: either tabs work as some amount of
whitespace, or there aren't any tabs at all. Thus it might make sense
to retain these characters with the same semi-standard status. I don't
see how doing that would harm the rest of the characters proposal.
Since it says somewhere that implementations are allowed to support only
a subset of a registry, it would be valid to support only a subset of
the control-characters registry (format-effectors might be a better
name).
∂06-Mar-89 1449 X3J13-mailer Re: cs proposal and straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:49:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551645; Mon 6-Mar-89 17:44:45 EST
Date: Mon, 6 Mar 89 17:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: cs proposal and straw vote
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, baggins@ibm.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903021757.AA03241@defun.utah.edu>
Message-ID: <19890306224429.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 2 Mar 89 10:57:40 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
....
Why do we need CHAR-CODE-LIMIT, CODE-CHAR, and CHAR-CODE anyway?
While bits and fonts were in the standard, these were useful for
things like creating a character with the same code but different bits
or font attributes, but now that's out. If we want a function to use
for hashing characters, that's what CHAR-INT is for. The only other
use I can think of is supporting iteration over characters, and it
seems like this could be extremely inefficient in implementations that
support user-defined character sets. (In such a case, I would imagine
that one would make CHAR-CODE-LIMIT correspond to the limit imposed by
the representation, perhaps the same as MOST-POSITIVE-FIXNUM, but in
actual practice, very few of those codes would have corresponding
characters.) I agree with Dan that we'd be better off having a
specialized iterator.
You left out the most obvious use, which is associating data of some
sort with characters by making an array indexed by char-code. I agree
that this will not be practical in implementations where CHAR-CODE-LIMIT
is very large.
I didn't really understand Dan's suggestion for a specialized iterator,
since in one paragraph he said it was premature to put in character
registries, then in the next paragraph he said there should be an
iterator that takes a character registry and executes the body for
each character in that registry.
I think that the char-code stuff needs to be retained to ease the writing
of applications that are portable between implementations with different
sets of implementation-defined character attributes. However, I would
probably not object strenuously to the removal of the char-code stuff
(I can't promise; I'd have to check with other Symbolians first) since
it could become an implementation-dependent extension.
Should we consider extending MAKE-STRING-OUTPUT-STREAM to take an
:ELEMENT-TYPE keyword?
That seems like a good idea. WITH-OUTPUT-TO-STRING also. An idea which
I slightly prefer is that WITH-OUTPUT-TO-STRING when no string argument
is provided and MAKE-STRING-OUTPUT-STREAM produce a stream that accepts
all characters and returns a string of some element-type that
accomodates all the characters that were actually output. This reflects
Symbolics current practice.
In fact Symbolics Genera will also widen a base-string provided as a
string argument to WITH-OUTPUT-TO-STRING into a general-string if
necessary. If we wanted to put that into the standard, that would be
great as the user would never have to worry about the element-type,
however if other implementors object I won't push it.
∂06-Mar-89 1538 X3J13-mailer Re: cs proposal and straw vote
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 6 Mar 89 15:37:53 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA12950; Mon, 6 Mar 89 18:35:51 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA15870; Mon, 6 Mar 89 18:33:59 EST
Message-Id: <8903062333.AA15870@mist.>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: x3j13@sail.stanford.edu
Subject: Re: cs proposal and straw vote
In-Reply-To: Your message of Mon, 06 Mar 89 17:44:00 -0500.
<19890306224429.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Mar 89 18:33:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Mon, 6 Mar 89 17:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I didn't really understand Dan's suggestion for a specialized iterator,
since in one paragraph he said it was premature to put in character
registries, then in the next paragraph he said there should be an
iterator that takes a character registry and executes the body for
each character in that registry.
It's actually very simple. I have doubts about putting registries in
at all, but IF we do decide to put them in there should be a way to
iterate over them.
∂06-Mar-89 1627 X3J13-mailer cs proposal straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 16:27:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551767; Mon 6-Mar-89 19:23:38 EST
Date: Mon, 6 Mar 89 19:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal straw vote
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@sail.stanford.edu>
In-Reply-To: <890222.120815.baggins@almvma>
Message-ID: <19890307002320.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is the official response from Symbolics to the 22 Feb 89
straw vote on the characters proposal.
The format in which this was presented makes it very difficult to
know what we're voting on. Fortunately, it's only a straw poll.
However, you need to be aware that we had to guess what exactly
we're voting on, and so the results of the straw poll might not
be too meaningful, if different participants made different guesses.
I would strongly suggest casting this material into a precise
and unambiguous form before the binding vote occurs. That could
save a great deal of discussion time and minimize the possibility
of perfectly good language features being voted down simply because
of the way they were presented. It's especially important not to
retain the current format, where things are discussed in three places
(the body of the proposal, the appendix, and the ballot) and the
three places contradict each other in significant ways.
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Yes. We will want to check the p.29 rules for implementation-dependent
character attributes carefully.
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
No. CHAR-INT is needed for hashing. CHAR-INT should be retained, but
INT-CHAR and its shadow in the COERCE function should be removed.
This issue is unrelated to the apparent primary goal of the proposal.
Issue: CHARACTER-TYPE-RESTRICTIVEC
Define BASE-CHARACTER as a subtype of STRING.
No. Yes to BASE-CHARACTER as a subtype of CHARACTER.
Standard characters are a subset of the base
characters.
Yes.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
No. Keep STANDARD-CHAR. A change here is unnecessary for the rest of
the proposal. Adding (CHARACTER :STANDARD) would be okay, not adding it
would also be okay.
Remove the semi-standard characters.
No. A change here is unnecessary for the rest of the proposal.
Issue: STRING-TYPE-RESTRICTIVE
Define STRING as a union type
Yes
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
Yes
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
Yes. This is already required by the requirement on storing
into arrays in general.
Extend the COERCE function to allow coercion from
base string to extended string.
No, this feature is already present in CLtL, since any sequence
type can be coerced to any other sequence type.
Issue: STRING-TYPE-ABBREVIATIONS
Yes.
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Define SIMPLE-STRING as a union type
Abstain. We want to understand the consequences of this better,
vis a vis the alternative of defining SIMPLE-STRING as a
particular type, either (AND SIMPLE-ARRAY GENERAL-STRING)
or (AND SIMPLE-ARRAY BASE-STRING).
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
Depends on the outcome of the previous.
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
Depends on the outcome of the previous. This is getting to
be too many names.
Issue: FILE-EXTERNAL-REPRESENTATION
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Approved in principle, but the name is too long.
Issue: CHAR-CODE-NON-PORTABLE
Add CHAR-CCS-VALUE function
Approved in principle, but the name is too long, uses an unmotivated
abbreviation "ccs", and is not consistent with the name of the OPEN
keyword. Although they don't do exactly the same thing (the OPEN
keyword can specify multiple coded character sets and a protocol
for switching among them), they are related enough that the names
should express their relation.
This issue is unrelated to the apparent primary goal of the proposal.
For both of the above, the main naming problem seems to be to keep
clear the distinction between these and CHAR-CODE. How about
CHAR-EXTERNAL-CODE for the function name and :EXTERNAL-CODE for
the OPEN keyword? These aren't the best names in the world, but
they are an improvement, maybe someone else can think of something
better.
Also this seems to be an incomplete set of facilities. Conversion
of characters to external codes is provided, but not the inverse.
Conversion between internal and external encodings is bundled with
stream I/O, but not available on its own; there could be functions
that convert a string to/from a vector of integers under a specified
"external-coded-character-format".
Issue: STRING-BINARY-WIDTH
Add EXTERNAL-CODED-STRING-LENGTH function
No. The meaning of what this returns is too implementation-dependent
and the need for this has not been shown. If this is retained, the name
should be consistent with the names of the preceding two facilities.
This issue is unrelated to the apparent primary goal of the proposal.
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Introduce the concept of Registries
We incline towards yes, except that the relation to ISO work has not
been made clear. In particular, how can registries be used before the
putative ISO committee is formed and completes its work?
Standardize on #\registry:id
Yes, assuming we guessed correctly what this was supposed to mean.
add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Yes to one, no to the other. The second name is better.
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
Yes to these three.
New syntax for CHARACTER type specifier
New argument to CHARACTERP
No, the need for these has not been shown. Why not
call the CHAR-REGISTRY-NAME function?
New #\label:registry character name syntax
No, contradicts #\registry:id just above.
Is this issue unrelated to the apparent primary goal of the proposal?
That's the big question, isn't it? A more constructive way to put the
question is, how would a program make use of character registries to
access portably characters outside of the 96 characters that all Common
Lisp implementations must have? The proposal appears to be completely
silent on that point. We think we know how character registries would
actually be very useful for that. However, instead of counting on the
reader to guess the usefulness of character registries, the proposal
should contain some examples. If the character committee can't come up
with any examples, then perhaps character registries aren't really
needed.
∂06-Mar-89 1714 X3J13-mailer Review schedule reminder
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 17:13:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551816; Mon 6-Mar-89 20:11:10 EST
Date: Mon, 6 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Review schedule reminder
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271052.AA15941@decwrl.dec.com>
Message-ID: <19890307011058.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 27 Feb 89 05:31
From: chapman%aitg.DEC@decwrl.dec.com
Please let me know if you have any trouble accessing or reviewing this
information.
I am not equipped to do anything with the tex source files you've been
mailing out. So far I have been unable to open a network connection
to hudson.dec.com to access the dvi file.
∂07-Mar-89 0254 X3J13-mailer clarification
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 02:54:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06496; Tue, 7 Mar 89 02:52:25 PST
Message-Id: <8903071052.AA06496@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06496; Tue, 7 Mar 89 02:52:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Mar 89 05:47
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: clarification
In Symbolics' vote, Moon mentioned that he wasn't willing to vote on the
sections on the letter ballot because he was afraid they would be cast
in concrete. I should have made it more clear that these sections can
be changed, via clean-up, after they have been voted on.
I am trying to get incremental closure on the standard, just as one would
stop gratuitous changes on software being developed in a large system
a few modules at a time. That never means that the modules originally
"fixed" will not be subject to change if the whole system doesn't work!
Please do not be afraid to spend time reviewing these sections now and
commenting if there are problems. Even if the volume of reading looks
large, imagine how large it will look in a few months when you have
over 1000 pages to review.
Please review and vote!!!
kc
∂07-Mar-89 1334 X3J13-mailer hotel for march meeting
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 13:34:03 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03677g; Tue, 7 Mar 89 13:27:16 PST
Received: by challenger id AA28084g; Tue, 7 Mar 89 13:22:41 PST
Date: Tue, 7 Mar 89 13:22:41 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072122.AA28084@challenger>
To: x3j13@sail.stanford.edu
Subject: hotel for march meeting
I have reserved rooms for X3J13 but it is up to you to make your personal
reservations.
---jan---
∂07-Mar-89 1403 X3J13-mailer Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:03:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03717g; Tue, 7 Mar 89 13:56:36 PST
Received: by challenger id AA28137g; Tue, 7 Mar 89 13:52:01 PST
Date: Tue, 7 Mar 89 13:52:01 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072152.AA28137@challenger>
To: x3j13@sail.stanford.edu
Subject: Agenda DRAFT
X3J13 Committee Meeting Agenda DRAFT
March 28 - 30, 1989
Fairfax, VA
1 Call to Order, Tuesday, March 28, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Cleanup Subcommittee Report, Larry Masinter
7 Coffee Break 10:30
8 Cleanup Subcommittee Report continuation
9 LUNCH 12:00
10 Cleanup Subcommittee Report continuation
11 Recess, 5:00pm
12 Call to Order, Wednesday, March 29, 9:00am
13 Character Subcommittee Report, Thom Linden (4 hours)
14 Coffee Break 10:30am
15 Character Subcommittee Report continuation
16 Lunch 12:00
17 Character Subcommittee Report continuation
18 Compiler Subcommittee Report, Sandra Loosemore (2 hours)
19 Break 3:00
20 Compiler Subcommittee Report continuation
21 Recess 5:00
22 Call to Order, Thursday, March 30, 9:00am
23 Editorial Subcommittee Report, Kathy Chapman (1.5 hours)
24 Coffee Break 10:30
25 Cleanup Subcommittee Report continuation
26 Lunch 12:00
27 Cleanup Subcommittee Report continuation
28 Break 3:00
29 Cleanup Subcommittee Report continuation
30 Adjournment 5:00pm
∂07-Mar-89 1429 X3J13-mailer registration list
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:29:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03769g; Tue, 7 Mar 89 14:22:28 PST
Received: by challenger id AA28211g; Tue, 7 Mar 89 14:17:54 PST
Date: Tue, 7 Mar 89 14:17:54 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072217.AA28211@challenger>
To: x3j13@sail.stanford.edu
Subject: registration list
X3J13 Attendee Information
03/07/89
Name Institute Paid L1 L2 L3
David Bartley TI -0- y y y
Paul Beiser HP -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Kathy Chapman DEC -0- - - -
Jeff Dalton University of Ediburgh -0- y y y
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI 50.00 y y y
Masayuki Ida Aoyama Gakuin University -0- y y
Gregor Kiczales Xerox Corp. -0- y y y
Dieter Kolb Siemans -0- y y y
Tim Koschmann Xerox -0- y y y
Aaron Larson Honeywell S&RC -0- y y y
Kevin Layer Franz, Inc. 50.00 y y y
Thom Linden IBM 50.00 y y y
David Loeffler MCC 50.00 y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines 50.00 y y y
Larry Masinter Xerox Corp. -0- y y y
Robert Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Cris Perdue Sun Microsystems -0- y y y
Dan Pierson Encore Computer -0- y y y
Kent Pitman Symbolics -0- y y y
Guy Steele Thinking Machines -0- y y y
Paul Tucker IBM -0- y y y
Walter van Roggen DEC -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂08-Mar-89 0523 X3J13-mailer Issue: PLUS-ABNORMAL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 05:22:59 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27292; Wed, 8 Mar 89 05:21:03 PST
Message-Id: <8903081321.AA27292@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA27292; Wed, 8 Mar 89 05:21:03 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Mar 89 08:20
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: PLUS-ABNORMAL
Sorry about that. Disregard that last issue. It should have been sent
to cl-cleanup.
∂08-Mar-89 0520 X3J13-mailer Issue: PLUS-ABNORMAL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 05:20:36 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27193; Wed, 8 Mar 89 05:18:36 PST
Message-Id: <8903081318.AA27193@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA27193; Wed, 8 Mar 89 05:18:36 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Mar 89 08:18
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: PLUS-ABNORMAL
Issue: PLUS-ABNORMAL
References: +, ++, +++ (p. 325)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
Problem Description:
The description of +, ++, and +++
does not mention the possibility of abnornal termination of
the evaluation of the variable {\tt +}.
Are the values associated with {\tt ++},
and {\tt +++} are updated?
Proposal (PLUS-ABNORMAL:UPDATE)
If the evaluation of the variable {\tt +} is aborted for some reason,
then the values associated with {\tt ++},
and {\tt +++} are updated.
Rationale:
This clarification is primarily to establish the contents of these
variables in all cases.
Current Practice:
VAX Lisp updates the values.
Adoption Cost:
?
Benefits:
Disambiguity.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂08-Mar-89 1649 X3J13-mailer February 21 Ballot
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 16:49:01 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA05400g; Wed, 8 Mar 89 16:42:11 PST
Received: by challenger id AA00614g; Wed, 8 Mar 89 16:37:36 PST
Date: Wed, 8 Mar 89 16:37:36 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903090037.AA00614@challenger>
To: x3j13@sail.stanford.edu
Subject: February 21 Ballot
Here is Lucid's vote. There are two conditional acceptances. One is
because several of us are rewriting the error terminology yet again.
The other is section 6.1 where I want to look at the notation
introduced there once more. Also, there are some minor problems with
the rest of the section, (for example, fill pointers and pathnames
should be described somewhere else.) The sections on CLOS (1.8, 2.3,
2.4, 2.5) were put together by Kathy, Linda DeMichiel, and me, so I
think they're ok from the CLOS committee's point of view.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
-rpg-
∂08-Mar-89 1741 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 17:41:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553455; Wed 8-Mar-89 20:38:11 EST
Date: Wed, 8 Mar 89 20:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Feb. 21 Letter Ballot: editorial issues
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <19890306214441.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890309013751.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'd like to change the Symbolics vote, since you told me two things
that none of us here knew before: that there will be an opportunity
for cleaning up these sections even after they are voted in now, and
that the CLOS sections had already been carefully reviewed by Gabriel
and that Gregor had said he was satisfied with them. As a result,
we're changing our vote on sections 2.3, 2.4, and 2.5 from I to Y.
The other three I votes should remain. For ERROR-TERMINOLOGY because
it seems to be actively changing, for section 1.8 because the section
is sketchy, and for section 6.1 because we haven't really understood
it yet. Section 6.1 looks fundamental, do you think it's important
to get a vote on it as soon as possible? If so, we at Symbolics could
try to concentrate our efforts there.
I'd also like to clarify the meaning of this paragraph of our reply:
The five numbered sections: We approve these in principle, but aren't
ready to cast them in concrete. We haven't had time to review them with
the extreme care warranted for a language standard, and don't know who
else, if anyone, has reviewed them that thoroughly.
This was certainly not meant to give the impression that we were
refusing to review this stuff! The problem is simply that except for
Pitman, who is on the editorial committee, no one here had seen any of
this before two weeks ago. Also as it happens it is an extremely busy
time for us right now. Two weeks would not enough time for a really
careful review even in slack times, but at the time it was impossible.
I personally plan to try to review the entire standard carefully, as
well as to browbeat several other people at Symbolics into doing careful
review of either the entire standard or selected sections for their
areas of expertise. That will take a significant amount of time, of
course, probably several months.
∂09-Mar-89 1340 X3J13-mailer Issue: SUBSETTING-POSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:40:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554074; Thu 9-Mar-89 16:37:07 EST
Date: Thu, 9 Mar 89 16:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBSETTING-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902200927.AA06837@decwrl.dec.com>
Message-ID: <19890309213655.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support SUBSETTING-POSITION:NONE. I think that subsets are
a good idea, but I also think that the X3J13 process has no
chance at all of coming up with a subset that is useful to
anyone in the time available. Therefore I think the standard
should propose no subsets, but should not contain any statement
(unlike, I think, Ada) to the effect that subsets are forbidden
or a bad idea.
∂09-Mar-89 1345 X3J13-mailer Issue: EXTENTIONS-POSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:45:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554086; Thu 9-Mar-89 16:42:43 EST
Date: Thu, 9 Mar 89 16:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTENTIONS-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902242224.AA13754@decwrl.dec.com>
Message-ID: <19890309214233.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor EXTENSIONS-POSITION:DOCUMENTATION.
I oppose EXTENSIONS-POSITION:DISABLE because it mandates a
particular development environment feature, but Common Lisp
has avoided saying anything about development environments
since that is an area of extreme controversy.
Gabriel's position of standing mute would be okay with me.
∂09-Mar-89 1349 X3J13-mailer Issue: MACRO-AS-FUNCTION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:49:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554092; Thu 9-Mar-89 16:46:30 EST
Date: Thu, 9 Mar 89 16:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-AS-FUNCTION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242236.AA14651@decwrl.dec.com>
Message-ID: <19890309214619.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Why don't we just change PROG1 and PROG2 to functions, now that
we have clarified that functions evaluate their arguments in
left-to-right order?
∂09-Mar-89 1350 X3J13-mailer Issue: UNSOLICITED-MESSAGES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:50:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554094; Thu 9-Mar-89 16:47:35 EST
Date: Thu, 9 Mar 89 16:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14750@decwrl.dec.com>
Message-ID: <19890309214725.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS is okay.
∂09-Mar-89 1352 X3J13-mailer Issue: UNSPECIFIED-DATATYPES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:52:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554096; Thu 9-Mar-89 16:49:52 EST
Date: Thu, 9 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSPECIFIED-DATATYPES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14708@decwrl.dec.com>
Message-ID: <19890309214942.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose UNSPECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED
on the grounds that it is unnecessary and that the problem it's
attempting to address (making it possible to check conformance
by machine) is impossible to solve.
∂09-Mar-89 1357 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:57:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554101; Thu 9-Mar-89 16:55:10 EST
Date: Thu, 9 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-SYNTAX (Version 4)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271015.AA14142@decwrl.dec.com>
Message-ID: <19890309215459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose EXTRA-SYNTAX:NO. The rationale says
It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.
I can't see what's hard about detecting use of additional syntax not
specified -- that seems to be the easiest to detect of any
nonconformance. To take the canonical example of extending IF to allow
more than three subforms, surely it is very easy for a
program-analyzing-program to detect an invocation of IF with more than
three subforms and complain that the program is non-conforming.
∂09-Mar-89 1406 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 14:06:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554109; Thu 9-Mar-89 17:03:09 EST
Date: Thu, 9 Mar 89 17:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271016.AA14193@decwrl.dec.com>
Message-ID: <19890309220257.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose both proposals. The adoption cost is:
Implementors will be required to determine which parts of their
implementations are conforming and which parts aren't. Implementors
will have to provide a candidate list of exceptions to the editorial
committee.
The second sentence strikes me as a lot of extra work that will just
delay closure on the standard.
The stated benefits are:
It will be more possible to write portable programs. Also, future
standards will be less likely to make changes that are incompatible
with current implementations.
I don't believe in the first benefit. This issue does not affect the
ability to write portable programs in any significant way. It only
affects whether particular implementations are more or less useful as
development tools for checking conformance. I believe that development
tools for checking conformance are a valuable item for which market
demand exists, but are not within the purview of X3J13.
The second benefit is true. However there are a large number of other
ways that future standards could be incompatible with current
implementations, none of which have been ruled out. For example, any
implementation that makes symbols accessible to the USER package other
than symbols in the LISP package risks name conflicts with future
additions to the LISP package. It's simply a fact of life that any
extension might be incompatible with an eventual standard; pioneers can
never be sure that everyone will follow in their exact footsteps.
∂09-Mar-89 1433 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Mar 89 14:33:19 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA06700g; Thu, 9 Mar 89 14:26:23 PST
Received: by challenger id AA02174g; Thu, 9 Mar 89 14:21:48 PST
Date: Thu, 9 Mar 89 14:21:48 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903092221.AA02174@challenger>
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-SYNTAX (Version 4)
The rationale says:
``It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.''
In fact the error terminology says this about extending the syntax
when it's allowed:
``Implementations are permitted to define unambiguous extensions to
the syntax of the construct being described. No conforming code can
depend on this extension. Implementations are required to document
each such extension. All conforming code is required to treat the
syntax as meaningless.''
Thus, the only syntactic extensions allowed would be those that
program analysis programs could detect.
There are some cases where we wish to disallow extensions and some
cases where we don't care. DEFCLASS is an example of one place we wish
to keep people away from. If there are vastly more places where we
don't care, that should be the default. I think it would take a
careful editorial process to decide whether it's easier to defaultly
allow or defaultly disallow. I think this issue is quite different
from that of extensions in general.
-rpg-
∂09-Mar-89 1539 X3J13-mailer Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Mar 89 15:39:49 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA04997; Thu, 9 Mar 89 16:37:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10028; Thu, 9 Mar 89 16:37:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903092337.AA10028@defun.utah.edu>
Date: Thu, 9 Mar 89 16:37:28 MST
Subject: Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
To: chapman%aitg.dec@decwrl.dec.com
Cc: x3j13@sail.stanford.edu,
David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 9 Mar 89 16:49 EST
I agree with Moon. Leaving the behavior undefined gives an
implementation permission to do anything it wants, including starting
WWIII. "Anything" ought to include defining some useful behavior for
the situation, such as asking me if I really want to launch the
missiles.
-Sandra
-------
∂12-Mar-89 1616 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 89 16:16:40 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555408; Sun 12-Mar-89 19:14:06 EST
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14750@decwrl.dec.com>
Message-ID: <890312191349.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case. In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
This is the issue which I expected to `fix' this problem, and it does
not. In fact, its suggestion that it's ok to type such messages on
*TERMINAL-IO* may actually encourage what I consider to be an abominable
practice.
I would like it stated clearly that in the `normal situation' no
LISP function is permitted to do I/O unless the manual expressly
permits it.
Further, I think the current proposal permitting unsolicited messages
to go to *TERMINAL-IO* is a bad idea. I don't think unsolicited messages
should ever go directly to *TERMINAL-IO*. I am ammenable to them going to
documented streams which happen to have initial values that are synonym
streams to *TERMINAL-IO*, but
- I -don't- want them to be the standard CL streams, so I don't redirect
them by accident.
- I -do- want them to not be *terminal-io* so I can redirect them on
purpose.
Conceivably we could actually make a *JUNK-OUTPUT* which is initially a
synonym stream to *TERMINAL-IO*, but which is specially permitted to be
NIL to mean don't send the output anywhere, and we should say that all
unsolicited I/O has to go through there.
∂13-Mar-89 0714 X3J13-mailer cl-compiler mail
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:14:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA16287; Mon, 13 Mar 89 08:12:01 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02044; Mon, 13 Mar 89 08:11:59 -0700
Date: Mon, 13 Mar 89 08:11:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131511.AA02044@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: cl-compiler mail
I will be sending out the remaining batch of cl-compiler issues today.
I will also put FTP'able copies on host cs.utah.edu in directory
~ftp/pub/cl-compiler/pending. I'll send out a summary of issues when
I've gotten through them all.
It may be necessary for us to bring revised versions of some of these
proposals to the meeting. In particular, a few of them have been put
together at the last minute and haven't been reviewed thoroughly yet;
I've marked these as drafts so you'll be able to identify them. Any
comments or questions should be directed to cl-compiler@sail.stanford.edu.
-Sandra
∂13-Mar-89 0747 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:47:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17004; Mon, 13 Mar 89 08:44:52 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02070; Mon, 13 Mar 89 08:44:48 -0700
Date: Mon, 13 Mar 89 08:44:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131544.AA02070@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue LOAD-TIME-EVAL (passed)
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Category: CLARIFICATION
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
V3, 10 Feb 1989, Sandra Loosemore (new proposal)
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
with other pending proposals)
Status: Ready for release
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
The two proposals presented below present a simple model of the
compilation process. A minimal compiler could be implemented to
perform a code walk to apply the indicated transformations to the
function source code. Of course, most compilers will perform other
transformations as well, such as translating the Lisp source code into
a representation that is more compact or which can be executed more
efficiently.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls appearing lexically within the function have
already been expanded and will not be expanded again when the
function is called. (See CLtL p. 143.) The process of
compilation effectively turns MACROLET and SYMBOL-MACROLET
constructs into PROGNs with all instances of the local macros
in the body fully expanded.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within
the function are to be treated as lexical or special.
- COMPILER-LETs nested lexically within the function will not bind
any variables when the function is called (CLtL p. 112). Again,
the process of compilation effectively turns COMPILER-LET
constructs into PROGNs with all macros in the body fully expanded.
- Lexically nested EVAL-WHENs have been processed as stated in
proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
an implicit PROGN or as the constant NIL.
- If the function contains lexically nested LOAD-TIME-VALUE forms,
these have already been pre-evaluated and will not be evaluated
again when the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for functions that are
not COMPILED-FUNCTIONs to satisfy the above criteria.
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It assigns some specific properties to compiled functions. Users would
be able to rely on any function which is of type COMPILED-FUNCTION having
really been (at least partially) compiled.
It also states what many people believe to be the minimum functionality
required of a compiler.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN-COMPILE:
(1) Clarify that functions produced by COMPILE, or defined in a file
produced by COMPILE-FILE which has been subsequently LOADed, must
satisfy the same requirements listed in section (1) of proposal
TIGHTEN.
(2) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It also states what many people believe to be the minimum functionality
required of a compiler.
However, it allows functions that have not been compiled also to be of
type COMPILED-FUNCTION. For implementations that do not use different
representations for interpreted and compiled functions, it would still
allow COMPILED-FUNCTION and FUNCTION to be synonymous, even if
interpreted functions do not satisfy the requirements for compilation.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation. It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.
Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
Cost to implementors:
Unknown, but probably small for either proposal. Proposal
TIGHTEN-COMPILE is probably most consistent with current practice.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One use of the COMPILED-FUNCTION type is in declarations. A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION. However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION. Both of the proposals presented require COMPILE
and COMPILE-FILE to construct compiled functions.
Sandra Loosemore says:
I have a marginal preference for proposal TIGHTEN-COMPILE, since it
gives implementors more flexibility. To me it's more important that
COMPILE and COMPILE-FILE be guaranteed to do something, than that I
be able to test whether a function has had those things done to it.
∂13-Mar-89 0749 X3J13-mailer issue COMPILER-VERBOSITY, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:48:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17056; Mon, 13 Mar 89 08:46:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02078; Mon, 13 Mar 89 08:46:42 -0700
Date: Mon, 13 Mar 89 08:46:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131546.AA02078@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-VERBOSITY, version 6
Forum: Compiler
Issue: COMPILER-VERBOSITY
References: CLtL p. 438-329; 426
issue COMPILER-DIAGNOSTICS
Category: ENHANCEMENT
Edit History: V1, 25 Oct 1988, Sandra Loosemore
V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
V5, 06 Jan 1989, Sandra Loosemore (update discussion)
V6, 26 Jan 1989, Sandra Loosemore (remove USE-CONDITIONS)
Status: Ready for release
Problem Description:
Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE. In some situations, it would be useful to control
how much information is printed.
Proposal COMPILER-VERBOSITY:LIKE-LOAD:
Introduce special variables, *COMPILE-VERBOSE* and *COMPILE-PRINT*,
with implementation-dependent initial values.
Add :VERBOSE and :PRINT keyword arguments to the function
COMPILE-FILE, analogous to those for the function LOAD.
The :VERBOSE argument (which defaults to the value of
*COMPILE-VERBOSE*), if true, permits COMPILE-FILE to print a message
in the form of a comment to *STANDARD-OUTPUT* indicating what file is
being compiled and other useful information.
The :PRINT argument (which defaults to the value of *COMPILE-PRINT*),
if true, causes information about top-level forms in the file being
compiled to be printed to *STANDARD-OUTPUT*. Exactly what is printed
will vary from implementation to implementation, but nevertheless some
information will be printed.
Introduce a special variable *LOAD-PRINT*, which has an initial value of
NIL. State that the default value of the :PRINT argument to LOAD is
*LOAD-PRINT* (rather than NIL).
Rationale:
This proposal makes COMPILE-FILE behave like LOAD. There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).
Adding the *LOAD-PRINT* variable allows the printing of messages by
LOAD to be controlled either on a global or a per-call basis.
Current Practice:
COMPILE-FILE prints out progress messages in nearly all
implementations.
Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".
On the TI Explorer, COMPILE-FILE displays the name of the function
being compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true. (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)
Symbolics Cloe already has a *LOAD-PRINT* variable.
Cost to implementors:
This is an incompatible change for some implementations. While the
changes required should be conceptually simple, their implementation
may involve a significant amount of grunt work. At least two
implementations already provide some similar mechanism for suppressing
messages.
Cost to users:
Some (non-portable) user code may break in implementations where this
is an incompatible change.
No user code should be broken by the addition of the *LOAD-PRINT*
variable, since the default behavior for the :PRINT keyword to LOAD
is unchanged.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Discussion:
This issue addresses an extension to the language. If this proposal
is not accepted, the standard will simply continue not to say anything
about whether COMPILE-FILE can print progress messages, or what stream
such messages are directed to.
∂13-Mar-89 0748 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 9
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:48:14 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17028; Mon, 13 Mar 89 08:46:02 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02075; Mon, 13 Mar 89 08:45:59 -0700
Date: Mon, 13 Mar 89 08:45:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131545.AA02075@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-DIAGNOSTICS, version 9
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
V9, 26 Jan 1989, Sandra Loosemore (simplify)
Status: Ready for release
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
of WARNING.
(2) Clarify that ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation that "is an error" would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) The compiler is permitted to signal diagnostics about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation. State that
both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler. If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it. If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.
(4) Specify that COMPILE-FILE returns two values. The first value
is the truename of the output file, or NIL if the file could not be
created. The second value is T if the file was compiled without
errors, or NIL if errors were signalled during compilation.
Rationale:
Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.
Requiring any condition handlers established by the compiler to resignal
the condition before proceeding with any implementation-specific action
gives user error handlers a chance to override the compiler's default
behavior. For example, the user error handler could invoke a restart
such as ABORT or MUFFLE-WARNING.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire compilation if it is not feasible to abort a
smaller part.
Requiring a second success-p value to be returned from COMPILE-FILE
gives the user some indication of whether there were serious problems
encountered in compiling the file.
Test Case/Example:
Here is an example of how COMPILE-FILE might set up its condition
handlers. It establishes an ABORT restart to abort the compilation
and a handler to take implementation-specific action on ERROR
conditions. Note that INTERNAL-COMPILE-FILE may set up additional
ABORT restarts.
(defvar *output-file-truename* nil)
(defun compile-file (input-file &key output-file)
(let ((*output-file-truename* nil)
(errors-detected nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((error #'(lambda (condition)
(setq errors-detected t)
(signal condition)
...)))
(internal-compile-file input-file output-file)))
(values *output-file-truename*
errors-detected)))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
∂13-Mar-89 0815 X3J13-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:15:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17983; Mon, 13 Mar 89 09:12:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02083; Mon, 13 Mar 89 09:12:49 -0700
Date: Mon, 13 Mar 89 09:12:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131612.AA02083@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
Forum: Compiler
Issue: CONSTANT-COMPILABLE-TYPES
References: CLtL pp. 56, 77-80, 324
Issue CONSTANT-MODIFICATION
Issue CONSTANT-CIRCULAR-COMPILATION
Issue CONSTANT-ARRAY-ATTRIBUTES
Issue QUOTE-SEMANTICS
Issue LOAD-OBJECTS
Category: CLARIFICATION, ADDITION
Edit history: 11/07/88, V1 by Cris Perdue
11/14/88, V2 by Cris Perdue
11/22/88, V3 by Cris Perdue
12/20/88, V4 by Cris Perdue
01/06/89, V5 by Sandra Loosemore (minor editorial
clarifications, expand discussion)
03/05/89, V6 by Cris Perdue (more response to comments,
especially from Moon and and from Loosemore)
03/05/89, V7 by Loosemore (more editorial tweaks)
03/13/89, V8 by Loosemore (discussion)
Status: Ready for release
Problem description:
CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there is to be between the
constant passed to the compiler and the one that is established by
compiling and then loading its file. Relevant remarks in CLtL
concerning file compilation and the definition of QUOTE suggest that
the compiler handles constants in ways that are not actually possible.
Introduction to the proposal:
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear. Unless stated otherwise, in this proposal where the term
"constant" is used, it means a quoted or self-evaluating constant, not
a named (defconstant) constant.
The key is a definition of a form of equivalence between Lisp objects,
"similarity as constants". Code passed through the file compiler and
then loaded must behave as though quoted constants in it are "similar"
to quoted constants in the corresponding interpreted "source" code.
Because it is legitimate to compile in one address space and load into
a different one, it is necessary for the constraints to be defined
across address spaces. This proposal only concerns quoted constants
to be processed by COMPILE-FILE. Some other issues related to file
compilation are CONSTANT-COLLAPSING, CONSTANT-CIRCULAR-COMPILATION,
and QUOTE-SEMANTICS.
Some implementations "lose information" about some constants during
compilation. Typically all constant arrays become simple arrays
during the process of compiling and loading. We try to balance the
desire for more functionality against the effort required from
implementors.
Comments within the text of the proposal are enclosed in double angle
brackets, <<like this>>.
Proposal: CONSTANT-COMPILABLE-TYPES:SPECIFY
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original. Treatment of uninterned symbols must be consistent across
the entire file as described below. There also is a constraint on
arrays which is not symmetrical; compilation can make arrays
"simpler", but not "less simple". (See below for the definition.)
We refer below to "quoted constants" or just "constants". In this
section these terms refer to objects appearing in expressions of the
form (QUOTE <object>), to objects used as self-evaluating forms, and
to objects appearing in code at locations described as "not
evaluated".
Some types such as streams are not supported in constants. Put
another way, an object containing one of these is not considered
similar as a constant to any other object. Some implementations may
support them and define how they are treated. For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
Of the types supported in constants, some are treated as aggregate
objects. For these types, being similar as constants is defined
recursively. We say that an object of these types has certain
attributes, and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.
This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself. We
use the idea of depth-limited comparison, and say that two
objects are similar as constants if they are similar at all finite
levels. This idea is implicit in the definitions below, and applies
in all the places where attributes of two objects are required to be
similar as constants.
Here we define the notion of two objects being "similar as constants",
organizing the definition by type, and note additional constraints
that the compiler and loader working together must meet:
Number
If either of the two objects is a number, both must be of the same
type and must represent the same mathematical value.
Character
If either of the two objects is a character, both must be character
objects that represent the same character. <<Note that this
definition has to depend on the results of the Character Set
proposals.>>
Random-state
Let us say that two random-states are functionally equivalent if
applying RANDOM to them repeatedly always produces the same
pseudo-random numbers in the same order.
Two random-states are similar as constants exactly if copies of them
made via MAKE-RANDOM-STATE are functionally equivalent.
Note that a constant random-state object cannot be used as the "state"
argument to the function RANDOM (because RANDOM side-effects this
data structure).
Symbol
A symbol can only be similar to a symbol. References to interned
symbols are "by name". <<See issue COMPILE-FILE-SYMBOL-HANDLING for
details.>>
If a symbol is not interned, i.e. its home package is NIL, it is
treated in a rather special way. To be similar as a constant to
another symbol, both symbols must be uninterned and have the same
name.
Constants that contain uninterned symbols have to satisfy an extra
constraint. Consider the set of places in a constant that refer to
the same (EQ) uninterned symbol. In any similar constant, the
corresponding places must also all be EQ -- no more places and no
fewer. Moreover, COMPILE-FILE must arrange for the EQness of all
constant uninterned symbols that appear in the file to be preserved,
even if they are referenced in separate constants.
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
Package
A package can only be similar as a constant to a package. References
to packages are permitted in any constant. References to packages are
"by name": two packages are similar as constants when their names are
similar as constants. Within a Lisp "address space", packages with
the same name are EQ.
At load time, the package becomes the same as returned by
FIND-PACKAGE, given the package name. An error is signalled if no
package of that name exists at load time.
AGGREGATE TYPES
---------------
For each of the types listed below, if either object is of the given
type, the two objects are similar as constants exactly if the other is
of that type and the values of all of the specified attributes are
similar as constants.
The attributes listed here can be called the "Basic Attributes" of
objects of each of these types.
Cons CAR, CDR.
Array For 1-dimensional arrays:
LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all legal indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
An array of type SIMPLE-ARRAY can only be similar as a
constant to an array of type SIMPLE-ARRAY. However, we
allow the file-compiler a bit of latitude here. Where
constants in source code are displaced, have fill
pointers, or are adjustable, constants in the code
resulting from compilation and loading are permitted to
lack any or all of these qualities.
Hash Table Keys and value pairs. The table's test is unchanged
also. If the file compiler is given a constant containing a
a hash table that has keys that are similar as
constants, the consequences are undefined.
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
Pathname Each pathname component.
OTHER TYPES
-----------
Stream, Compiled-Function, Readtable, Generic-function, Method
Objects of these types are not supported in compiled
constants.
Function Only function constants that are not compiled-functions
and do not close over any (lexical) variables are
supported in compiled constants.
Two such functions are similar as constants if their
SOURCE-LAMBDA-EXPRESSIONs are similar as constants.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
Examples:
If source code contains a constant that could PRINT as (#1=#:FOO
#2=#:FOO #1# #2#), the constant resulting from compiling and loading
that code would have to be PRINTable as (#1=#:FOO #2=#:FOO #1# #2#).
If we make a hash table H, set three variables A, B, and C to
different uninterned symbols named FOO, and enter keys and values as
follows:
(setf (gethash a h) b)
(setf (gethash b h) a)
(setf (gethash c h) c)
If H appears in a compiled constant, after compiling and loading it,
(let ((value (list)))
(maphash #'(lambda (x y) (push (list x y) value)) h)
value)
could print as
((#1=#:FOO #2=#:FOO) (#2# #1#) (#3=#:FOO #3#))
but not as
((#1=#:FOO #2=#:FOO) (#2# #3=#:FOO) (#3# #1#))
Rationale:
For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle. It
also attempts to leave room for implementations to differ. Some
implementations have made opposing choices because the language
doesn't specify one over the other. Some implementations already
handle constants that this proposal defines as not legal in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.
This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.
The proposal ensures that all references to the same uninterned symbol
within a file will all map to references to just one uninterned symbol
after compiling and loading. This is needed to support PCL.
Current practice:
>From Gail Zacharias (Nov 14): "Coral pretty much implements this
proposal (I think we currently coalesce hash table keys, but that's
just a bug that will be fixed). We also fasdump packages (using the
package name) and compiled functions (but not foreign functions). For
symbols, we dump the name, and if (roughly speaking) the symbol would
get printed with a package prefix, we also dump the package name and
load the symbol into that package (otherwise it gets loaded into the
current load-time package)."
>From David Gray (Nov 9): "The Explorer can compile constant functions,
read tables, and hash tables; an error is signalled for a stream. A
package object used to break the compiler but in release 5 it has been
fixed to generate instructions to call FIND-PACKAGE on the package
name at load time." (Nov 15): [The Explorer does not guarantee
retention of displaced-to and displaced-index-offset attributes.]
"The Explorer also does not currently support dumping closures (either
compiled or evaluated), although non-closure compiled functions can be
dumped."
>From David Moon (Jan 24): "Symbolics Genera current practice: aside
from some current bugs we have with circular structures of certain
types and with preserving the identity of CONSes under EQ, this is
more or less consistent with our current practice, if you made the
changes implied by my earlier comments. We preserve the :displaced-to
and :fill-pointer array attributes. I doubt that we do what the
proposal says for hash-tables, readtables, and random-states. We
support dumping compiled and interpreted functions, but not closures,
which in effect means we don't support dumping functions."
>From Sandra Loosemore (Mar 3): "UCL currently can handle only
constants that are of type number, character, symbol, cons,
simple-vector, or string (which it turns into simple-string). It
signals an error if an attempt is made to compile any other kind of
object as a constant."
Adoption cost:
Not known. Probably moderate or low -- for most implementations. The
cost would be to implementors rather than users since this part of the
language is currently underspecified. The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.
This proposal is close to compatible with the Franz, Lucid, Coral,
Texas Instruments, and Symbolics implementations. It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
Comparing functions semantically is intertwined with the specification
of what conforming programs and implementations are allowed to do.
This proposal does not attempt to do that since compiled functions are
not supported by this proposal in compiled constants.
The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.
Readtables need not be supported by an implementation. If a readtable
contains only symbols to represent functions, here is Cris Perdue's
suggested spec for similarity of readtables:
Character syntax type for each character in the table;
function for each readmacro character, mappings for
dispatch macros; whether terminating or nonterminating
for each readmacro.
Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances. The cleanup issue LOAD-OBJECTS deals with this.
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
The main point of disagreement on this proposal over its handling
of constant functions.
Sandra Loosemore says:
I plan to submit an amendment to this proposal which would remove the
requirement that the compiler be able to dump non-compiled, non-closed
functions. The reason for removing this requirement is that there is
no way to portably construct an object which is guaranteed to be a
non-compiled, non-closed function. Note that implementations are
permitted to make all functions COMPILED-FUNCTIONs.
Dick Gabriel says:
I guess I pretty strongly object to leaving functions out of the list
of constants that can appear in compiled code. The part that's
disturbing is that such non-Lispy things like arrays, hashtables, and
pathnames get better treatment than functions, the most Lispy part of
Common Lisp. I wonder how many implementations will be forced to come
within an inch of the required functionality to implement a first-rate
CLOS?
The specification of the subset of functions that are acceptable as
compiled constants cannot be tested for within Common Lisp itself.
I suggest we ask implementors (Lucid included) to bite the bullet and
handle this case correctly. Won't our grandchildren appreciate us
treating Common Lisp like Lisp and not like PASCAL?
If we were to specify that all functions could appear as constants, we
would also need to clarify whether the closed-over variable bindings
become immutable, and also deal with whether bindings that are closed
over more than one function retain their uniqueness. Also, the cost
to implementors to add support for dumping non-interpreted functions
may be quite high.
∂13-Mar-89 0821 X3J13-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:21:42 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18436; Mon, 13 Mar 89 09:19:31 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02090; Mon, 13 Mar 89 09:19:28 -0700
Date: Mon, 13 Mar 89 09:19:28 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131619.AA02090@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
Forum: Compiler
Issue: CONSTANT-CIRCULAR-COMPILATION
References: Issue CONSTANT-COLLAPSING
Issue QUOTE-SEMANTICS
Category: CLARIFICATION, ADDITION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 14 Nov 1988, Cris Perdue
V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
V6, 08 Feb 1989, Sandra Loosemore (replace FLAG with YES)
V7, 11 Mar 1989, Sandra Loosemore (error terminology)
Status: Ready for release
Problem Description:
CLtL does not specify whether constants containing circular or
recursive references may be compiled. It is also not clear whether
the compiler must preserve sharing of EQ substructures; that is, whether
subobjects that are EQ in the source code must remain EQ after being
compiled.
The proposals below apply to constants appearing in a file compiled by
COMPILE-FILE. If proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE
passes, then the same constraints would apply to all constants. The
minimal scope over which sharing would be required to be detected is
over a single call to EVAL or COMPILE.
In the proposals that follow, "preserving EQness" means that
subobjects that are EQ in the source code must remain EQ after being
compiled; that is, things don't get "less EQ" after compilation.
(Note that coalescing of constants implies that things may get "more
EQ".)
Proposal CONSTANT-CIRCULAR-COMPILATION:NO
State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled. State that
the compiler is not required to preserve EQness of substructures.
Rationale:
This proposal would not require any existing implementation to change.
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled. State that
the compiler is required to preserve EQness of substructures within a
file compiled with COMPILE-FILE.
Rationale:
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Some programs (such as PCL) have come to depend on COMPILE-FILE
preserving the EQness of uninterned symbols, and it is cleaner
to require sharing to be preserved in general instead of making
symbols be a special case. Requiring sharing to be preserved still
allows loaders to build constants bottom-up.
Proposal CONSTANT-CIRCULAR-COMPILATION:YES
State that objects containing circular references may legitimately
appear as constants to be compiled. State that the compiler is
required to preserve EQness of substructures within a file compiled
with COMPILE-FILE.
Rationale:
Users seem to expect this functionality, and some implementations
already provide it.
Current Practice:
A-Lisp preserves EQness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant. PSL and Utah Common Lisp both
get stuck in an infinite loop if an attempt is made to compile a
reentrant structure. The TI Explorer compiler is able to reproduce
recursive lists and arrays, but currently hangs in a loop on a
circular list. Neither the Explorer nor Symbolics Genera 7.x detects
EQness of list CDRs. Lucid handles circular constants correctly.
Franz uses a flag to control whether or not to attempt to detect
circular constants. KCL handles circular structures, but only detects
sharing of top-level structure (it does not traverse constants to look
for shared substructure).
Cost to implementors:
We know of no implementation that would have to change under proposal
NO.
For proposal YES, some implementations would require sweeping
changes; in some cases a completely different dumper/loader strategy
would have to be implemented.
The cost of proposal PRESERVE-SHARING-ONLY would fall somewhere in
between.
Cost to users:
The situation now is that programs which depend upon circularity or
sharing of substructure being preserved by the compiler are already
nonportable. Proposal NO simply formalizes the status quo. Proposal
YES would offer users functionality that is currently not portable.
Benefits:
An area of ambiguity in the language is removed.
Discussion:
The issue of compiler speed is largely a red herring on this issue;
the overhead of detecting circularities is generally quite small. The
main question is whether we should require some implementations to
completely redo their compiler/loader interface in order to support
circular constants.
It has been argued that any "serious" implementation will support
circular constants anyway, because of customer demand. However, since
there appears to be only one implementation (Lucid) that now
implements proposal YES in its full generality, perhaps the demand for
this feature is not really all that strong.
Earlier drafts of this writeup contained a proposal FLAG which would
have added a variable *COMPILE-CIRCLE*, similar to *PRINT-CIRCLE*.
However, there were unresolved problems about what would happen if the
value of this variable were altered within the file being compiled,
and it was generally agreed that this proposal didn't have any
particular advantages over proposal YES and just introduced
unnecessary hairiness.
Since it is usually fairly simple to detect circular constants,
Loosemore would support an amendment to proposals NO and
PRESERVE-SHARING-ONLY to change the first sentence to read:
State that the consequences are unspecified if an object containing
a circular reference appears as a constant to be compiled.
Implementations must either correctly handle the circular reference
or signal an error.
This is similar to the language which is already used in proposal
CONSTANT-COMPILABLE-TYPES:SPECIFY.
∂13-Mar-89 0824 X3J13-mailer issue CONSTANT-COLLAPSING, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:24:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18594; Mon, 13 Mar 89 09:22:09 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02093; Mon, 13 Mar 89 09:22:05 -0700
Date: Mon, 13 Mar 89 09:22:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131622.AA02093@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-COLLAPSING, version 5
Forum: Compiler
Issue: CONSTANT-COLLAPSING
References: CLtL p. 78, 87
Issue CONSTANT-MODIFICATION
Issue CONSTANT-COMPILABLE-TYPES
Issue EQUAL-STRUCTURE
Issue QUOTE-SEMANTICS
Category: CHANGE
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
V3, 03 Jan 1989, Sandra Loosemore
V4, 06 Jan 1989, Sandra Loosemore
V5, 11 Mar 1989, Sandra Loosemore
Status: Ready for release
Problem Description:
CLtL states that an implementation is permitted to "collapse" or
coalesce constants appearing in code to be compiled if they are EQUAL.
The definition of EQUAL does not permit coalescing of more general
isomorphic data structures (such as arrays and structures), which is
often desirable.
Issue QUOTE-SEMANTICS deals with whether coalescing may be performed
only by COMPILE-FILE, or by COMPILE and EVAL as well. If proposal
QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE passes, then coalescing could be
performed on all constants.
CLtL says: "An object is considered to be a constant in code to be
compiled if it is a self-evaluating form or contained in a QUOTE
form".
Proposal CONSTANT-COLLAPSING:GENERALIZE:
State the an implementation is permitted to coalesce constants
appearing in code to be compiled if they are equivalent under the
relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.
Rationale:
There is little reason why implementations should not be allowed to
perform more general collapsing of structures, since the arguments
against doing so also apply to collapsing of EQUAL structures, which
is already permitted. The arguments for coalescing of EQUAL structures
(primarily space reduction) also apply to coalescing of structures that
are equivalent under a more general coalescing predicate.
Current Practice:
Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example). Lucid Common Lisp also uses a more
general coalescing predicate than EQUAL.
Cost to implementors:
None. This extends the range of permitted behavior for
implementations but does not require any implementation to change.
Cost to users:
Programs that depend on objects not being coalesced except when they
are EQUAL may break under this proposal. The only way one would be
able to detect that coalescing has taken place is if objects that were
not EQ in the source file become EQ after compilation; accessors on
the objects would return the same values regardless of whether or not
coalescing has taken place.
Benefits:
Collapsing of isomorphic arrays may lead to significant memory savings
in some applications.
Discussion:
This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
Some people believe that if the definition of EQUAL weren't "broken",
there wouldn't be any need for this proposal.
There is no inherent reason why the "coalescing predicate" must be the
same as the relationship used by the compiler/loader to construct
equivalent copies of objects of constants, but making the same rules
be applied in both situations simplifies the language somewhat.
∂13-Mar-89 0840 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:40:09 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 11:34:05 EST
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <890312191349.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890313163525.7.BARMAR@OCCAM.THINK.COM>
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case.
Do progress notes in the wholine count as output? If not, why not? If
so, are you proposing that they be prohibited? In Genera, calling
COMPILE displays "Compiling <name>" in the wholine, and calling
READ-CHAR on a console stream displays "User Input" in the wholine. I
like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
I think market forces should be enough to prevent really silly
unsolicited messages, just as all serious Lisp implementations have a GC
even though CLtL never mentions it.
barmar
∂13-Mar-89 0834 X3J13-mailer issue LOAD-TIME-EVAL, version 11
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:34:06 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18990; Mon, 13 Mar 89 09:31:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02140; Mon, 13 Mar 89 09:31:50 -0700
Date: Mon, 13 Mar 89 09:31:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131631.AA02140@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue LOAD-TIME-EVAL, version 11
On this issue, we've come up with an improved version of the proposal that
was accepted at the January meeting.
Forum: Compiler
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
issue SHARP-COMMA-CONFUSION
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
21-Sep-88, Version 6 by Moon (stripped down)
17-Oct-88, Version 7 by Loosemore (change direction again)
30-Dec-88, Version 8 by Loosemore (tweaks)
23-Jan-89, Version 9 by Loosemore (amendments)
02-Mar-89, Version 10 by Loosemore (new proposal)
11-Mar-89, Version 11 by Loosemore
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Proposal R**2-NEW-SPECIAL-FORM was approved at the January 1989
meeting. After the meeting, some additional suggestions were made that
have been incorporated into proposal R**3-NEW-SPECIAL-FORM. The sections
of the two proposals that differ are marked with change bars in the margin.
Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
| performs normal semantic processing such as macro expansion but
| arranges for the evaluation of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, <form> is evaluated (by EVAL) in a null
lexical environment, and one value is returned. Implementations which
implicitly compile (or partially compile) expressions passed to
EVAL may evaluate the <form> only once, at the time this
compilation is performed. This is intentionally similar to the
freedom which implementations are given for the time of expanding
macros in interpreted code.
| Note that, in interpreted code, there is no guarantee as to when
| evaluation of <form> will take place, or the number of times the
| evaluation will be performed. Since successive evaluations of the
| same LOAD-TIME-VALUE expression may or may not result in an evaluation
| which returns a "fresh" object, destructive side-effects to the
| resulting object may or may not persist from one evaluation to the
| next. It is safest to explicitly initialize the object returned by
| LOAD-TIME-VALUE, if it is later modified destructively.
| Implementations must guarantee that each reference to a
| LOAD-TIME-VALUE expression results in at least one evaluation of its
| nested <form>. For example,
| (DEFMACRO CONS-SELF (X)
| `(CONS ,X ,X))
| (CONS-SELF (LOAD-TIME-VALUE (COMPUTE-IT)))
| must perform two calls to COMPUTE-IT; although there is only one
| unique LOAD-TIME-VALUE expression, there are two distinct references
| to it.
|
| In the case of a LOAD-TIME-VALUE form appearing in a quoted expression
| passed to EVAL, each call to EVAL must result in a new evaluation of
| <form>. For example,
| (DEFVAR X 0)
| (DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
| is guaranteed to increment X each time FOO is called, while
| (DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
| may cause X to be evaluated only once.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
The requirement that LOAD-TIME-VALUE expressions be evaluated once per
reference (rather than once per unique expression) prevents problems
that could result by performing destructive side-effects on a value
that is unexpectedly referenced in more than one place.
Proposal (LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
| performs its normal semantic processing (such as macro expansion and
| translation into machine code) on the form, but arranges for the
| execution of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, <form> is evaluated (by EVAL) in a null
lexical environment, and one value is returned. Implementations which
implicitly compile (or partially compile) expressions passed to
EVAL may evaluate the <form> only once, at the time this
compilation is performed. This is intentionally similar to the
freedom which implementations are given for the time of expanding
macros in interpreted code.
| If the same (compared with EQ) list (LOAD-TIME-VALUE <form>) is
| evaluated or compiled more than once, it is unspecified whether <form>
| is evaluated only once or is evaluated more than once. This can
| happen both when an expression being evaluated or compiled shares
| substructure, and when the same expression is passed to EVAL or to
| COMPILE multiple times. Since a LOAD-TIME-VALUE expression may be
| referenced in more than one place and may be evaluated multiple times
| by the interpreter, it is unspecified whether each execution returns
| a "fresh" object or returns the same object as some other execution.
| Users must use caution when destructively modifying the resulting
| object.
|
| If two lists (LOAD-TIME-VALUE <form>) are EQUAL but not EQ, their
| values always come from distinct evaluations of <form>. Coalescing
| of these forms is not permitted.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
Allowing multiple references to the same LOAD-TIME-VALUE expression
to result in only one interpretation allows it to be specified more
cleanly. It also allows interpreters that do not perform a prepass
to cache LOAD-TIME-VALUE expressions.
Current Practice:
This is an addition to the language and has not yet been implemented.
Cost to Implementors:
In compiled code, (LOAD-TIME-VALUE <form>) is similar to
'#,<form>. Most implementations can probably make use of the same
mechanism they use to handle #, to handle LOAD-TIME-VALUE. Note that
#, does not currently provide a mechanism for dealing with
non-read-only-ness.
Implementing LOAD-TIME-VALUE in the interpreter should be fairly
straightforward, since one simply needs to evaluate the <form> in the
null lexical environment. Implementations that use a preprocessing
code walk in the interpreter to perform macro expansion could process
LOAD-TIME-VALUE forms at that time.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Benefits:
Users are given a mechanism that to force evaluation to be delayed
until load time that does not rely on a feature of the reader.
Discussion:
Earlier versions (up to version 7) of this proposal stated that
all semantic processing of the LOAD-TIME-VALUE form should be postponed
until load time.
The semantics of LOAD-TIME-VALUE would be simplified considerably if
the READ-ONLY-P argument were removed and destructive operations on
the result of evaluating <form> prohibited. However, some people feel
that the ability to destructively modify the value is an essential
feature to include.
"Collapsing" of multiple references to the same LOAD-TIME-VALUE
expression could be allowed for read-only situations, but it seems
like it would be more confusing to make it legal in some situations
and not in others.
A number of other alternatives have been considered on this issue,
including:
- A proposal for a new special form that would force evaluation of
the <form> to happen only once. This was rejected because of
implementation difficulties.
- A proposal to add a function making the "magic cookie" used by #,
available to user code. The current proposal does not prevent such
a function from being added, but this approach appeared to have
less support than making the hook available as a new special form.
- A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).
- A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).
Kent Pitman says:
Although I'm willing to take multiple evaluation in the interpreter
as a compromise position, I would like it mentioned in the discussion
that this was only an expedient to getting this issue accepted at all,
and that I'm not really happy about it. I have said that I think a
number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
this -- for example) are due to the presence of interpreters which do
not do a semantic-prepass at a known time. If I had my way, we would
require a semantic pre-pass and we would then be able to forbid
multiple evaluations even in the interpreter.
Moon and Gray support proposal R**3-NEW-SPECIAL-FORM.
Pitman also expressed willingness to go along with
R**3-NEW-SPECIAL-FORM, but was somewhat concerned that coalescing
LOAD-TIME-VALUE results based on EQ-ness of the LOAD-TIME-VALUE form
could conceivably lead to trouble down the line. However, since he
could provide no actual examples to back up that worry, and since the
majority opinion was that some implementations would find a
restriction against such coalescing an undue burden, the decision was
made to just `note the concern' and proceed on. Sandra Loosemore and
JonL White concur with this position.
∂13-Mar-89 0853 X3J13-mailer issue COMPILER-VERBOSITY, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:53:16 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 11:48:42 EST
Date: Mon, 13 Mar 89 11:50 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-Id: <19890313165001.9.BARMAR@OCCAM.THINK.COM>
I see the benefit of :PRINT, but do we really need :VERBOSE? What's the
difference between
(compile path :verbose t)
and
(format t "~&Compiling file ~A...~%" path)
(compile-file path)
(format t "~&done.~%")
If any users want to have this controlled by a global variable, they can
do what we (Thinking Machines) did years ago and package it up in their
own function. At this stage of the game I don't see the need to add
gratuitous features like this.
:PRINT is less gratuitous because it implements a feature that the user
can't add himself.
barmar
∂13-Mar-89 0855 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:54:56 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555652; Mon 13-Mar-89 11:51:33 EST
Date: Mon, 13 Mar 89 11:51 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: barmar@Think.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, chapman%aitg.DEC@decwrl.dec.com,
x3j13@sail.stanford.edu
In-Reply-To: <19890313163525.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case.
Do progress notes in the wholine count as output? If not, why not? ...
No. They are passive. The function in question does not output to the
wholine. Rather, it arranges information such that a foreign process
can access it and display it. For example, if 500 calls to LOAD are done
in three second, you don't always get 500 progress messages. That is
because the output is done by the foreign process doing the polling and
not the process which is running the CL code. I think this distinction
is important. Indeed, if the running process could block, signal an
error, etc. due to problems in I/O then it would not be a good idea.
If so, are you proposing that they be prohibited?
No.
In Genera, calling
COMPILE displays "Compiling <name>" in the wholine, and calling
READ-CHAR on a console stream displays "User Input" in the wholine.
No. COMPILE does no display. A foreign process which is working by polling
does. This is no different than a foreign process doing any kind of
debugging activity.
I like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
I don't think it's that difficult.
In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
Maybe it's because C people have traditionally been willing to settle
for less. :-) Seriously, I think it's a clear hole in their standard.
People would probably flame if things that weren't documented as doing
I/O were to suddenly start doing it.
I think market forces should be enough to prevent really silly
unsolicited messages,
Really I don't. COMPILE is a notable offender. Real implementations have
been known to print "Compiling FOO." on *TERMINAL-IO* and this proposal
does not forbid it.
In some cases, market pressure can --- after some number of months --
get things back in line. In others, implementors just point to the standard
and either say "it doesn't say anything" or even worse suggest that the
reason it doesn't say it is because it wants to leave room.
Not all implementors come from our culture. Often, those that don't
would -prefer- to have little `hints' (rules?) like this specified so
that the process of making incidental decisions would be easier. For
example, it's not unreasonable that implementors find themselves asking
"Should COMPILE say something?" -- It's been traditional for compilers
in languages where you couldn't invoke the compiler at runtime to do
typeout, so they might naturally assume that the same should be true
here. Certainly it's natural for them to at least answer the question.
just as all serious Lisp implementations have a GC
even though CLtL never mentions it.
This comes up because it's a "hard issue" and new implementors naturally
tend to discuss "hard issues" with other implementors before even getting
started. My guess is that no new implementor would consider calling up
Moon or JonL or Masinter to ask what the I/O behavior of COMPILE should
be. Probably they would just make a guess, hope it was right, and move on
to the next seemingly trivial decision.
∂13-Mar-89 0853 X3J13-mailer issue MACRO-CACHING, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:49:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA19529; Mon, 13 Mar 89 09:47:42 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02151; Mon, 13 Mar 89 09:47:38 -0700
Date: Mon, 13 Mar 89 09:47:38 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131647.AA02151@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue MACRO-CACHING, version 2
Issue: MACRO-CACHING
Forum: Compiler
References: 8.2 Macro Expansion (CLtL pp151-152),
Issues PACKAGE-CLUTTER, LISP-SYMBOL-REDEFINITION,
QUOTE-SEMANTICS (a.k.a. QUOTE-MAY-COPY),
and MACRO-ENVIRONMENT-EXTENT
Category: Clarification
Edit history: 31-Jan-89, Version 1 by Pitman
11-Mar-89, Version 2 by Loosemore (add discussion)
Status: Ready for release
Background:
CLtL suggests that macro caching is a legitimate strategy.
Two particular kinds of caching are common:
Displacement. A macro expansion function displaces the actual macro in
order to avoid any later need for lookup.
Table. A macro expression is looked up in a cache (such as a hash table)
to avoid having to run the expander code.
While CLtL seems to expressly suggest these strategies to be legitimate,
linguistic constraints show that in most cases they are not. The problems
are things like:
- lexical scoping (MACROLET and SYMBOL-MACROLET, and FLET and LET to
the extent that they shadow the effect of MACROLET and SYMBOL-MACROLET,
respectively).
- ``read only'' structure
To see the problem, consider the following examples:
(SETQ FOO1 '(FOO))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO1)
(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO1)))
=> (2 3)
Note that because the lexical contour may vary for an EQL expression,
however, displacing the expansion will cause confusion:
(DEFUN DISPLACE (X Y)
(SETF (CAR X) (CAR Y))
(SETF (CDR X) (CDR Y))
X)
(DEFVAR FOO2 '(FOO))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM)
(DISPLACE FORM '(+ 1 1)))) ,FOO2)
(MACROLET ((FOO (&WHOLE FORM)
(DISPLACE FORM '(+ 1 2)))) ,FOO2)))
=> (2 2)
CLtL suggests that a displacement hook might be placed in
*MACROEXPANSION-HOOK*. The above example shows that to be an
unreliable technique.
If this were not enough, displacement is also inappropriate because
no Common Lisp primitive can tell the difference between regular list
structure and read-only list structure. Since a macro form being
expanded might have been read-only in some implementations (e.g., EVAL
of a quoted list), the macro cannot reliably side-effect the structure.
In the case of table-lookup, the problem is more complicated.
Table-lookup does not have a necessary effect beyond the particular
lookup being done at the moment. To do table-lookup correctly relies
on the key being not only the expression but also the lexical
environment object. Whether the cost of making and throwing away so
many tables was worth the savings over running the macro expander is
not at all clear. And the GC effects of caching every macro environment
ever seen may be extraordinary, however correctness could in principle
be preserved by doing such a two-dimensional lookup... at least unless
we decide that macro environments have only dynamic extent. [A separate
proposal, MACRO-ENVIRONMENT-EXTENT, addresses this issue. If it passed,
then there would really be no way for users to do reliable macro caching
without cooperation from the system to have the cache be part of the
environment itself.]
Problem Description:
Macro caching by displacement is provably not semantically valid.
Macro caching by table lookup is difficult for a user to do correctly,
and in any case is not possible to handle efficiently in user code.
Proposal (MACRO-CACHING:DISALLOW):
1. a. Clarify that macro caching by displacement is not semantically
valid in user code.
b. Clarify that macro caching by displacement is semantically valid
for system macros and special forms, provided that such caching
does not prejudice the expansion of user-code contained in any
displaced code. For example:
(PROG () (FOO))
could displace to a BLOCK, but the (FOO) must appear un-expanded
in the BLOCK in case the BLOCK occurs in more than one lexical
environment.
2. a. Clarify that macro caching by table lookup is not semantically
valid in user code in order to correctly respect the lexical
environment.
Implementations are free to extend the language to permit such
lookup and to offer functions which support it in a more efficient
way, but code using such functions would, of course, not be portable.
b. Clarify that macro caching by table lookup is valid for the system,
but only if it correctly respects the lexical environment.
Proposal (MACRO-CACHING:RESTRICT):
Like DISALLOW, but change 2a to:
Clarify that macro caching by table lookup is semantically valid only
if the lookup is keyed both on the form and the environment.
Implementations are free to extend the language to offer functions
which support it in a more efficient way, but code using such functions
would, of course, not be portable.
Rationale:
1. a. Displacement has effects which by their nature transcend
lexical boundaries.
b. The system can assure that lexical boundaries are irrelevant in some
cases because users are not permitted to redefine or shadow definitions
in the initial LISP system. [See issues PACKAGE-CLUTTER and
LISP-SYMBOL-REDEFINITION.]
2. a. Users can only associate an environment with a macro cache table
in a very clumsy way. Also, Permitting them to do so at all forces
macro environments to have indefinite extent, and works against
efficiency in compilers.
b. The system is capable of allocating space in an environment object
for a macro cache which can be reliably kept up in synch with the
lexical environment environment.
Test Case:
;; #1: File compiling this definition in some implementations will produce
;; a definition that returns read-only list structure. The call to EVAL
;; on the result must not try to modify the read-only structure during
;; macroexpansion. [See issue QUOTE-SEMANTICS.]
(DEFUN READ-ONLY-FOO () '(MACROLET ((FOO (&WHOLE FORM) (+ 1 1))) (FOO)))
(EVAL (READ-ONLY-FOO))
=> 2
;; #2: This constructs a form and then uses it in two places in another
;; constructed form. Each of the uses is in a different lexical
;; contour, so must be expanded differently.
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO)
(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
;; #3: This is effectively the same thing but involves a MACROLET
;; shadowing a DEFMACRO rather than two MACROLETs, since some
;; implementations might only be caching expansions that come
;; from DEFMACRO.
(DEFMACRO FOO (&WHOLE FORM) '(+ 1 1))
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST ,FOO (MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
Current Practice:
Symbolics Genera does not use displacing or table caching in either
the interpreter or compiler.
Symbolics Cloe, a compiled only implementation, uses table caching
to boost compilation by a little. Running the test cases above turned
up a bug (in test case #3), which is now in the process of being fixed.
[The fact that a bug was turned up in code written by a CL implementor
is an existence proof that the potential for trouble was not imagined.]
Both Symbolics Cloe and Symbolics Genera support *MACROEXPANSION-HOOK*,
leaving open the possibility of users bringing disasters upon themselves.
Macro environment objects in Symbolics Genera are stack-allocated, so
have only dynamic extent.
Cost to Implementors:
This proposal is upward compatible with correct implementations.
Cost to Users:
There is no cost to users of the RESTRICT proposal, unless they were doing
semantically invalid caching.
The cost to users of the DISALLOW proposal is a loss of speed in some cases
which are semantically valid. In general, however, the efficiency and
usefulness of such caching is subject to question in code intended to be
ported. Given that implementations are not required to ever give the same
environment object twice, the caching may be all for naught in some
implementations.
Cost of Non-Adoption:
Continued widespread confusion about whether displacement is a legitimate
implementation technique for user code.
Benefits:
Since *MACROEXPANSION-HOOK* is in the Lisp package, multiple applications
in the same environment share its effects. Often one application will
clobber another's hook, or introduce a hook that is not desirable to other
applications when none previously existed. Since a common use of
*MACROEXPANSION-HOOK* is to install a macro caching mechanism, clarifying
the situations in which *MACROEXPANSION-HOOK* should not be used will
decrease the likelihood of one program breaking, slowing down, or otherwise
adversely affecting another.
Aesthetics:
Most people agree that macro caching techniques are only supposed to improve
speed without affecting semantics. This proposal is only intended to
underscore that necessary truth. Insofar as this is only a clarification,
it presumably has no significant aesthetic impact.
Discussion:
Pitman thinks it's a good idea to clarify this issue because it's not really
spelled out now and it's the sort of thing programmers can waste a lot of
time bickering about to no good end. Either the functionality is reliable
and should be encouraged, or it is not reliable and should be discouraged
or forbidden. Pitman supports the DISALLOW proposal because it leaves open
the possibility of making macro environments have dynamic extent, but he
can live with the RESTRICT position, which he believes represents the
status quo.
Bob Laddaga (a Cloe maintainer who reviewed a draft of this proposal)
supports the DISALLOW option as well.
David Grays says:
I can accept MACRO-CACHING:DISALLOW.
The Explorer evaluator does displacement of macros, but is careful to
correctly handle the cases exemplified in your test cases #1 and #2.
It does not do the right thing for #3, but that is a bug that can fairly
easily be fixed.
Sandra Loosemore says:
This issue is closely tied to MACRO-ENVIRONMENT-EXTENT. If we decide
environments have (or can be made to have) indefinite extent, I see no
reason not to go with MACRO-CACHING:RESTRICT. On the other hand, if
we decide environments have only dynamic extent, proposal
MACRO-CACHING:DISALLOW is the only one that makes sense.
∂13-Mar-89 0924 X3J13-mailer issue QUOTE-SEMANTICS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:23:57 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA20995; Mon, 13 Mar 89 10:21:38 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02184; Mon, 13 Mar 89 10:21:33 -0700
Date: Mon, 13 Mar 89 10:21:33 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131721.AA02184@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue QUOTE-SEMANTICS, version 2
This issue replaces QUOTE-MAY-COPY, which was distributed and discussed
briefly at the last meeting.
Forum: Compiler
Issue: QUOTE-SEMANTICS
Subsumes: Issue QUOTE-MAY-COPY
References: CLtL p. 55, 78, 86, 143
Issue CONSTANT-COLLAPSING
Issue CONSTANT-COMPILABLE-TYPES
Issue CONSTANT-CIRCULAR-COMPILATION
Category: CLARIFICATION
Edit History: V1, 22 Jan 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore (discussion)
Status: Ready for release
Problem Description:
Is it permissible for COMPILE and EVAL to coalesce or copy constants?
Are there constraints upon what kinds of objects may appear as
constants in code processed by COMPILE or EVAL, similar to those for
COMPILE-FILE?
CLtL p86 states that (QUOTE <x>) simply returns <x>. On p55 it is
mentioned that the only self-evaluating forms that may be copied are
numbers or characters. It is also stated that an implementation is
permitted to collapse (or coalesce) EQUAL constants "appearing in code
to be compiled" (p78), which is defined to mean self-evaluating forms
or objects contained in a QUOTE form (without reference to whether the
form is processed by EVAL, COMPILE, or COMPILE-FILE).
Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded. In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced. There is also
at least one implementation where constants are copied by EVAL in some
circumstances.
Proposal QUOTE-SEMANTICS:NO-COPYING:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is not permitted; the resulting program
must reference objects that are EQL to the corresponding objects in
the source code. The constraints on what kinds of objects may appear
as constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
Rationale:
This proposal is consistent with what many people think of as the
"traditional" semantics for QUOTE. It gives users maximum flexibility
about what kinds of objects may appear as constants.
Proposal QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
Any object may validly appear as a constant in code processed by EVAL
or COMPILE. The constraints on what kinds of objects may appear as
constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
Rationale:
This proposal is the most consistent with the semantics stated in CLtL.
It gives users maximum flexibility about what kinds of objects may
appear as constants.
Proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
The constraints on what kinds of objects may appear as constants
(described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply to EVAL and COMPILE as well as to
COMPILE-FILE.
Rationale:
This makes the rules for handling of constants consistent between
EVAL, COMPILE, and COMPILE-FILE. It gives implementors maximum
flexibility in handling constants in EVAL and COMPILE.
Current Practice:
Implementations in which COMPILE attempts to copy all constants
include PSL/PCLS and Kyoto Common Lisp.
In Lucid Common Lisp, constants are not normally copied by COMPILE,
but since COMPILE does coalesce constants, it may cause QUOTE to
return an object which is not EQL to the object which appeared in the
source code.
Symbolics Genera has COMPILE copy list, string, non-displaced array,
and (I-Machine only) closure constants, but Moon says he thinks this
is wrong.
There is known to be at least one implementation where expanding the
DEFUN macro causes all constants in the body of the function to be
copied.
Cost to implementors:
Proposal NO-COPYING would involve a significant cost in those
implementations where constants are now copied or coalesced by EVAL
and COMPILE. Some implementations would also require substantial
changes to support proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS. The
aspect that is likely to cause the most problems is that, in some
implementations, the garbage collector assumes that constants
referenced in compiled code have been copied to read-only storage and
do not need to be scanned or relocated.
Proposal SAME-AS-COMPILE-FILE has no adoption cost above what is
required to support issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION.
Cost to users:
Proposals COPYING-ALLOWED-BUT-NO-CONSTRAINTS and SAME-AS-COMPILE-FILE
may break some existing programs that assume constants in code
processed by EVAL or COMPILE are always EQL to the corresponding
objects in the source code. Proposal SAME-AS-COMPILE-FILE may also
break existing programs that depend on referencing "undumpable"
constants in code processed by EVAL or COMPILE. In both cases,
however, the behavior is already nonportable. Both proposals would
permit implementations in which these programs now work to continue to
provide their existing behavior.
Benefits:
The semantics of QUOTE are clarified.
Discussion:
This issue subsumes issue QUOTE-MAY-COPY, which caused a very lengthy
debate on the cl-compiler mailing list.
This issue relates to conformance requirements. Accepting either of
proposals NO-COPYING or COPYING-ALLOWED-BUT-NO-CONSTRAINTS would mean
that not all conforming programs could be compiled with COMPILE-FILE.
Some people may find this disturbing, particularly since one of the
goals of Common Lisp has been to try to eliminate differences in
semantics between compiled and interpreted code.
Loosemore supports proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE,
since it requires essentially no conversion cost for implementors and
does not break any user programs that are not already nonportable.
JonL White says:
Since we have already passed the proposal that permits constants to
be "read-only" -- it is an error to modify them -- and have already
passed the proposal that allows access to updateable structures --
LOAD-TIME-EVAL -- then there is no excuse for being overly concerned
with the storage address of quoted data. People who have mistakenly
used structured constants as updatable data should convert over to
either LOAD-TIME-EVAL or DEFPARAMETER.
Kent Pitman says:
The problem is that a lot of copying advocates have been going around
trying to use "the need for copying" as leverage for restricting
the set of things which I may quote. My view is that it is my write [sic]
to quote whatever I want, and it's up to the person who thinks they
can do something fun with copying to not get themselves in deeper than
they can handle.
Jeff Dalton says:
I would agree [with Pitman's remarks] too. My only quibble is that
it's not just "the need for copying" that's used a lever.
"Consistency with file compilation" is also being used as a lever.
∂13-Mar-89 0929 X3J13-mailer issue SAFE-CODE, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:29:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21179; Mon, 13 Mar 89 10:26:59 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02193; Mon, 13 Mar 89 10:26:56 -0700
Date: Mon, 13 Mar 89 10:26:56 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131726.AA02193@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue SAFE-CODE, version 1
Issue: SAFE-CODE
Forum: Compiler
References: OPTIMIZE declaration (p160),
Issue ERROR-TERMINOLOGY
Category: CLARIFICATION/CHANGE
Edit history: 07-Mar-89, Version 1 by Pitman
Status: Ready for release
Problem Description:
The new error terminology refers to ``safe code'' in the definition
of the term and CLtL refers to
individual meanings of OPTIMIZE qualities, but there is no standardized
way of relating the two concepts.
Proposal (SAFE-CODE:SAFETY-3):
Define that, formally, the term ``safe code'' is code refers to any
code in which the OPTIMIZE quality for SAFETY has a value of 3.
Implementors might wish to consider treating other situations as safe
as well, but in making that decision both the relative values of other
OPTIMIZE qualities and the idiosyncratic properties of the particular
implementation should also be taken into account.
Examples:
1. The body of the following is safe...
a. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 3))) . body)
b. (LOCALLY (DECLARE (OPTIMIZE SAFETY )) . body)
2. The body in each of the following is unsafe. They might
or might not be treated as safe, possibly depending
on the values of other qualities and specifics of the
implementation.
a. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 0))) . body)
b. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 1))) . body)
c. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 2))) . body)
Rationale:
Programmers will probably intuitively expect that the term
``highest safety'' refers to giving the SAFETY quality its
highest safety.
Current Practice:
Implementors ...
Symbolics Genera does error checking always, and ignores OPTIMIZE
declarations.
Symbolics Cloe heeds OPTIMIZE declarations, but effectively makes
`judgment calls' in every case because there is no clear guidance
on how to interpret them.
Programmers ...
Many programmers write (DECLARE (SPEED 0) (SAFETY 3)) even when all
they really want to control is SAFETY because they are afraid that
unless they explicitly sacrifice speed, the compiler will ignore
their plea for error checking.
Cost to Implementors:
Some implementations might require a lot of nitpicky little changes.
Cost to Users:
Technically none. No portable code can really rely on much of any
reliable effect out of any of the OPTIMIZE qualities. However, some
users may rely on implementation-specific features of implementations,
and if those implementations are forced to change, non-portable user
code might break in some ways.
Cost of Non-Adoption:
The meaning of ``safe code'' will not be clearly defined.
Benefits:
Programmers will be able to say what they mean. They can stop
superstitiously putting (SPEED 0) next to (SAFETY 3) just to
assure they get safe code.
Aesthetics:
Improved. This will make the English align well with the code.
Discussion:
It is very important that we reach consensus in some form on this issue.
Pitman supports SAFE-CODE:SAFETY-3.
∂13-Mar-89 1014 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:14:33 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 13:09:40 EST
Date: Mon, 13 Mar 89 13:10 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890313181059.0.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 11:51 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Do progress notes in the wholine count as output? If not, why not? ...
No. They are passive. The function in question does not output to the
wholine. Rather, it arranges information such that a foreign process
can access it and display it. For example, if 500 calls to LOAD are done
in three second, you don't always get 500 progress messages. That is
because the output is done by the foreign process doing the polling and
not the process which is running the CL code. I think this distinction
is important. Indeed, if the running process could block, signal an
error, etc. due to problems in I/O then it would not be a good idea.
So, the acceptability of progress notes has nothing to do with the
stream they are displayed on, only the fact that they are displayed by a
background process? This implies that a single-tasking machine that
displayed progress notes synchronously would therefore be unacceptable.
I find this distinction extremely arbitrary, since it is based only on
the implementation, not the program-visible effects.
I like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
I don't think it's that difficult.
We'll have to come up with a general definition of passive output versus
active output. And we'll still have to make sure that passive output
isn't allowed to go to *STANDARD-OUPTUT*.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
Maybe it's because C people have traditionally been willing to settle
for less. :-) Seriously, I think it's a clear hole in their standard.
People would probably flame if things that weren't documented as doing
I/O were to suddenly start doing it.
Actually, I think the difference is that Common Lisp includes some
operations that are not traditionally included in runtime libraries,
COMPILE, COMPILE-FILE, and LOAD being the most notable ones. No
Lisp implementor would even think of having CONS or EQ produce output,
just as the C standard doesn't need to say that malloc() is silent.
Perhaps this means that since we have such unusual runtime facilities,
we can't rely on common sense as other languages do. I would be willing
to support a blanket statement that said that no output may be produced
by functions other than that specified in the standard or due to the
signalling of conditions detected by the function.
Would this prevent an implementation from having a *DEBUG-CONS* variable
that turns on debugging output by CONS?
barmar
∂13-Mar-89 1046 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:46:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555842; Mon 13-Mar-89 13:43:40 EST
Date: Mon, 13 Mar 89 13:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: x3j13@sail.stanford.edu
cc: barmar@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890313134321.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Further discussion on this topic will take place on CL-Editorial.]
∂13-Mar-89 1450 X3J13-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:50:22 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07805; Mon, 13 Mar 89 15:48:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02496; Mon, 13 Mar 89 15:48:08 -0700
Date: Mon, 13 Mar 89 15:48:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132248.AA02496@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
This issue is still under discussion. There has been a lot of talk
about how this relates to the creation of meta-objects at compile
time, but the only proposals that have been made so far are the two
included here.
Forum: Compiler
Issue: CLOS-MACRO-COMPILATION
References: CLOS chapters 1 & 2 (88-002R)
CLOS chapter 3 (89-003)
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION
Edit History: V1, 10 Mar 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore
Status: **DRAFT**
Problem Description:
Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?
A part of the problem is that we do not currently have a full
understanding of all the issues involved. In particular, work on
defining the CLOS meta-object protocol is still in progress. The goal
of this proposal is to say enough about the behavior of these macros
in the standard so that users can use them portably in compiled code,
but to leave as much of the behavior as possible unspecified to avoid
placing undue restrictions on the meta-object protocol.
There are two proposals, MINIMAL and NOT-SO-MINIMAL.
Proposal CLOS-MACRO-COMPILATION:MINIMAL:
State that top-level calls to the CLOS defining macros have the
following compile-time side-effects. Any other compile-time behavior
is explicitly left unspecified.
DEFCLASS:
* The class name becomes a type specifier which may appear in
subsequent type declarations.
* The class name can be used to name a superclass in a subsequent
DEFCLASS.
* The class name can be used as a specializer in a subsequent
DEFMETHOD.
DEFGENERIC:
* The generic function can be referenced in a subsequent DEFMETHOD.
* The generic function is not callable at compile-time.
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function. The compiler may
perform tests for lambda-list congruence only between the DEFGENERICs
and DEFMETHODs for a given generic function name that appear within
the file being compiled, and not against a generic function of the
same name which exists in the compile-time environment.
DEFINE-METHOD-COMBINATION:
* The method combination can be used in a subsequent DEFGENERIC. If it
is referenced, the body of a long form of method combination must be
evaluable at compile-time.
Rationale:
The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
DEFTYPE.
DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
function definition to the compile-time environment. Since generic
functions may be freely redefined between compile and run time (just
like any other function), a method may end up "belonging" to a
different generic function at load time than at compile time.
Some implementations compose effective methods at compile time, which
requires evaluating the body of the DEFINE-METHOD-COMBINATION at
compile time.
Proposal CLOS-MACRO-COMPILATION:NOT-SO-MINIMAL:
This is the same as proposal MINIMAL, except under DEFCLASS add:
* The class may be instantiated at compile-time. Provided the
appropriate methods are also defined at compile-time, this implies:
- The class can be used as the :METACLASS option of a later DEFCLASS.
- It can be used as the :GENERIC-FUNCTION-CLASS or :METHOD-CLASS option
of a DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS.
Rationale:
Being able to instantiate a class at compile-time is somewhat more
convenient for users.
Current Practice:
The items listed under DEFCLASS in proposal MINIMAL are fairly standard
programming style.
Flavors does not support compile-time instantiation of classes. It
does not make method combinations available at compile-time either, but
Moon considers that to be a bad design choice.
Cost to implementors:
Unknown.
Cost to users:
Unknown, but probably fairly small.
Note that for proposal NOT-SO-MINIMAL, users still have to ensure that
any methods on the class which may be invoked at compile-time are
fully defined. This includes the INITIALIZE-INSTANCE and
SHARED-INITIALIZE methods that are invoked by MAKE-INSTANCE.
Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
definitions will make sure they are fully defined at compile-time.
Alternatively, the definitions could be placed in a separate file,
which is loaded before compiling the file that depends on those
definitions.
Benefits:
Programmers can rely on programs that use the CLOS defining macros
being able to compile correctly in all implementations, without having
to wrap explicit EVAL-WHENs around every macro call.
Discussion:
This writeup is based on discussions between Moon, Gray, and
Loosemore, who are mostly in agreement on the things presented in
proposal MINIMAL. We have purposely avoided saying anything about
whether meta-objects representing the classes, methods, etc. get
created at compile-time, or whether such meta-objects are fully or
partially defined. The basic questions addressed by this issue are
what kinds of things can be defined and then used during compilation
of the same file that defines them, and what restrictions might apply.
These proposals are not completely compatible with the meta-object
protocol document (89-003). Gregor Kiczales says:
No one believes that what is written in draft 10 of the MOP is valid.
Sandra Loosemore says:
Although I admit I don't understand all of the issues involved with
the meta-object protocol, I prefer proposal MINIMAL over
NOT-SO-MINIMAL. I don't think leaving the issue of whether or not
classes can be instantiated at compile-time unspecified places an
undue burden on users, and it does leave more freedom for the
meta-object protocol to decide what the right behavior really is.
Dick Gabriel notes:
The question I have about the process going on with respect to the
CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
CLOS under various compilation/evaluation situations is being
over-specified.
At this stage of the game I worry that we might go a little too far in
one direction in specification when we are actually engaged in design
work. This isn't intended to be a criticism of any committees, but I
would feel a lot more comfortable with a conservative specification
that defined well-formed programs being loaded or compiled in fresh
Common Lisps with a pretty simple eval-when model that is easier to
specify and which makes it easy for all but the hairiest
compilation-environment-frobbing programs to be written.
∂13-Mar-89 1452 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:52:29 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07899; Mon, 13 Mar 89 15:50:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02499; Mon, 13 Mar 89 15:50:07 -0700
Date: Mon, 13 Mar 89 15:50:07 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132250.AA02499@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
V4, 08 Mar 1989, Sandra Loosemore (wording changes)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled. At what time (compiletime or runtime) are certain
kinds of definitions "captured"? What happens if these definitions
are not consistent at both compile and run times?
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
The process of compilation causes certain kinds of information present
in the compiletime environment to be captured and incorporated into
the resulting compiled code. Other kinds of information may not be
captured until the compiled code is actually run.
Specifically:
(1) The following information *must* be present in the compiletime
environment for the program to be compiled correctly. This
information need not also be present in the runtime environment.
(a) In conforming code, macros referenced in the code being compiled
must have been previously defined in the compiletime environment.
The compiler must treat any form that is a list beginning with
a symbol that does not name a macro or special form as a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) In conforming code, variables that are intended to be bound
specially must be declared SPECIAL in the compiletime environment
before any bindings of that variable are processed by the compiler.
The compiler must treat any binding of an undeclared variable as a
lexical binding.
(2) The compiler *may* incorporate the following kinds of information
into the code it produces, if the information is present in the
compiletime environment and is referenced within the code being
compiled. Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code. In all
cases, the absence of the information at compiletime is not an error,
but its presence may enable the compiler to generate more efficient
code.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) The compiler can assume that type definitions made with DEFTYPE
or DEFSTRUCT in the compiletime environment will retain the same
definition in the runtime environment. It may also assume that
a class defined by DEFCLASS in the compiletime environment will
be defined in the runtime environment in such a way as to have
the same superclasses and metaclass. This implies that
subtype/supertype relationships of type specifiers will not
change between compiletime and runtime. (Note that it is not
an error for an unknown type to appear in a declaration at
compiletime, although it is reasonable for the compiler to
emit a warning in such a case.)
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the runtime behavior of the program is
undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above. It is, however,
permissible for the compiler to emit warning messages when
compiling calls to functions that are defined in the compiletime
environment, but where the wrong number or type of arguments
are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible for the
compiler to emit a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
There don't seem to be any compilers around that do not implement the
provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
Several people have expressed reservations about items 2b and 2c, saying
that self-tail-recursion optimization and block compilation should not
be the default behavior of the compiler. Gail Zacharias responds:
This item [2c] has nothing to do with whether anybody does it by
default. The question is whether an end user can take a Common Lisp
program whose internals he's not familiar with, block-compile it, and
be guaranteed that it will continue to function correctly. This item
says that yes, a correct CL program must explicitly indicate what
functions in the source it will redefine at runtime. I don't think
this places such a great burden on the programmer. Without this
provision, only somebody intimately familiar with a program could know
whether it can be safely block-compiled, making block-compilation
useless in the context of portable CL programs.
This thing about "block compilation shouldn't be the default" seems to
come up every time this item is discussed. That's an environment
question and is not addressed by the proposal. The proposal simply
says that block compilation should be legal.
∂13-Mar-89 1514 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:14:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08718; Mon, 13 Mar 89 16:12:23 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02542; Mon, 13 Mar 89 16:12:19 -0700
Date: Mon, 13 Mar 89 16:12:19 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132312.AA02542@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Forum: Compiler
Issue: COMPILE-FILE-SYMBOL-HANDLING
References: CLtL p. 182
Issue IN-PACKAGE-FUNCTIONALITY
Issue CONSTANT-COMPILABLE-TYPES
Issue DEFPACKAGE (passed)
Category: CHANGE/CLARIFICATION
Edit History: V1, 01 Feb 1989, Sandra Loosemore
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
Status: Ready for release
Problem Description:
It is not clear how COMPILE-FILE is supposed to specify to LOAD how
symbols in the compiled file should be interned. In particular, what
happens if the value of *PACKAGE* is different at load-time than it
was at compile-time, or if any of the packages referenced in the file
are defined differently?
There are three proposals: CURRENT-PACKAGE, HOME-PACKAGE, and
REQUIRE-CONSISTENCY.
Proposal COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE:
When a compiled file is loaded, the interned symbols it references
are found by the following procedure. The rules are applied in the
order listed and only the first applicable rule has any effect.
(1) Any symbol accessible at compile time in the package that is the
value of *PACKAGE* is found by calling INTERN at load time with one
argument, the name of the symbol.
(2) A keyword symbol is found by finding or creating a keyword symbol
with the same name.
(3) A symbol that at compile time is an external symbol of its home
package is found at load time by finding the package with the same
name as the compile-time home package, and then finding an exported
symbol of that package with the same name as the compile-time symbol.
If no such package exists, no such symbol exists, or the symbol is not
exported, an error is signalled.
(4) Any other symbol is found by calling INTERN at load time with two
arguments, the name of the symbol and the package with the same name
as the compile-time symbol's home package. If no such package exists,
an error is signalled.
The goal of this procedure is for each symbol reference to be
resolved to the same symbol when a compiled file is loaded as when
the source file is loaded directly with LOAD. It is possible to
create package structures that make that impossible; for example, it
is possible for a symbol to be inaccessible from its own home
package. A conforming program cannot depend on any symbol
resolution behavior that is not provided by the above four rules.
If any top level form in a compiled file changes the value of
*PACKAGE*, other than a SELECT-PACKAGE appearing as the first
top level form in the file, the package in which the loader will
place the constant symbols referenced in the file is unspecified.
Rationale:
Proposal CURRENT-PACKAGE makes COMPILE-FILE/LOAD follow the same
rules as PRINT/READ. For any symbol not written with a package
prefix in the source file (which should be the great majority of
them), CURRENT-PACKAGE will make loading the compiled file get the
same symbols as loading the source file.
The reason for the rule about changing the value of *PACKAGE* is that
many loaders cache the interning of symbols; if the same symbol
appears multiple times in the source file, its name may only be
looked up once at load time. Since not all loaders are required to
work this way, changing *PACKAGE* in mid-file is not allowed,
because the effect on later occurrrences of a symbol would be
implementation-dependent.
Proposal COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE:
When a compiled file is loaded, the interned symbols it references are
found by calling INTERN at load time with two arguments, the name of
the symbol and the package with the same name as the compile-time
symbol's home package. If no such package exists, an error is
signalled.
The goal of this procedure is for each symbol reference to be resolved
to the same symbol when a compiled file is loaded as when the source
file was processed by COMPILE-FILE. A conforming program cannot
depend on any symbol resolution behavior that is not provided by the
above rule.
If any top level form in a compiled file changes the value of
*PACKAGE* when the file is loaded interpretively but not during
compile-time processing by COMPILE-FILE, the package in which the
loader will place the constant symbols referenced in the file is
unspecified.
Rationale:
The behavior specified in this proposal is simple and easy to
understand (there is only one rule to remember instead of four).
It does not require any restrictions on where top-level
SELECT-PACKAGE forms may appear in the file. It allows a compiled
file that does not include an explicit SELECT-PACKAGE to be loaded
successfully no matter what the load-time value of *PACKAGE* is,
as long as the compile-time value of *PACKAGE* was the "right"
package.
Proposal COMPILE-FILE-SYMBOL-HANDLING:REQUIRE-CONSISTENCY:
In order to guarantee that compiled files can be loaded correctly,
users must ensure that the packages referenced in the file are defined
consistently at compile and load time. Conforming Common Lisp programs
must satisfy the following requirements:
(1) The value of *PACKAGE* when the contents of the file are compiled
by COMPILE-FILE must be the same as the value of *PACKAGE* when
the file is loaded. In particular:
(a) If any top level form in a compiled file changes the value
of *PACKAGE*, other than a SELECT-PACKAGE appearing as the first
top-level form in the file, the package in which the loader
will place the constant symbols referenced in the file is
unspecified.
(b) If the first top-level form in the file is not a call to
SELECT-PACKAGE, then the value of *PACKAGE* at the time LOAD is
called must be a package with the same name as the package that
was the value of *PACKAGE* at the time COMPILE-FILE was called.
(2) For all symbols that were accessible in *PACKAGE* at compile
time but whose home package was another package, at load time there
must be a symbol with the same name that is accessible in both the
load-time *PACKAGE* and in the package with the same name as the
compile-time home package.
(3) For all symbols in the compiled file that were external symbols in
their home package at compile time, there must be a symbol with the
same name that is an external symbol in the package with the same name
at load time.
If any of these conditions do not hold, the package in which LOAD looks
for the affected symbols is unspecified. Implementations are permitted
to signal an error or otherwise define this behavior.
Otherwise, when a compiled file is loaded, the interned symbols it
references are found by calling INTERN at load time with two
arguments, the name of the symbol and the package with the same name
as the compile-time symbol's home package. If no such package exists,
an error is signalled.
Rationale:
Any program that behaves differently under the other two proposals
is already nonportable. This proposal is merely an explicit
statement of the status quo, namely that users cannot depend on
any particular behavior if the package environment at load time is
inconsistent with what existed at compile time.
Current Practice:
PSL/PCLS implements something very similar to proposal HOME-PACKAGE,
as does A-Lisp. Utah Common Lisp implements something like proposal
CURRENT-PACKAGE, but the chief compiler hacker says he thinks that
proposal HOME-PACKAGE actually makes more sense, and agrees that any
program that behaves differently under the two proposals is broken.
The TI Explorer currently implements proposal HOME-PACKAGE, after
trying it both ways.
KCL implements something like HOME-PACKAGE (symbols in the compiled
file are explicitly qualified with the name of their home package),
except that it differentiates between internal and external symbols.
Lucid Lisp appears to implement something like proposal CURRENT-PACKAGE.
Symbolics Genera implements CURRENT-PACKAGE. Symbolics Cloe probably
does also.
Coral also implements something like proposal CURRENT-PACKAGE.
Cost to implementors:
Proposals HOME-PACKAGE and CURRENT-PACKAGE would be incompatible
changes for implementations that currently do things the other way.
It would probably be easier to convert to HOME-PACKAGE than
CURRENT-PACKAGE, since it is less complicated.
Proposal REQUIRE-CONSISTENCY is intended to be compatible with either
of the other two proposals, but it may not be entirely compatible with
the details of current implementations.
Cost to users:
Proposal HOME-PACKAGE places the fewest restrictions on user programs.
Proposal CURRENT-PACKAGE places a restriction on where and how the value
of *PACKAGE* may be changed within the file.
Proposal REQUIRE-CONSISTENCY places even more restrictions on user
programs.
Most of these restrictions are probably already necessary in portable
programs. However, some nonportable programs that depend on the "other"
model may be broken by proposals HOME-PACKAGE or CURRENT-PACKAGE.
For a discussion of how these proposals treat nonportable or erroneous
programs, see the "Analysis" section below.
Benefits:
COMPILE-FILE's treatment of symbols is made explicit in the standard.
Analysis:
Proposals CURRENT-PACKAGE and HOME-PACKAGE present two different
models of how this problem might be solved. Essentially, proposal
CURRENT-PACKAGE uses the same rules as PRINT/READ in deciding when to
qualify symbols with a package name and where to find unqualified
symbols. Proposal HOME-PACKAGE requires -all- symbols written to the
compiled file to be qualified with an explicit package, and the loader
simply INTERNs the symbol names in that package.
These two proposals differ in the following situations. Proposal
REQUIRE-CONSISTENCY, in effect, says that valid programs do not cause
any of these situations to occur, and the behavior in such cases is
unspecified (allowing both models to be used as valid implementation
techniques).
(1) The situation where the file does not contain a SELECT-PACKAGE
and where the compile-time value of *PACKAGE* is a package with a
different name than the load-time value of *PACKAGE*.
Proposal CURRENT-PACKAGE would intern the names of symbols that
were accessible in *PACKAGE* at compile time in *PACKAGE* at load time.
Proposal HOME-PACKAGE would intern the names of symbols that
were accessible in *PACKAGE* at compile time in the package with
the same name as their compile-time home package.
In general, programs must be compiled in the "right" package, so
that the compiler can find and apply the correct macro expansions,
type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.
As a result of macroexpansion or other transformations applied by
the compiler, the compiled file may contain symbol references that
were not present in the source file. Proposal CURRENT-PACKAGE may
cause problems because these references may be resolved to be
symbols other than the ones that were intended. Since proposal
HOME-PACKAGE remembers the home package of all symbols, it is much
more likely to find the correct symbols at load time.
(2) The situation where *PACKAGE* is altered by a top-level form
that is not a SELECT-PACKAGE which is the first top-level form in
the file.
Proposal CURRENT-PACKAGE says this is illegal. This is because
of the difficulty in deciding what the "current package" is, if it
is allowed to change throughout the file.
Proposal HOME-PACKAGE says this is OK, as long as *PACKAGE* is
altered in the same way at compile time as when the file is loaded
interpretively. This is possible because the behavior this
proposal specifies does not depend on what the value of *PACKAGE*
is once symbols in the source file have been read by COMPILE-FILE.
Some people argue that allowing *PACKAGE* to be switched in
mid-file is a bad idea anyway; it is not really necessary and it
implies a restriction on COMPILE-FILE to read forms from the file
one at a time, processing each form before the next call to READ.
Others argue that restricting SELECT-PACKAGE to be the first
top-level form is an artificial contrivance. The compile-time
behavior of SELECT-PACKAGE is well-defined no matter where it
appears in the file. There is also a problem defining what "the
first top-level form" really means. Finally, this model requires
all package definitions to be made externally to the file, which
may be inconvenient for smaller programs that now contain the
package definition and package contents all in one file.
(3) The situation where there is a symbol accessible in the
compile-time value of *PACKAGE* but with another home package, and
where at load time there is not a symbol with the same name that
is accessible in both packages. This situation might occur, for
example, if at compile time there is a symbol that is external in
its home package and that package is used by *PACKAGE*, but where
there is no such external symbol in that package at load time, or
the load-time *PACKAGE* does not use the other package.
Proposal CURRENT-PACKAGE would find or create a symbol accessible
in *PACKAGE*.
Proposal HOME-PACKAGE would find or create a symbol accessible in
a package with the same name as the symbol's compile-time home
package.
Some people feel that the behavior of proposal CURRENT-PACKAGE is
more intuitive in this situation, and that it is more forgiving of
differences between the compile-time and load-time package
structures. Others feel that the behavior of HOME-PACKAGE is more
intuitive, and that if there have been significant changes to the
package structures, it is probably an indication that the file
needs to be recompiled anyway, since the compiler might have
picked up macro definitions and the like from the wrong package.
(4) The situation where a symbol is external in its home package
and where there is no such external symbol in that package at load
time.
Proposal CURRENT-PACKAGE would quietly find or create the symbol
in *PACKAGE* if the symbol were accessible in *PACKAGE* at compile
time. Otherwise, it will signal an error.
Proposal HOME-PACKAGE would always just quietly find or create the
symbol as internal in its home package.
Not complaining when a symbol that is supposed to be external
isn't can be seen as a violation of modularity. However, it seems
like this argument should apply equally to symbols whose home
package is *PACKAGE* as symbols whose home package is somewhere
else.
Discussion:
Loosemore is opposed to proposal CURRENT-PACKAGE, but would be
less opposed to it if it contained an explicit statement that
*PACKAGE* must be a package with the same name at load time as at
compile time. She thinks proposal HOME-PACKAGE is the best of the
options presented here.
Moon is opposed to proposal HOME-PACKAGE, but would be less
opposed to it if it required an error to be signalled when a
symbol that was external at compile time is not external at load
time. He thinks proposal CURRENT-PACKAGE is the best of the options
presented here.
John Kolts, who did the implementation on the TI Explorer, recalls:
My primary motivation was compile/load consistency. I thought it was
important that during loading all symbol references should resolve to
the same symbol as they would have during the compilation. If, for
instance, the packages used by *package* were different at compile
time than at load time, my approach would still intern the accessible
symbols in the "right" package during loading. [...] Of course, such
an approach means that loading the [compiled file] could give results
incompatible with loading the LISP file directly, but I felt that if
behavior consistent with some altered package structure was desired,
the file should be recompiled, a relatively small price to pay for the
benefit of this consistency.
A related consideration was that remembering the home package seemed to
be important for proper macro expansion in certain cases.
What was apparent was that there were several defensible approaches,
none of which was obviously the absolutely right way to handle certain
pathological situations. Making the expected behavior explicit in a
standard is a good idea.
David Gray says:
There really shouldn't be anything wrong about using SELECT-PACKAGE
multiple times within a file as long as it is used at top level so
that the compiler knows that the current package is being changed.
Cris Perdue says:
[Proposal HOME-PACKAGE] doesn't ensure that the home package remains
the same across compilation and loading, which I consider the key
consideration. How about this statement instead?
"When a file is compiled, the symbol name is recorded together
with the home package name and an indication of whether the
symbol is external in its home package. At load time the
symbol is effectively looked up with:
(find-symbol string (find-package pkg-name))
If the symbol is noted as external, it must be found at load
time as :external. If it is noted as internal, it must either
be present in the package or not found at all. If it is not found
at all, it is created as if by:
(intern string (find-package pkg-name))
If the package system is not in a suitable state, an error is
signalled."
This is what I consider "the right thing".
JonL White says:
I don't believe we have anything to gain at this point in trying to
standardize the faslout package-qualification algorithm; this is
notwithstanding that standardizing PRINT output, as an interchange
format, is an absolute requirement [even though READ-of-PRINT will
likely be even more information losing than loading in a compiled
file!]
∂13-Mar-89 1517 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:16:50 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08737; Mon, 13 Mar 89 16:14:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02546; Mon, 13 Mar 89 16:14:26 -0700
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132314.AA02546@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-LET-CONFUSION, version 7
Issue: COMPILER-LET-CONFUSION
Forum: Compiler
References: CLtL p. 112
Category: CHANGE
Edit History: V1, 27 Sep 1988, Sandra Loosemore (initial version)
V2, 04 Oct 1988, Sandra Loosemore (add another example)
V3, 31 Oct 1988, Sandra Loosemore (only proposal ELIMINATE)
V4, 08 Jan 1989, Kent M. Pitman (new alternative)
V5, 09 Jan 1989, Sandra Loosemore (discussion)
V6, 08 Mar 1989, Sandra Loosemore (general updating)
V7, 13 Mar 1989, Sandra Loosemore (fix bug from V6)
Problem Description:
The description of the COMPILER-LET special form in CLtL is confusing
to many people. There are no examples provided to make it clear how it
is supposed to be used. The only description which is offered is overly
concrete, which has led to confusion about the intent of COMPILER-LET,
and about its implementability.
The intent of COMPILER-LET was to permit information to be communicated
between macros by use of dynamic variables at macroexpansion time.
It was not necessary to the intended uses of COMPILER-LET that such
variables ever be bound at execution time.
Unfortunately, probably because some implementations did not primitively
support COMPILER-LET at the time CLtL was written, an exception was
permitted to make COMPILER-LET `more or less work' in interpreters:
the COMPILER-LET variables were permitted to be bound at execution time.
The problem was further compounded by the fact that CLtL presented this
exception as part of COMPILER-LET's contract rather than as an
implementation note, and by the fact that no examples of actually using
COMPILER-LET correctly are provided.
One particular case where problems have resulted is a situation like
(compiler-let ((*v* 1))
#'(lambda () (m)))
where M is a macro that refers to *V*. In some implementations, M is
not macroexpanded until the dynamic extent of the *V* binding has
ended.
Subtle bugs can be introduced because of the different handling of the
variable bindings in the interpreter and the compiler. In compiled
code, the bindings are only lexically visible during the expansion of
macros at compile time, while in interpreted code the bindings have
dynamic scope and may also be seen during ordinary evaluation if
evaluation and macroexpansion happen "in parallel".
Further compatibility problems can result from the value forms being
evaluated in a null lexical environment in the compiler and the ordinary
lexical environment in the interpreter.
Background and Analysis:
It should be clear up front that COMPILER-LET is not computationally
essential. Most (if not all) uses of it can be rewritten using MACROLET
or SYMBOL-MACROLET.
A typical use of COMPILER-LET might be:
(defvar *local-type-declarations* '())
(defmacro local-type-declare (declarations &body forms)
`(compiler-let ((*local-type-declarations*
(append ',declarations *local-type-declarations*)))
,@forms))
(defmacro typed-var (var)
(let ((type (assoc var *local-type-declarations*)))
(if type `(the ,(cadr type) ,var) var)))
(defun f (x y)
(local-type-declare ((x fixnum) (y float))
(+ (typed-var x) (typed-var y))))
The same thing could be accomplished using MACROLET:
(defmacro local-type-declare (declarations &body forms)
(local-type-declare-aux declarations forms))
(defmacro typed-var (var) var)
(eval-when (eval compile load)
(defun local-type-declare-aux (declarations forms)
`(macrolet ((typed-var (var)
(let ((type (assoc var ',declarations)))
(if type `(the ,(cadr type) ,var) var)))
(local-type-declare (new-declarations &body new-forms)
(local-type-declare-aux
(append new-declarations ',declarations)
new-forms)))
,@forms)))
A further alternative would be to use SYMBOL-MACROLET (this particular
implementation assumes that issue DEFINING-MACROS-NON-TOP-LEVEL passes):
(let ((temp (gensym)))
(defmacro local-type-declare (declarations &body forms &environment env)
`(symbol-macrolet ((,temp ',(append declarations
(symbol-macro-value temp env))))
,@forms))
(defmacro typed-var (var &environment env)
(let ((type (assoc var (symbol-macro-value temp env))))
(if type `(the ,(cadr type) ,var) var)))
)
(defun symbol-macro-value (symbol env &optional default)
(multiple-value-bind (expansion macro-p) (macroexpand symbol env)
(if macro-p (eval expansion) default)))
Opinion is divided as to which is more understandable. Some
people find the COMPILER-LET idiom more understandable (assuming that
it can be made to work consistently in compiled and interpreted
code), while others find it just as natural to use MACROLET or
SYMBOL-MACROLET.
The issues are these:
- Is it possible to implement COMPILER-LET in a usefully consistent
way in all implementations?
- Are the benefits of providing a useful and compatible implementation
of COMPILER-LET worth any associated cost?
Two proposals are presented below:
- Option REPAIR argues that COMPILER-LET provides interesting
functionality that can be implemented in a manner that is usefully
consistent across implementations, and that the associated cost
is low enough for it to be worthwhile to do so.
- Option ELIMINATE argues that COMPILER-LET complicates the language
and that providing this construct is not worth the associated
implementation cost.
Proposal (COMPILER-LET-CONFUSION:REPAIR):
Strike the existing definition of COMPILER-LET. Redefine it as follows:
COMPILER-LET [Special form]
COMPILER-LET is similar to LET, but it always makes special
bindings and makes those bindings visible only during
macroexpansion of forms in the body, not during the runtime
execution of those forms.
The intent is that some macros might macroexpand into calls to
COMPILER-LET in which the body would the contain references to
macros which access the variables in the COMPILER-LET.
The initial value forms of the bindings, if any, are always
evaluated in a null lexical context, regardless of whether the
COMPILER-LET expression is being interpreted or compiled.
The initial value forms of the bindings, if any, are evaluated in
a dynamic context where the bindings of any lexically enclosing
COMPILER-LET are visible, and where dynamic execution-time
environment may or may not be visible.
Implementation Note: Permitting the execution-time dynamic
environment to be visible when initializing COMPILER-LET variables
is a concession to some interpreters which may have to do this in
order to keep the cost down. Where feasible, implementors should
try not to make the runtime environment visible.
Rationale:
This gives a consistent description of COMPILER-LET which separates
issues of intent from those of implementation in a way that makes it
possible for portable code to make serious use of it, and which does
not force gratuitous incompatibilities between interpreters and
compilers.
This description of COMPILER-LET can be implemented without undue
cost by all implementations. See "Cost to Implementors" for details.
Cost to Implementors:
Modest, but nontrivial in some implementations.
In compiled code, and in interpreters doing a one-time semantic
prepass, it should be fairly easy for COMPILER-LET to cause the
variables to get bound (using PROGV) during semantic analysis.
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
This reduces the problem of writing a program capable of doing a
full macroexpansion. Many systems already have such a facility.
Pitman wrote such a facility in Cloe Runtime in order support
SYMBOL-MACROLET (before it was christened a special form); it was
about 750 lines of relatively straightforward, well-commented code.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
Most users will probably be happy for any interpretation which offers
them a future shot at portability.
Some users have indicated they dislike interpreters which do a semantic
prepass, because they like to be able to dynamically redefine macros
while debugging.
Proposal (COMPILER-LET-CONFUSION:ELIMINATE):
Remove COMPILER-LET from the language.
Rationale:
Some people think that having one less special form would simplify the
language. The revised COMPILER-LET semantics, which require
COMPILER-LET to make special bindings which are only visible during
expansion of macros which appear lexically within its body, are
not shared by any other feature in the language, and require a
fairly complex implementation technique. There are other
constructs which are strictly lexical that can be readily used
to solve the same kinds of problems that COMPILER-LET is intended to
be used for.
Cost to Implementors:
Minimal. Implementations could continue to support COMPILER-LET as
an extension.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
People who use COMPILER-LET would have to rewrite their programs to use
some other construct. As discussed above, most uses of COMPILER-LET
for communication between macros can be handled using MACROLET or
SYMBOL-MACROLET, though some perspicuity may be lost in the process.
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations (the ones from which COMPILER-LET originally came)
continue to use their pre-CLtL semantics. These semantics are useful, though
incompatible with CLtL (which they largely consider to simply be in error).
Users of those implementations probably use COMPILER-LET somewhat more
often since it has an intelligible behavior, but their code is not portable
since it relies on behaviors which are either contrary to or not guaranteed
by CLtL.
Benefits:
Either way, a potential area of incompatibility between compiled and
interpreted code would be eliminated.
Either way, a potential area of portability trouble would be very
drastically reduced (in the case of the REPAIR option) or eliminated
(in the case of the ELIMINATE option).
Discussion:
Pitman strongly favors COMPILER-LET-CONFUSION:REPAIR. He argues
against the idea of using MACROLET instead of COMPILER-LET, saying:
This is a little misleading because it's like saying you can
do without LET given that you have FLET. You can, but you lose some things
in the process:
Just as rewriting a LET using FLET might slow your computation, so too
a rewrite of COMPILER-LET using MACROLET might slow things down. However,
compilation speed is generally not weighted as heavily as execution speed
by many people, so the loss of speed here may not be as important.
Just as rewriting a LET using FLET might obscure the simplicity of your
intent, so too rewriting COMPILER-LET using MACROLET might obscure your
intent. You'd probably get used to recognizing idioms if you used it often
enough. Certainly this would be true if you didn't have LET. However,
COMPILER-LET is used less often, so not having it would mean that the
code you wrote instead would be much harder to read because people
wouldn't have the necessary familiarity with the idioms involved and so
wouldn't always understand them.
Sandra Loosemore responds:
The argument that using MACROLET is more inefficient than COMPILER-LET
is questionable. Both of the suggested implementation techniques for
COMPILER-LET involve considerable overhead.
If COMPILER-LET were not part of the language, people wouldn't think in
terms of rewriting COMPILER-LETs as MACROLETs; instead, they'd think of
how to use MACROLET in the first place to solve their problems. This
is what people who now use implementations with broken COMPILER-LETs
already do. Since MACROLET is now used much more frequently than
COMPILER-LET, that argues that people are much more familiar with
MACROLET idioms than COMPILER-LET idioms.
Also, note that the intent of the revised COMPILER-LET definition is
to make the binding only lexically visible within the body. Using
special binding for this purpose is troublesome. Both the MACROLET
and SYMBOL-MACROLET solutions are completely lexical and avoid all
the problems associated with special binding.
Glenn Burke thinks it needs to be emphasized that the code-walker
mentioned in the REPAIR proposal does not need to be portable. He
says:
The present wording makes it sound like a piece of cake to do with
portable code, when the reality is that a good fraction of CL cleanup
effort has involved the lack of capability of producing such a beast.
Without one or more of a number of proposals being accepted, a fully
correct portable code walker cannot be built, in my belief.
I object to the flippant attitude of just "presupposing" this
"trivial" function which "we know how to do".
∂13-Mar-89 1531 X3J13-mailer **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:30:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09104; Mon, 13 Mar 89 16:28:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02557; Mon, 13 Mar 89 16:28:37 -0700
Date: Mon, 13 Mar 89 16:28:37 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132328.AA02557@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
We don't expect to ask for a vote on this issue -- the writeup is just
being distributed so that we can refer to it in case the issue ever
comes up again. None of the suggestions listed here seemed to have a
great deal of support among people on the cl-compiler list, and all of
them have problems we haven't been able to resolve yet.
Forum: Compiler
Issue: DEFCONSTANT-NOT-WIRED
References: CLtL pages 68-69
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS,
PROCLAIM-LEXICAL,
DECLARE-TYPE-FREE,
DEFCONSTANT-SPECIAL
Category: ADDITION
Edit history: 09 Oct 1988, V1 by David Gray
27 Oct 1988, V2 by David Gray (new proposal)
10 Nov 1988, V3 by David Gray - updated proposal, rationale
and discussion sections in response to comments.
21 Nov 1988, V4 by David Gray - SPECIAL cancels CONSTANT;
CONSTANT doesn't require previous SPECIAL.
28 Nov 1988, V5 by Sandra Loosemore (clean up, fix
some consistency problems)
13 Mar 1989, V6 by Sandra Loosemore (start over)
Status: **DRAFT**
Problem description:
DEFCONSTANT performs two different functions:
- It says that it is an error to SETQ or rebind the variable which
is being defined as a constant.
- It gives the compiler permission to evaluate the initial value form
at compile time, and to build assumptions about the value into
programs being compiled.
In some cases, one would like to have the first behavior without
getting the second. In particular, one would like to get the same
behavior with regard to signalling errors and warnings that you get
with DEFCONSTANT.
Common Lisp provides no mechanism for specifying a variable should
be treated in this way.
Proposal DEFCONSTANT-NOT-WIRED:FIX-DEFPARAMETER:
This is what DEFPARAMETER was supposed to be used for. The description
of DEFPARAMETER needs to be clarified to reflect this, perhaps by
saying that a continuable error should be signalled if an attempt is
made to SETQ or rebind a variable defined with DEFPARAMETER.
Rationale:
DEFPARAMETER apparently derives from Zetalisp's DEFCONST construct,
which was used to indicate that values that would "never" change,
without licensing the compiler to make assumptions about that value.
However, most uses of DEFCONST have apparently been changed to use
DEFCONSTANT instead.
Objections:
Some people don't think that DEFPARAMETER was intended to be used
in this way and that this would be an incompatible change.
Proposal DEFCONSTANT-NOT-WIRED:RESTORE-DEFCONST:
Leave DEFPARAMETER alone but add another construct with the semantics
described above.
Rationale:
Some people don't think that DEFPARAMETER was intended to be used
in this way.
Objections:
We haven't been able to come up with a good name for this construct.
"DEFCONST" is too confusing and all of the other names that have
been suggested are too long. Also, having so many macros for
declaring variables with is confusing.
Proposal DEFCONSTANT-NOT-WIRED:NEW-DECLARATION:
Add a new CONSTANT declaration to the language which can be used to
declare that a variable cannot be SETQ'd or bound within the scope of
the declaration.
Rationale:
This solves the problem and also provides more general functionality.
For example, one could declare that a lexical variable won't be
SETQ'ed.
Objections:
We haven't been able to decide whether a CONSTANT declaration should
augment or replace a SPECIAL or LEXICAL declaration. How do you
initialize a variable that has been proclaimed CONSTANT? Some people
have objected to calling the declaration CONSTANT unless it is
equivalent to what a DEFCONSTANT does.
Proposal DEFCONSTANT-NOT-WIRED:ADD-OPTIONAL-ARGUMENT:
Add an optional argument to DEFCONSTANT to indicate whether the
compiler can make assumptions about the constant's value.
Rationale:
It would solve the problem.
Objections:
It would make DEFCONSTANT have different syntax from DEFVAR and
DEFPARAMETER.
Proposal DEFCONSTANT-NOT-WIRED:DEFINE-VARIABLE
Define a single macro, DEFINE-VARIABLE, that can be used to do what
DEFVAR, DEFPARAMETER, and DEFCONSTANT now do, plus the proposed new
functionality, plus possibly handle lexical variables as well
(if proposal PROCLAIM-LEXICAL passes). Arguments to the macro
could be used to control whether the value is allowed to change
and whether the compiler is allowed to make assumptions about the
value.
Rationale:
It would solve the problem without cluttering up the language with
new defining macros for every possible combination of behavior.
Objections:
Nobody has proposed anything definite yet.
Discussion:
This issue was discussed at length on the cl-compiler mailing list
last fall, without coming up with an acceptable proposal. It didn't
appear that any of the alternatives had a great deal of support. This
writeup summarizes the alternatives that have been proposed at various
times. Some of them (particularly NEW-DECLARATION) have been
considered in detail, and others (DEFINE-VARIABLE) haven't been
pursued at all.
∂13-Mar-89 1533 X3J13-mailer issue DEFINE-OPTIMIZER, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:33:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09197; Mon, 13 Mar 89 16:31:22 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02562; Mon, 13 Mar 89 16:31:17 -0700
Date: Mon, 13 Mar 89 16:31:17 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132331.AA02562@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue DEFINE-OPTIMIZER, version 5
Forum: Compiler
Issue: DEFINE-OPTIMIZER
References: Issue SYNTACTIC-ENVIRONMENT-ACCESS
Category: ADDITION
Edit history: 28-Sep-88, Version 1 by Pitman
10-Mar-89, Version 2 by Pitman (clarifications, new example),
10-Mar-89, Version 3 by Pitman & Loosemore
11-Mar-89, Version 4 by Pitman
13-Mar-89, Version 5 by Loosemore (discussion)
Status: Ready for release
Problem Description:
Often a general functional interface could be bypassed given explicit
knowledge of the arguments passed. This may happen when the arguments
are constant (or otherwise inferrable), an argument type is known (eg,
due to use of THE or DECLARE), or when some particular pattern of
optional, rest or keyword arguments is apparent.
Most implementations provide internally for optimization of generalized
function call interfaces to more specialized ones, but such an
optimization facility is not provided to Common Lisp users.
The absence of this facility in a portable fashion means that some
CL programs run slower than they need to in some implementations, or
else that some operators that should be implemented as functions end
up getting implemented as macros to assure needed efficiency.
Proposal (DEFINE-OPTIMIZER:NEW-FACILITY):
Introduce a facility for declaring compiler optimizations.
DEFINE-OPTIMIZER name arglist {declaration}* {form}* [Macro]
Defines a compiler optimizer for a function named NAME. The ARGLIST,
DECLARATIONS, and FORMS are treated exactly like the arglist,
declarations, and forms in a DEFMACRO. (The arglist may include
&ENVIRONMENT and &WHOLE.)
The argument NAME must name a function which has been previously
defined. The effects of defining an optimizer for a locally or
globally defined macro, a locally defined function, or a special
form are undefined.
When the optimizer is invoked, the forms are executed in the context
of bindings specified by the arglist, and two values are yielded,
RESULT and VALID-P. (If either of the first or second return value
is non-NIL, then the first return value is considered valid).
If the result is valid, it is a form which is preferable to evaluate
instead of the indicated call.
If a call to DEFINE-OPTIMIZER appears at top-level in a file
being processed by the file compiler, it also makes the optimizer
known at compile-time (similar to the way DEFMACRO makes a macro
definition known to the compiler).
OPTIMIZE-EXPRESSION-1 form env [Function]
Similar to MACROEXPAND-1. Invokes the optimizers for the top level of
FORM, but does not iterate on the result. Returns two values:
RESULT and CHANGED-P.
Note: If an optimizer returns a result which is not valid,
OPTIMIZE-EXPRESSION-1 hides the fact by returning FORM,NIL
rather than NIL,NIL.
OPTIMIZE-EXPRESSION form env [Function]
Iterates calling OPTIMIZE-EXPRESSION-1 until the CHANGED-P result
is NIL.
An implementation must save optimizer definitions created by
DEFINE-OPTIMIZER in case OPTIMIZE-EXPRESSION is attempted, but is
not actually required to call OPTIMIZE-EXPRESSION itself. Interpreters,
for example, may choose to just call the unoptimized form.
Using FLET and MACROLET shadow not only functions and their SETF methods,
but also their optimizers. No portable facility is provided for creating
locally defined optimizers.
The effect of defining optimizations for functions in the LISP package
is not defined. (In some implementations, this would clobber or conflict
with existing advice that may be of higher quality.)
The editor is advised that a non-binding style note such as the
following would also be appropriate:
In general, it is poor style for a programmer to define optimizers for
functions that he does not maintain. This is because the correct
implementation of an optimizer for a function usually depends on an
understanding of the internals of that function. As such, a function
definition and any optimizers should be maintained as a unit so that
they can changes in either can be synchronized as appropriate with the
other.
The effect of using DEFINE-OPTIMIZER on a function declared to be
INLINE is ``unspecified but harmless'' (per new Error Terminology).
That is, since both operations (optimization and inlining) are intended
to be semantics-preserving, no functional difference should be observed.
However, in some implementations the presence of an optimizer may thwart
the ability to inline, or vice versa. Writers of portable code are
encouraged to use either DEFINE-OPTIMIZER or (PROCLAIM '(INLINE ...))
but not both.
Example:
;; These examples are taken literally from the Macsyma sources,
;; modified only to change DEFOPT to DEFINE-OPTIMIZER. The comments
;; were specially written for the X3J13 audience.
;; M+ is adds a Macsyma expression to another Macsyma expression.
;; The Macsyma internal representation for the sum of X and Y is
;; ((MPLUS) X Y). A all the real work is done by SIMPLIFY, which
;; reduces the expression as needed necessary. However, SIMPLIFY
;; is very complicated, and considerable speed can be gained by
;; entering it at specific known places.
(DEFUN M+ (&REST TERMS)
(PROTECT-&REST-VARIABLE TERMS)
(SIMPLIFY `((MPLUS) ,@TERMS)))
(DEFINE-OPTIMIZER M+ (&REST TERMS)
(COND ((= (LENGTH TERMS) 2) `(ADD2* ,@TERMS))
(T `(ADDN (LIST ,@TERMS) NIL))))
;; M- negates a Macsyma expression, or substracts two Macsyma
;; expressions. Once you figure out which of the two operations is
;; to be done, the problem is similar to that of M+ above. However,
;; often the decision can be made at compile time. In this case,
;; INLINE functions would have worked ok, except that not all
;; implementations do inlining, and even those that do may fail to
;; recognize that EXP2 being NIL means that a test can be eliminated
;; or dead code can be eliminated. Using optimizers is far more
;; likely to be useful in practice.
(DEFUN M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
(M--INTERNAL-NEGATE EXP1)
(M--INTERNAL-SUBTRACT EXP1 EXP2)))
(DEFINE-OPTIMIZER M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
`(M--INTERNAL-NEGATE ,EXP1)
`(M--INTERNAL-SUBTRACT ,EXP1 ,EXP2)))
Rationale:
Many large portable applications expect such a facility on an
implementation-specific basis. Others would use one if available.
Even if implementations don't use the provided optimizers primitively,
user macros and code-walkers can invoke them, so the facility wouldn't
be completely useless even in those implementations.
Current Practice:
Symbolics Genera provides an optimizer facility which is more elaborate
but not fundamentally incompatible with this facility.
Many (if not most) serious implementations provide a similar facility.
For example, Lucid provides "compiler macros" which serve the same
purpose.
Cost to Implementors:
Since the implementation is not required to use this facility, the
cost of providing the proposed support is very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Portable code would be slower than necessary in some situations.
Benefits:
Some existing non-portable code could become portable.
Aesthetics:
Providing a separate optimizer definition from a main function definition
makes a possibility that the optimizer and main function could drift out
of synch. However, most places where this gets used in the first place
are places where speed is of paramount importance and the programmer is
willing to invest effort in maintaining things correctly and to accept the
risk of lossage if s/he fails.
This is a fairly clean and simple extension which adds significant
power to the compiler.
Discussion:
Pitman strongly supports this proposal, the design of which is modeled
directly after that which has been used in Macsyma for many years.
Information about argument type can come from two different sources:
THE and declarations (via PROCLAIM or DECLARE). The former information
is portably accessible, the latter is not. While a separate proposal
(SYNTACTIC-ENVIRONMENT-ACCESS) for allowing program access to type
declarations would be make this facility more useful, it is still
quite useful without it, as the examples from Macsyma illustrate.
Some implementations provide a way to provide more than one optimizer
for the same function. A multiple optimizer facility can be written
in terms of this simpler facility and vice versa, so the simpler of
the two facilities is proposed here.
Some people have suggested that they would like to see a pattern
matching facility integrated into this facility. The design of a
facility that would satisfy everyone would take a lot of time and
effort. At this point, there is no chance that the design of such a
facility would occur in time for acceptance into the standard.
The choice is this or nothing. Pitman thinks the language is much
better off with some form of optimization support than none.
Loosemore says:
Although I don't really think this is an essential feature to include
in the standard, I don't have any strong objection to adding it. If
people think it's a good idea to provide a standard interface for this
kind of thing, this is a good proposal for doing it -- it's fairly
simple, doesn't introduce any radically new ideas, and is general
enough to allow alternate interfaces (such as the pattern matcher) to
be layered on top of it.
Barrett says:
I think you may have gotten the sense of Cris' INLINE comment wrong.
I believe what he was suggesting is that NOTINLINE declarations should
inhibit optimizers, a position I agree with. I also think it would be
better to specify the behavior when both an optimizer and an inline
are present, rather than leaving it 'unspecified but harmless'. I'd
suggest that optimizers have precedence. The rational is that this
allows an optimizer to look for special patterns in the arguments, and
to defer to the inline if it doesn't find them. Of course, there's
the problem that the compiler might then ignore the inline.
∂13-Mar-89 1536 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:36:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09314; Mon, 13 Mar 89 16:33:46 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02565; Mon, 13 Mar 89 16:33:44 -0700
Date: Mon, 13 Mar 89 16:33:44 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132333.AA02565@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Forum: Compiler
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue COMPILER-LET-CONFUSION
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
16-Dec-88, V5 by Sandra Loosemore (major restructuring)
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
07-Jan-89, V7 by Sandra Loosemore (add example)
09-Mar-89, V8 by Sandra Loosemore (more restructuring)
Status: Ready for release
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.
On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context. Compilers, for example, may not recognize these forms
properly in other than top-level contexts". At least one implementation
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.
Proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW:
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations. However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.
(2) Remove the language on p. 145 of CLtL, which states that macro
functions are always defined in the null lexical environment. Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
(3) Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially. The order in which
non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
Rationale:
This proposal makes the rules for when defining macros cause
compile-time side effects to be exactly the same as the rules for when
(EVAL-WHEN (COMPILE) ...) causes compile-time evaluation. This
provides a simple implementation technique.
Item (3) serves two purposes. First, it guarantees users that
compile-time side-effects from top-level EVAL-WHEN forms or defining
macros will happen in the correct order; programmers can depend upon
the compile-time side-effects of a top-level form being visible during
the compilation of subsequent forms. Second, it allows compilers to
perform certain kinds of source-to-source transformations that change
the order of subforms.
For instance, the following example from CLtL
(let ((old-count *access-count*))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(setq *access-count* old-count)))
is entirely equivalent to:
(let ((old-count *access-count*))
(let ((thunk #'(lambda () (setq *access-count* old-count))))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(funcall thunk))))
(This is a real example from the A-Lisp compiler, which implements
UNWIND-PROTECT by having it push a "thunk" to perform the cleanup
actions onto the catch stack before executing the protected form.)
Current Practice:
Most implementations do allow defining macros in non-top-level places.
However, the rules for when they cause compile-time side-effects are
not always the same as those for EVAL-WHEN. This is the case in
Lucid Common Lisp, for example.
Cost to implementors:
Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special when they
appear at top-level is removed, since their behavior can be explained
using EVAL-WHEN as a primitive. Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.
Discussion:
This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL. In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
∂13-Mar-89 1545 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:45:11 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09664; Mon, 13 Mar 89 16:42:59 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02574; Mon, 13 Mar 89 16:42:54 -0700
Date: Mon, 13 Mar 89 16:42:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132342.AA02574@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
This issue has been giving us a lot of trouble for a long time. A few
people on the cl-compiler mailing list have expressed discontent with
the proposals included here, but the dissenters haven't been able to
come up with an acceptable alternative proposal that they can all agree
on.
Issue: EVAL-WHEN-NON-TOP-LEVEL
Forum: Compiler
References: EVAL-WHEN (CLtL pp69-70),
Issue DEFINING-MACROS-NON-TOP-LEVEL
Issue COMPILED-FUNCTION-REQUIREMENTS
Issue IN-PACKAGE-FUNCTIONALITY
Issue LOCALLY-TOP-LEVEL
Category: CLARIFICATION/CHANGE
Edit History: 06-May-88, Version 1 by Sandra Loosemore
16-Dec-88, Version 2 by Loosemore (alternate direction)
30-Dec-88, Version 3 by Loosemore (minor wording changes)
07-Jan-89, Version 4 by Loosemore (update discussion)
09-Feb-89, Version 5 by Pitman and Moon (some major changes)
09-Mar-89, Version 6 by Loosemore (clean up wording)
Status: Ready for release
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
locations? Even if it is legitimate, what does it mean?
Another issue, referred to here as ``the EVAL-WHEN shadowing problem,''
is that some people have complained that shadowing the symbols EVAL,
COMPILE, or LOAD means that you have to also either shadow EVAL-WHEN
and define it to recognize the new symbol, or else you must resign
yourself to writing (EVAL-WHEN (... LISP:EVAL ...) ...),etc. all over.
While the goal here is not to solve this problem, it might be possible
to solve both problems at once.
There are two proposals presented here, GENERALIZE-EVAL and
GENERALIZE-EVAL-NEW-KEYWORDS.
Background/Analysis:
The proposal which follows was constructed with the following goals
in mind:
1. The lexical and dynamic environment for the EVAL-WHEN body should
be the same for each situation. That is, the body should ``mean
the same thing'' regardless of which situation is being processed.
2. The evaluation context for EVAL-WHEN should be the current
lexical environment.
3. At execution time, EVAL-WHEN should always return the result of
its last form if execution of the body occurred, or NIL if the
body was not executed.
4. If a top-level EVAL-WHEN has a LOAD keyword, its body should
inherit top-level-ness during normal processing. This permits the
use of (EVAL-WHEN (EVAL COMPILE LOAD) ...) at top-level to mean
simply "Do whatever would normally be done for this body, but
also do something at compile time." This, in turn, will later be
the key to allowing defining forms to be usefully described in
terms of EVAL-WHEN.
5. Non-top-level expressions should have no effect until they are
executed. This is the key to making sure that any necessary
environment is present. Since the COMPILE keyword forces effects
to occur earlier than execution time, it follows from this that
any correct solution must not allow the COMPILE keyword to have
an effect at other than top-level.
To accomplish these goals, we formulated the following model:
The purpose of EVAL-WHEN is to accomodate the fact that some of the
semantic processing of an expression may usefully be partitioned
between compile time and run time in some circumstances.
(EVAL-WHEN (EVAL) <code>)
describes a general technique for accomplishing some particular goal
at normal program execution time. However, the pair of expressions
(EVAL-WHEN (COMPILE) <code-A>)
(EVAL-WHEN (LOAD) <code-B>)
can be used to describe an alternate technique for implementing part
of the effect (A) at compile-time, and part of the effect (B) at
load-time.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL):
Replace the description of EVAL-WHEN with the following:
EVAL-WHEN ({situation}*) {form}* [Special Form]
The body of an EVAL-WHEN form is processed as an implicit PROGN, but
only in the situations listed. Each SITUATION must be a symbol,
either COMPILE, LOAD, or EVAL.
The use of COMPILE and LOAD controls whether and when processing
occurs for top-level forms. The use of EVAL controls whether
processing occurs for non-top-level forms.
The EVAL-WHEN construct may be more precisely understood in terms of
a model of how the file compiler, COMPILE-FILE, processes forms in a
file to be compiled.
Successive forms are read from the file by the file compiler using
READ. These top-level forms are normally processed in what we call
`not-compile-time' mode. There is one other mode, called
`compile-time-too' mode, which can come into play for top-level
forms. The EVAL-WHEN special form is used to annotate a program
in a way that allows the program doing the processing to select
the appropriate mode.
Processing of top-level forms in the file compiler works as follows:
* If the form is a macro call, it is expanded and the result is
processed as a top-level form in the same processing mode
(compile-time-too or not-compile-time).
* If the form is a PROGN form, each of its body forms is
sequentially processed as top-level forms in the same processing
mode.
* If the form is a COMPILER-LET, MACROLET, or SYMBOL-MACROLET,
the file compiler makes the appropriate bindings and recursively
processes the body forms as an implicit top-level PROGN with those
bindings in effect, in the same processing mode.
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
COMPILE LOAD EVAL compile-time-too Action
Yes Yes -- -- Process body in compile-time-too mode
No Yes Yes Yes Process body in compile-time-too mode
No Yes Yes No Process body in not-compile-time mode
No Yes No -- Process body in not-compile-time mode
Yes No -- -- Evaluate body
No No Yes Yes Evaluate body
No No Yes No do nothing
No No No -- do nothing
"Process body" means to process the body as an implicit top-level
PROGN. "Evaluate body" means to evaluate the body forms as in
implicit PROGN in the dynamic execution context of the compiler and
in the lexical environment in which the EVAL-WHEN appears.
* Otherwise, the form is a top-level form that is not one of the
special cases. If in compile-time-too mode, the compiler first
evaluates the form and then performs normal compiler processing
on it. If in not-compile-time mode, only normal compiler
processing is performed. [The nature of this processing is
defined more precisely in issue COMPILED-FUNCTION-REQUIREMENTS.]
Any subforms are treated as non-top-level forms.
For an EVAL-WHEN form that is not a top-level form in the file compiler
(that is, one of: in the interpreter; in COMPILE; or in the file
compiler but not at top-level), if the EVAL situation is specified,
its body is treated as an implicit PROGN. Otherwise, the EVAL-WHEN
form returns NIL.
Clarifications/Consequences:
The following effects are logical consequences of the above proposal:
* It is never the case that the execution of a single EVAL-WHEN
expression will execute the body code more than once.
* The keyword `EVAL' is a misnomer because execution of
the body need not be done by EVAL. In compiled code, such as
(DEFUN FOO () (EVAL-WHEN (EVAL) (PRINT 'FOO)))
the call to PRINT should be compiled.
* Macros intended for use in top-level forms should arrange for all
side-effects to be done by the forms in the macro expansion.
The macro-expander itself should not do the side-effects.
Wrong: (defmacro foo ()
(really-foo)
`(really-foo))
Right: (defmacro foo ()
`(eval-when (compile eval load) (really-foo)))
Adherence to this convention will mean that such macros will behave
intuitively when placed in non-top-level positions.
* Placing a variable binding around an EVAL-WHEN reliably captures the
binding because the `compile-time-too' mode cannot occur (because
introducing a variable binding would mean we were not at top level).
For example,
(LET ((X 3))
(EVAL-WHEN (EVAL LOAD COMPILE) (PRINT X)))
will print 3 at execution [load] time, and will not print anything at
compile time. This is important so that expansions of DEFUN and
DEFMACRO can be done in terms of EVAL-WHEN and can correctly capture
the lexical environment.
(DEFUN BAR (X) (DEFUN FOO () (+ X 3)))
might expand into
(DEFUN BAR (X)
(PROGN (EVAL-WHEN (COMPILE)
(COMPILER::NOTICE-FUNCTION-DEFINITION 'FOO '(X)))
(EVAL-WHEN (EVAL LOAD)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))))
which would be treated the same as
(DEFUN BAR (X)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))
by the above rules.
Test Cases:
;; #1: The EVAL-WHEN in this case is not at top-level, so only the EVAL
;; keyword is considered. At compile time, this has no effect.
;; At load time (if the LET is at top level), or at execution time
;; (if the LET is embedded in some other form which does not execute
;; until later) this sets (SYMBOL-FUNCTION 'FOO1) to a function which
;; returns 1.
(LET ((X 1))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO1) #'(LAMBDA () X))))
;; #2: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting
;; (SYMBOL-FUNCTION 'FOO2) to a function which returns 2.
(EVAL-WHEN (EVAL LOAD COMPILE)
(LET ((X 2))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO2) #'(LAMBDA () X)))))
;; #3: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting the
;; function cell of FOO3 to a function which returns 3.
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO3) #'(LAMBDA () 3)))
;; #4: This always does nothing. It simply returns NIL.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO4)))
;; #5: If this form occurs at top-level of a file to be compiled, FOO5 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (EVAL)
(PRINT 'FOO5)))
;; #6: If this form occurs at top-level of a file to be compiled, FOO6 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (EVAL LOAD)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO6)))
Rationale:
This is compatible with any guarantees made by CLtL, and extends the
behavior usefully to non-top-level situations.
This gives a useful meaning to EVAL-WHEN that supports useful and
predictable behavior if defining macros are used in a non-top-level
situation.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS):
As in GENERALIZE-EVAL, but rename the EVAL keyword to :EXECUTE,
the COMPILE keyword to :COMPILE-TOPLEVEL, and LOAD keyword to
:LOAD-TOPLEVEL.
Deprecate the use of keywords EVAL, COMPILE, and LOAD to EVAL-WHEN.
For compatibility, they are supported in EVAL-WHEN
at top-level, but their meaning is not defined elsewhere.
Rationale:
The fact that the situation keywords chosen are not the same as
those now used means that the change can be added in a way that
is truly upward compatible (not only with CLtL but with existing
practice in implementations which have chosen to extend or `clarify'
the definition given in CLtL) since the meaning of EVAL, COMPILE,
and LOAD in non-top-level situations (which was never spelled
out in CLtL) can legitimately differ from the meaning of these
new keywords.
Using other names and/or the keyword package for the names of
situations solves the EVAL-WHEN shadowing problem.
The name `execute' does not promote the confusion that the body of an
EVAL-WHEN must be executed only in the evaluator. It also does not
promote the confusion that the body of an EVAL-WHEN, regardless of when
executed, must run interpreted.
The names `compile-toplevel' and `load-toplevel' emphasize the fact
that these cases are not interesting in non-top-level positions.
Current Practice:
In Symbolics Genera, the interpreter permits EVAL-WHEN in non-top-level
positions in a way that is compatible with this proposal but both the
COMPILE and COMPILE-FILE functions complain about EVAL-WHEN in a
non-top-level position.
Both Lucid Common Lisp and Kyoto Common Lisp already interpret the
EVAL keyword to mean "execute" in non-top-level situations. Both of
these implementations also make (EVAL-WHEN (LOAD) ...) suppress
compile-time "magic" from defining macros such as DEFMACRO.
IIM describes its EVAL-WHEN as:
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
Note that the interpretation of the EVAL situation and the nesting
behavior is different.
Cost to Implementors:
The actual change to EVAL-WHEN in both cases is probably fairly
localized and straightforward to make in most or all implementations.
The second-order costs of proposal GENERALIZE-EVAL will vary depending
on whether existing implementations have extended the definition of
EVAL-WHEN in incompatible ways. If an implementation has made such
extensions, there may be user and system code which depends on them
and the cost of converting that code may be non-trivial. There is
presumably also documentation impact.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS avoids most or all of the
second-order costs of proposal GENERALIZE-EVAL.
The compiler processing for top-level forms might be implemented
something like:
;;; Forms read by the file compiler are passed to PROCESS-TOP-LEVEL-FORM
;;; with a env compile-time-too both NIL.
(defun process-top-level-form (form env compile-time-too)
(setq form (macroexpand form env))
(cond ((not (consp form))
nil)
((eq (car form) 'progn)
(dolist (f (cdr form))
(process-top-level-form f env compile-time-too)))
((eq (car form) 'compiler-let)
(process-compiler-let form env compile-time-too))
((eq (car form) 'macrolet)
(process-macrolet form env compile-time-too))
((eq (car form) 'symbol-macrolet)
(process-symbol-macrolet form env compile-time-too))
((eq (car form) 'eval-when)
(process-eval-when form env compile-time-too))
(t
(if compile-time-too
(internal-eval form env))
(compile-form form env))
))
(defun process-eval-when (form env compile-time-too)
(let* ((situations (cadr form))
(body (cddr form))
(compile-p (member 'compile situations))
(load-p (member 'load situations))
(eval-p (member 'eval situations)))
(cond ((or (and compile-p load-p)
(and eval-p load-p compile-time-too))
(process-top-level-form `(progn ,@body) env t))
(load-p
(process-top-level-form `(progn ,@body) env nil))
((or compile-p
(and eval-p compile-time-too))
(dolist (f body)
(internal-eval f env)))
(t
nil))))
;;; PROCESS-COMPILER-LET, PROCESS-MACROLET, and PROCESS-SYMBOL-MACROLET
;;; do the obvious things.
;;; INTERNAL-EVAL evaluates "form" in lexical environment "env".
Cost to Users:
Technically, none. Either proposal is technically upward compatible
with CLtL.
Proposal GENERALIZE-EVAL might force some extended implementations to
change incompatibly. As such, some users who depend on
implementation-dependent extensions might have to adjust their code
somewhat to deal with those changes.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS does not force implementations
to change incompatibly, so has no forced impact on users.
Cost of Non-Adoption:
EVAL-WHEN is a mess. Using it as the low-level substrate into which
defining macros should expand, and guaranteeing any predictable effects
of those macros in non-top-level situations is currently difficult and
would continue to be so in the absence of some resolution on this issue.
Benefits:
The costs of non-adoption would be avoided: it would be possible to
use EVAL-WHEN in many situations where it cannot currently be used
reliably.
The portability of many existing tools which use EVAL-WHEN internally
in macros will be enhanced.
Aesthetics:
This generalization of the meaning makes the purpose and uses of
EVAL-WHEN less mysterious. In that sense, aesthetics are simplified
somewhat.
Discussion:
The cleanup issue LOCALLY-TOP-LEVEL would make LOCALLY also "pass
through" top-level-ness to its body. The reason why that is not
addressed in this issue is that it involves making LOCALLY a special
form.
Pitman and Moon don't care whether we say `top level,' `top-level,' or
`toplevel.' The spelling choices in this writeup are arbitrary. If
necessary, the proposal GENERALIZE-EVAL-NEW-KEYWORDS could be amended
to propose :COMPILE-TOP-LEVEL, etc.
Pitman, Moon, and Bob Laddaga (a Symbolics Cloe implementor) support
both of these proposals. Pitman and Laddaga have a preference for
GENERALIZE-EVAL-NEW-KEYWORDS. Moon is neutral about which should be
preferred.
Sandra Loosemore says:
I still feel somewhat uncomfortable with the definition of EVAL-WHEN
presented here, mostly because its nesting behavior is so unintuitive
(as in test case number 6). We have also had a hard time in deciding
what the term "top-level" really means; the definition presented here
is rather arbitrary. However, since we have run out of time in which
to come up with acceptable alternatives, I'm willing to go along with
proposal GENERALIZE-EVAL. It is compatible with the description in
CLtL but presented in a more coherent way, and I think it is an
improvement. On the other hand, I don't really like the idea of
changing the names of the keywords; if we are going to make an
incompatible change, the right thing to do would be to throw out
EVAL-WHEN entirely and start from scratch.
∂13-Mar-89 1601 X3J13-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:57:19 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10215; Mon, 13 Mar 89 16:55:08 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02585; Mon, 13 Mar 89 16:55:05 -0700
Date: Mon, 13 Mar 89 16:55:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132355.AA02585@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
This issue is still under discussion. There are three proposals
presented formally and two more mentioned informally in the discussion
section, but it appears that the decision is really between proposal
DYNAMIC and everything else.
Forum: Compiler
Issue: MACRO-ENVIRONMENT-EXTENT
References: CLtL p. 145-146
Issue COMPILER-LET-CONFUSION
Issue MACRO-CACHING
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue SYNTACTIC-ENVIRONMENT-ACCESS
CLOS Chapter 3 (89-003)
Category: CLARIFICATION,CHANGE
Edit History: V1, 10 Jan 1989, Sandra Loosemore
V2, 09 Mar 1989, Sandra Loosemore
V3, 13 Mar 1989, Sandra Loosemore (last-minute discussion)
Status: **DRAFT**
Problem Description:
What is the extent of environment objects received as the &ENVIRONMENT
argument of a macro function?
CLtL says that &ENVIRONMENT is "useful primarily in the rare cases
where a macro definition must explicitly expand any macros in a
subform of the macro call before computing its own expansion". While
this suggests that macro environment objects are typically used within
the dynamic scope of the macro function, the use of the word
"primarily" (rather than "only" or "exclusively" or some similarly
strong language) suggests that there may be other legitimate uses for
environment objects. But, because CLtL is silent about what those
uses might be, many users and implementors are under the impression
that environment objects have only dynamic extent.
There are some situations where using environment objects as if they
had indefinite extent provides a very useful viewpoint from which to
solve a problem. Consider the following example:
(defmacro typed-var (var) var)
(defmacro local-type-declare (declarations &body forms &environment env)
`(macrolet ((typed-var (&whole w var)
(let ((type (assoc var ',declarations)))
(if type
`(the ,(cadr type) ,var)
(macroexpand w ',env)))))
,@forms))
(defun f (x y)
(local-type-declare ((x fixnum) (y float))
(+ (typed-var x) (typed-var y))))
Here, local macro TYPED-VAR is defined to look first in the innermost
lexical environment for information about the variable, and if there
isn't any then it recurses on the next outermost lexical environment.
The global definition of TYPED-VAR provides a terminal case to stop
the recursion.
There are other situations where the extent of macro environment
objects comes into play. For example, if we allow caching of macro
expansions (issue MACRO-CACHING), environments must have indefinite
extent. It is unclear whether CLOS would be affected by allowing
macro environments to have only dynamic extent. (The descriptions of
the CLOS defining macros in document 89-003 seem to imply that the
value of the &ENVIRONMENT argument appears in the expansion of the
macro, but there now seems to be sentiment that the model of how the
defining macros work that is presented there is broken.)
Proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or as the argument to a *MACROEXPAND-HOOK*
function have indefinite extent.
Note that implementations are not permitted to destructively modify
lexical information in environment objects once they have been passed
to a macro function. It is, however, permissible to add or remove
global definitions that are accessible through the environment.
Rationale:
This legitimizes the use of idioms which depend on macro environments
having indefinite extent.
Since data objects in Lisp otherwise have indefinite extent, it is
more consistent to give environment objects indefinite extent as
well.
Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or with a *MACROEXPAND-HOOK* function
have only dynamic extent; the consequences are undefined if they are
referred to outside the dynamic extent of that macro function or hook
function.
Rationale:
This allows implementations to use somewhat more efficient techniques
for representing environment objects. For example, the storage could
be stack-allocated, or environments could be bashed destructively
instead of always being freshly heap-allocated.
Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC-WITH-COPIER:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or with a *MACROEXPAND-HOOK* function
have only dynamic extent; the consequences are undefined if they are
referred to outside the dynamic extent of that macro function or hook
function.
Add a new function:
COPY-ENVIRONMENT environment [function]
This function returns an environment object that is semantically
equivalent to "environment" (which must be an object of the type
received with an &ENVIRONMENT argument to a macro or as an argument to
a *MACROEXPAND-HOOK* function), but which may safely be referred to
outside the dynamic extent of the macro function. This function is
permitted to return an object that is EQ to its argument if that
object may be safely used.
Rationale:
This allows implementations to use somewhat more efficient techniques
for representing environment objects. For example, the storage could
be stack-allocated, or environments could be bashed destructively
instead of always being freshly heap-allocated.
It also allows programmers to use idioms that rely on environment
objects having indefinite extent.
Current Practice:
Macro environments appear to have indefinite extent in Lucid Common
Lisp, Kyoto Common Lisp, CMU Common Lisp (at least in the
interpreter), Utah Common Lisp, and A-Lisp. A-Lisp internally uses
the kind of idiom shown in the example above to implement FLET,
LABELS, and FUNCTION as macros.
Macro environments are stack-allocated in Symbolics Genera, and hence
have dynamic extent.
Macro environments also have dynamic extent on the TI Explorer,
because the compiler uses special variables are used to keep track of
lexical definitions.
Cost to implementors:
For proposal INDEFINITE, some implementations would need to change. A
simple implementation of macro environments that would fit the
requirements of this proposal is to represent them as lists, pushing
information for inner contours onto the front of the list as the
contour is entered and popping the list when the contour is exited.
For proposal DYNAMIC, there is no associated implementation cost.
For proposal DYNAMIC-WITH-COPIER, the implementation cost is unknown
but probably fairly small in most implementations.
Cost to users:
For proposal INDEFINITE, there is no associated cost to users.
For proposal DYNAMIC, users would not be able to portably use a
simple and elegant approach to solving certain kinds of problems.
For proposal DYNAMIC-WITH-COPIER, users would have to remember to make
a copy of an environment object in some situations.
Benefits:
It is made clear whether treating environment objects as if they had
indefinite extent is portable usage.
Discussion:
Proposal SYNTACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE
includes adding a function called AUGMENT-ENVIRONMENT which could also
be used to create a copy of an environment. However, it returns an
object with the same extent as its argument, and therefore can not
replace the function COPY-ENVIRONMENT under proposal
DYNAMIC-WITH-COPIER.
We have also considered a couple of other alternatives on this
issue.
One alternative would be to give "remote" environments created by
COMPILE-FILE the extent of that call to COMPILE-FILE, while "local"
environments (the null lexical environment and environments created by
COMPILE and EVAL) would have indefinite extent.
Another alternative would be to say that environments created by
COMPILE-FILE, COMPILE, or EVAL have a dynamic extent that includes the
time when any other macro calls appearing lexically within the
expansion returned by the macro function are expanded. This is
similar to the extent of the special bindings made by COMPILER-LET.
Both of these proposals could be combined with adding a copier
function to deal with those implementations where environments are
stack-allocated. They would both solve the extent problem for the
example given in the problem description section, but not the general
problem of macro caching. In conjunction with the proposals for issue
SYNTACTIC-ENVIRONMENT-ACCESS, they would both require some
modifications to implementations that currently give macro
environments dynamic extent.
Loosemore supports proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE.
Moon says:
My opinion is that anything in CLOS that seems to depend on indefinite
extent for macro environments is broken and needs to be fixed. It's not
broken because of the environment extent, but for other reasons.
Thus I believe in dynamic extent for environments.
Neil Goldman says:
In my code walker I have a pretty ugly way of dealing with MACROLET
that would have been trivial if I could have counted on the
ENVIRONMENT having indefinite extent. There may be some cleaner way
than what I did, but I just looked at PCL's code walker, and it also
is much more complex than would be necessary if environments had
indefinite extent.
∂13-Mar-89 1610 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:10:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10862; Mon, 13 Mar 89 17:08:13 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02608; Mon, 13 Mar 89 17:08:10 -0700
Date: Mon, 13 Mar 89 17:08:10 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140008.AA02608@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
This is a new writeup for an issue that was first brought up several
months ago. We haven't had time to review it thoroughly yet.
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
References: CLtL p. 182 [package functions],
p. 156 [PROCLAIM], p. 439 [COMPILE-FILE];
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue IN-PACKAGE-FUNCTIONALITY
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, CHANGE, ADDITION
Edit History: 15 Sep 88, V1 by David Gray
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
11 Mar 89, V3 by Sandra Loosemore (rewrite)
13 Mar 89, V4 by Sandra Loosemore (discussion)
Status: **DRAFT**
Problem Description:
Should the compiler treat top-level calls to PROCLAIM specially?
Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
to the following package functions as though they were wrapped in an
(EVAL-WHEN (COMPILE LOAD EVAL) ...):
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
CLtL is silent on whether top-level calls to PROCLAIM should also be
evaluated at compile-time, which presumably means they shouldn't be.
However, some implementations do evaluate PROCLAIM at compile-time.
In the model of how COMPILE-FILE works that is presented in issues
EVAL-WHEN-NON-TOP-LEVEL and DEFINING-MACROS-NON-TOP-LEVEL, the special
form EVAL-WHEN is the only thing that can cause compile-time evaluation
to occur. The compile-time side-effects of macros such as DEFMACRO
and DEFPACKAGE are explained by having them include EVAL-WHEN in their
expansions. Any functions that are treated specially, however, must
be included as special cases in the compiler.
Proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO would remove the
requirement that the package functions be treated specially. Do we
wish to make an exception to the model for PROCLAIM?
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:
Require COMPILE-FILE to treat top-level calls to PROCLAIM as if they
were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...).
Rationale:
Proclamations affect compilation semantics and should be made
available to the compiler.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation.
Rationale:
This makes the semantics of COMPILE-FILE more uniform and easier
to understand. In particular, if we remove the magic compile-time
behavior of the package functions, it seems silly to add another
exception for PROCLAIM.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
Add a new macro:
DEFPROCLAIM &rest decl-specs [Macro]
This macro PROCLAIMs the given <decl-specs>, which are not
evaluated. If a call to this macro appears at top-level in a file
being processed by the file compiler, the proclamations are also
made at compile-time. As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DEFPROCLAIM persist after the file has been compiled.
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation,
or use the macro DEFPROCLAIM.
Rationale:
The macro makes the proclamations available to the compiler in such
a way that does not require any special exceptions to be made in
the model of how COMPILE-FILE works.
Current Practice:
The TI explorer apparently implements proposal YES, except that
(EVAL-WHEN (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything.
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
Lisps developed at Utah (UCL, A-Lisp, PSL/PCLS) do not give PROCLAIM
any special compile-time handling.
Lucid does not evaluate calls to PROCLAIM at compile-time.
The IIM compiler has special top-level handling for PROCLAIM when
the argument is a constant. The information is recorded in the remote
environment.
Cost to implementors:
Since implementations are already required to have a mechanism for
compile-time handling of the package functions, it would probably
only require minor adjustments to add handling for PROCLAIM.
Cost to users:
For proposal YES, users would have no way to suppress compile-time
evaluation of a top-level call to PROCLAIM. Wrapping it in an
(EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.
Under any of these proposals, some users would probably have to
make minor changes to their code.
Benefits:
Users will know what to expect when they use PROCLAIM.
Costs of Non-Adoption:
Users will not know what to expect when they use PROCLAIM.
Aesthetics:
At least two people consider requiring magic behavior for certain
top-level function calls to be "semantically bletcherous". Removing
all special cases for functions that are implicitly evaluated at
compile-time would simplify the model of how COMPILE-FILE works.
Programs look cleaner if EVAL-WHEN is only needed for unusual cases
instead of being required for the normal cases.
Discussion:
The first version of this writeup also included REQUIRE with PROCLAIM,
but we have now voted to remove REQUIRE from the language entirely.
It also specified that OPTIMIZE proclamations should only have a local
effect within the file being compiled. This was removed for
consistency with other compile-time side-effects (such as those from
DEFMACRO), where their persistence is explicitly left unspecified.
Loosemore favors proposal NO, but wouldn't oppose proposal NEW-MACRO.
Kim Barrett says:
Proposal YES violates the general approach we've been taking of trying
to limit side-effects on the local environment during compilation.
Proposal NO makes PROCLAIM virtually worthless.
Proposal NEW-MACRO -- While this matches up with other stuff we've
been doing, I'm concerned about two things. First, I really dislike
the name DEFPROCLAIM. This thing isn't defining anything! It sounds
like something that modifies the behavior of PROCLAIM, not something
that actually makes a proclamation. Second, I'm concerned about the
cost to users. I think the statement that
"Under any of these proposals, some users would probably have to make
minor changes to their code."
is rather misleading for this case. There are a lot of PROCLAIMs out
there.
Loosemore replies:
....but all of those uses of PROCLAIM are already nonportable. No
matter what we do here, somebody is going to get burned.
Suggestions for better names for the macro are welcome.
∂13-Mar-89 1627 X3J13-mailer issue WITH-COMPILATION-UNIT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:27:44 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11422; Mon, 13 Mar 89 17:25:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02634; Mon, 13 Mar 89 17:25:31 -0700
Date: Mon, 13 Mar 89 17:25:31 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140025.AA02634@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue WITH-COMPILATION-UNIT, version 3
Forum: Compiler
Issue: WITH-COMPILATION-UNIT
References: COMPILE (p438), COMPILE-FILE (p439)
Category: ADDITION
Edit history: 29-Sep-88, Version 1 by Pitman
10-Mar-89, Version 2 by Pitman (merge comments)
13-Mar-89, Version 3 by Loosemore (update discussion)
Status: Ready for release
Problem Description:
Some actions done by the compiler (and particularly the file compiler)
are typically deferred until the "very end" of compilation. For example,
some compilers complain about "functions seen but not defined".
Unfortunately, since COMPILE-FILE is the largest unit of granularity,
and since systems often extend over more than one file, it often happens
that the compiler needlessly complains at the end of compiling one file
about the absence of functions defined in the next file.
Proposal (WITH-COMPILATION-UNIT:NEW-MACRO):
Add the following new macro:
WITH-COMPILATION-UNIT options &BODY forms [Macro]
Executes forms from left to right. Within the dynamic context
of this form, actions deferred by the compiler until "the end of
compilation" will be deferred until the end of the outermost call
to WITH-COMPILATION-UNIT. The result(s) are the same as that of
the last of the FORMS (or NIL if FORMS is null).
OPTIONS is a keyword/value list, where only the values are
evaluated. The set of keywords permitted may be extended by the
implementation, but the only keyword defined by this standard is:
:OVERRIDE boolean
The default is NIL. If nested dynamically only the outer call
to WITH-COMPILATION-UNIT has any effect unless BOOLEAN is T,
in which case warnings are deferred only to the end of the
innermost call.
It follows that the functions COMPILE and COMPILE-FILE should
provide the effect of (WITH-COMPILATION-UNIT (:OVERRIDE NIL) ...)
around their code.
Any implementation-dependent extensions may only be provided
as the result of an explicit programmer request by use of
an implementation-dependent keyword. Implementations are forbidden
from attaching additional meaning to a conforming use of this
macro.
Note also that not all warnings are deferred. In some implementations,
it may be that none are deferred. This proposal only creates an
interface to the capability where it exists, it does not require the
creation of the capability. An implementation which does not do
deferred warnings may correctly implement this as expanding into PROGN.
Test Case:
(DEFUN COMPILE-FILES (&REST FILES)
(WITH-COMPILATION-UNIT ()
(MAPCAR #'(LAMBDA (FILE) (COMPILE-FILE FILE)) FILES)))
(COMPILE-FILES "A" "B" "C")
processes deferred warnings only after compiling all of A, B, and C.
Rationale:
This will make the development of portable system-construction tools
considerably more convenient.
Current Practice:
Lucid has a very similar facility, called WITH-DEFERRED-WARNINGS.
TI Explorer and Symbolics Genera have a similar facility, which they
call COMPILER-WARNING-CONTEXT-BIND.
Cost to Implementors:
In implementations which have no deferred warnings, there is no cost.
In implementations which have deferred warnings, the cost is probably
fairly small -- usually just a matter of writing interfacing the
proposed macro to an existing one.
Cost to Users:
None. This is a compatible addition.
Cost of Non-Adoption:
Portable system-construction tools would continue to print lots of
spurious warnings because they would have no way to tell the system
that a set of files was working together.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
The ability to create a compilation unit other than a file is important.
Discussion:
Pitman and Benson support this addition.
One could imagine adding more options at a later date.
It was the opinion of the compiler committee that there was room for
expansion here to address issues like bounding the scope of global
proclamations, sharing compile-time environments across files, etc.
However, insufficient work was done on this to justify putting such
a thing into the standard. The only clear need we have at this time
was to defer warnings, but we chose a general name like
WITH-COMPILATION-UNIT rather than a specific name like Lucid's
WITH-DEFERRED-WARNINGS in order to encourage implementations to
experiment with other kinds of options under implementation-specific
keywords. Perhaps by the time of the next standard there will be
sufficient understanding of this area to warrant further elaboration
of this primitive.
Kim Barrett says:
I strongly oppose the behavior you proposed for compile and
compile-file. It is my belief that whether to override or not must be
controlled through an argument to the compile functions, with the
default being to override. Otherwise, all existing code which makes
use of the compile functions must be modified to protect itself by
wrapping a (with-compilation-unit (:override t) ...) around the calls
to the compiler.
Consider a stream system built on an object system which will compose
and compile functions on the fly on an as needed basis. It would be
very strange for the functions so generated while doing file io for
the user's compile-file to have any relationship with said
compile-file.
I agree with your position that implementation-dependent extensions
must be explicitly requested.
∂13-Mar-89 1622 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:22:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11265; Mon, 13 Mar 89 17:19:53 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02631; Mon, 13 Mar 89 17:19:48 -0700
Date: Mon, 13 Mar 89 17:19:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140019.AA02631@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
This issue is also still under discussion. This version of the writeup
is fairly new and hasn't been reviewed thoroughly yet.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
Issue MACRO-FUNCTION-ENVIRONMENT,
Issue GET-SETF-METHOD-ENVIRONMENT,
Issue COMPILE-FILE-ENVIRONMENT
Related Issues: Issue FUNCTION-NAME,
Issue PROCLAIM-LEXICAL
Issue MACRO-ENVIRONMENT-EXTENT
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Status: **DRAFT**
Problem description:
When macro forms are expanded, the expansion function is called with
two arguments: the form to be expanded, and the environment in which
the form was found. The environment argument is of limited utility.
The only use sanctioned currently is as an argument to MACROEXPAND or
MACROEXPAND-1 or passed directly as an argument to another macro
expansion function. Recent cleanup issues propose to allow it as an
argument to MACRO-FUNCTION and to GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle
local macro and function definitions, due to insufficient access to
the information contained in environments and the inability to
augment environments with local definitions.
Some people believe that the CLOS meta-object protocol will require the
ability to distinguish between remote environments used for compiling
to a file, from local environments used for processing by EVAL or
COMPILE. (However, there is no requirement in chapters 1 & 2 of the
CLOS spec that things be done this way.)
There are three proposals; SMALL, MEDIUM, and LARGE.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic
environment objects. In all of these functions the argument named ENV
is an environment of the sort received by the &ENVIRONMENT argument to
a macro or as the environment argument for EVALHOOK. Optional "env"
arguments default to NIL, which respresents the local null lexical
environment (containing only global definitions and proclamations
that are present in the runtime environment). All of these functions
should signal an error of type TYPE-ERROR if the value of an
environment argument is not a syntactic environment.
VARIABLE-KIND variable &optional env [Function]
VARIABLE is a symbol. This function returns one of the following
symbols, depending on the type of definition or binding which is
apparent in ENV.
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result
will also refer to variables proclaimed lexical.]
Example:
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-KIND VAR ENV))
(DEFVAR A)
(DEFUN TEST ()
(LET (B)
(LET (C)
(DECLARE (SPECIAL C))
(SYMBOL-MACROLET ((D ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E))))))
(TEST) -> (:SPECIAL :LEXICAL :SPECIAL :SYMBOL-MACRO NIL)
FUNCTION-KIND function &optional env [Function]
FUNCTION is a function name. This function returns two values,
depending on the type of function definition or function binding
which is apparent for FUNCTION in ENV.
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
The second value specifies whether the definition is local or
global. If local, the second value is true, and it is false when
the definition is global.
Some function names may refer to both a global macro and a global
special form. In such a case, the macro takes precedence, and
:MACRO is returned as the first value.
[Note: The use of "function name" rather than "symbol" as the
description of the function argument is intended to be compatible
with the various proposals to extend the syntax of function
specifiers. If no such change actually occurs then this would only
refer to symbols.]
Example:
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
`',(FUNCTION-KIND FUNCTION-NAME ENV))
(DEFUN A ())
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(MULTIPLE-VALUE-CALL #'LIST
(KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> (:FUNCTION NIL
:MACRO NIL
:SPECIAL-FORM NIL
:FUNCTION T
:MACRO T
NIL NIL)
VARIABLE-TYPE variable &optional env [Function]
VARIABLE is a symbol. This function returns the type specifier
associated with the variable named by the symbol in the environment.
If no explicit association exists, either by PROCLAIM or DECLARE,
then the result is the type specifier T.
The result of this function may not include all the apparent TYPE
declarations for VARIABLE. In particular, an implementation is free
to ignore TYPE declarations, only returning TYPE information which
was added to ENV by a call to AUGMENT-ENVIRONMENT.
Example:
This example assumes that the implementation records type
information in the environment, rather than ignoring it.
(DEFMACRO VARTYPE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-TYPE VAR ENV))
(DEFVAR A 1)
(PROCLAIM '(FIXNUM A))
(DEFUN TEST ()
(LET ((B (AREF "X" 0))
(C 3))
(DECLARE (STRING-CHAR B))
(LIST (VARTYPE A) (VARTYPE B) (VARTYPE C))))
(TEST) -> (FIXNUM STRING-CHAR NIL)
FUNCTION-FTYPE function &optional env [Function]
FUNCTION is a function name. This function returns the functional
type specifier associated with the function in the environment, or
the symbol FUNCTION if there is no functional type declaration or
proclamation associated with the function.
The result of this function may not include all the apparent FTYPE
declarations for FUNCTION. In particular, an implementation is free
to ignore FTYPE declarations, only returning FTYPE information which
was added to ENV by a call to AUGMENT-ENVIRONMENT.
Example:
This example assumes that the implementation records ftype
information in the environment, rather than ignoring it.
(DEFMACRO FUNTYPE (FUN &ENVIRONMENT ENV)
`',(FUNCTION-FTYPE FUN ENV))
(DEFUN A-FUNCTION (X)
(+ X 3))
(PROCLAIM '(FTYPE (FUNCTION (FIXNUM) FIXNUM) A-FUNCTION))
(DEFUN TEST ()
(FLET ((ANOTHER-FUNCTION (X)
(+ X 2)))
(DECLARE (FTYPE (FUNCTION (INTEGER) INTEGER) ANOTHER-FUNCTION))
(LIST (FUNTYPE A-FUNCTION) (FUNTYPE ANOTHER-FUNCTION))))
(TEST) -> ((FUNCTION (FIXNUM) FIXNUM) (FUNCTION (INTEGER) INTEGER))
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a copy of ENV, augmented with the information
provided by the keyword arguments. The arguments are supplied as
follows:
:VARIABLE A list of symbols which shall be visible as bound
variables in the new environment. Whether each
binding is to be interpreted as special or lexical
depends on SPECIAL declarations recorded in the
environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, in the same format
as the CADR of a SYMBOL-MACROLET special form. The
new environment will have local symbol-macro bindings
of each symbol to the corresponding expansion, so that
MACROEXPAND will be able to expand them properly.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, in the same format
as the CADR of a MACROLET special form. The new
environment will have local macro bindings of each
name to the corresponding expander function, which
will be returned by MACRO-FUNCTION and used by
MACROEXPAND.
:DECLARE A list of decl-specs. The new environment will
contain information about SPECIAL, TYPE, and FTYPE
declarations appearing within the list.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list.
An error is signalled if any of the names specified as keys in the
:MACRO alist are also included in the :FUNCTION list. The consequences
of destructively modifying the list structure of any of the arguments
to this function are undefined.
The extent of the returned environment is the same as the extent of
the argument.
While an environment argument from EVALHOOK may be used as the
environment argument for this function, the reverse is not true. If
an attempt is made to use the result of AUGMENT-ENVIRONMENT as
the environment argument for EVALHOOK, the consequences are undefined.
The environment returned by AUGMENT-ENVIRONMENT may only be used for
syntactic analysis, ie. the functions specified by this proposal and
functions such as MACROEXPAND.
[If PROCLAIM-LEXICAL is adopted, LEXICAL declarations would also
be recognized.]
Rationale:
This proposal defines a minimal set of accessors and a constructor
for environments.
The symbol-macro and macrolet definitions and declarations passed
to AUGMENT-ENVIRONMENT are in the same form as those which would
normally be encountered by a code-walker. This makes it easier to
use. In particular, there is no need for users to write their own
code to destructure macro arguments.
Making TYPE and FTYPE information optional continues to allow
implementations the freedom to simply ignore all such declarations.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM):
This is the same as proposal SMALL, but also includes:
There are two kinds of environments, local and remote. Local
environments are created by EVAL and COMPILE, and are used in
situations where the information in the environment pertains
to the immediate running Lisp environment. Remote environments
are used by processors such as COMPILE-FILE to model what the
Lisp environment will look like when the code being processed
is actually loaded.
If AUGMENT-ENVIRONMENT receives a remote environment as an argument,
then the new environment returned by this function will also be
remote, and the two will refer to the same model of the remote
environment.
ENVIRONMENT-REMOTE-P env [Function]
Returns true if ENV is a remote environment, false otherwise.
WITH-REMOTE-ENVIRONMENT var &body body [Macro]
Evaluates the BODY forms with VAR bound to a newly created remote
environment. The extent of the environment is the dynamic extent of
the WITH-REMOTE-ENVIRONMENT form.
This is the only specified mechanism by which a new remote
environment may be created.
Rationale:
The notion of local and remote environments may be useful for
developing the CLOS meta-object protocol. At some future time,
we may wish to tighten the specification of how compile-time
definitions of defining macros such as DEFMACRO or DEFCLASS are
achieved, by saying that the compile-time definitions must be made
only in the remote environment.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:LARGE):
This is the same as proposal MEDIUM, but also includes:
ENVIRONMENT-PROPERTY env name property &optional default
This function and its SETF method allow the association of arbitrary
'global' properties with names within an environment. An
environment can be thought of as having a local property list
associated with any name, and this function provides access to that
property list.
A remote environment may be thought of as an extension of the local
environment. Thus, when this function is applied to a remote
environment and the property is not found, the global local environment
is then searched.
The association between names and property lists uses EQUAL to match
names. The search of the property list uses EQ to match properties.
If the property is not found, DEFAULT is returned.
Using SETF of ENVIRONMENT-PROPERTY affects all environments which
refer to the same environment model. In particular, if ENV is a
local environment then all local environments are affected, while if
ENV is a remote environment, then all environments refering to the
same remote environment model as the argument are affected.
[Note: The local property list of a name is not necessarily the
symbol-plist of the name, though that is a possible implementation
for names which are symbols.
Note: The use of EQUAL as the matching function for names is to
allow for proposed extensions to function names. If no such
extension occurs, then EQ could be used instead.]
Rationale:
This would provide a mechanism for making and accessing global
definitions in the remote environment.
Cost to Implementors:
Most implementations already record some of this information in some
form. Providing these functions should not be too difficult, but it
is a more than trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable
Common Loops defines a subset of this functionality for its code
walker and implements it on a number of diffent versions of Common
Lisp. IIM uses the functionality provided by ENVIRONMENT-REMOTE-P
and ENVIRONMENT-PROPERTY (under other names) to implement the
association between names and remote metaobjects (macro and type
definitions, CLOS remote metaobjects, &etc).
Discussion:
The first version of this proposal expressly did not deal with the
objects which are used as environments by EVALHOOK. This version is
extended to support them in the belief that such environments share a
lot of functionality with the syntactic environments needed by a
compiler. While the two types of environments may have very
different implementations, there are many operations which are
reasonable to perform on either type, including all of the accessor
functions described by this proposal.
AUGMENT-ENVIRONMENT currently requires signaling an error when
symbol-macro names match variable names in the same call. This could
be reduced to "should signal". By requiring the error signaling, this
proposal is compatable with Proposal SYMBOL-MACROLET-DECLARE:ALLOW,
which says
"... signals an error if a SPECIAL declaration names one of the symbols
being defined as a symbol-macrolet."
Maintaining compatability with the SYMBOL-MACROLET-DECLARE proposal
allows fairly trivial implementations of the SYMBOL-MACROLET
special-form in terms of the AUGMENT-ENVIRONMENT function.
An possible alternative syntax for WITH-REMOTE-ENVIRONMENT might be
WITH-REMOTE-ENVIRONMENT (var &key) &body body
Can anyone suggest candidates for keyword options? We could do this
even if we can't think of any immediately, leaving room for
implementation-specific extensions. One candidate option that some
implementations might want would be to specify a target machine for
the compilation.
Kim Barrett originally suggested that WITH-COMPILATION-UNIT should
provide the mechanism for creating new remote environments. However,
it has been suggested that WITH-COMPILATION-UNIT is intended to serve
a somewhat different purpose.
Sandra Loosemore says:
I support proposal SMALL but would vote against both of the larger
proposals. It's true that they provide functionality which *might* be
useful to implement CLOS, but there is nothing now in the standard
that *requires* this functionality to be added. In fact, the version
of issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS that was accepted at
the January meeting explicitly leaves unspecified the mechanism by
which defining macros make definitions available to the compiler. We
have very little practical experience with using environment objects
for this purpose and I think it would be premature to try to
standardize it at this point. In particular, since the meta-object
protocol is still undergoing what appear to be substantial changes,
let's wait until it settles down and then see what kind of compiler
hooks it needs, instead of possibly standardizing the wrong thing.
∂13-Mar-89 1643 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:43:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 19:39:46 EST
Date: Mon, 13 Mar 89 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-Id: <19890314004109.1.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
Modulo some bugs in the code. Shouldn't the second-to-last line be:
(MAPCAR #'(LAMBDA (BINDING)
(eval (CaDR BINDING)))
BINDINGS)
(my additions are in lowercase)?
barmar
∂13-Mar-89 1634 X3J13-mailer summary of active cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:34:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11546; Mon, 13 Mar 89 17:32:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02645; Mon, 13 Mar 89 17:32:27 -0700
Date: Mon, 13 Mar 89 17:32:27 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140032.AA02645@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: summary of active cl-compiler issues
Here is a list of all the active cl-compiler issues. Writeups for
all of these were mailed out earlier today.
CLOS-MACRO-COMPILATION (**DRAFT** version 2)
Clarify compile-time behavior of CLOS defining macros.
Proposal MINIMAL
Proposal NOT-SO-MINIMAL
(Still under active discussion.)
COMPILE-ENVIRONMENT-CONSISTENCY (version 4)
What kinds of things can/must the compiler "wire in" to the code
it compiles?
Proposal CLARIFY
COMPILE-FILE-SYMBOL-HANDLING (version 2)
How does COMPILE-FILE tell LOAD what package to put symbols in?
Proposal CURRENT-PACKAGE
Proposal HOME-PACKAGE
Proposal REQUIRE-CONSISTENCY
COMPILED-FUNCTION-REQUIREMENTS (version 4)
What does the COMPILED-FUNCTION type imply? Do COMPILE and
COMPILE-FILE construct COMPILED-FUNCTIONs?
Proposal TIGHTEN
Proposal TIGHTEN-COMPILE
COMPILER-DIAGNOSTICS (version 9)
Clarify status and handling of errors and warnings signalled during
compilation.
Proposal USE-HANDLER
COMPILER-LET-CONFUSION (version 7)
The description of COMPILER-LET in CLtL is broken -- should we fix
it or eliminate it entirely?
Proposal REPAIR
Proposal ELIMINATE
COMPILER-VERBOSITY (version 6)
Mechanisms for controlling progress messages issued by the compiler.
Proposal LIKE-LOAD
CONSTANT-CIRCULAR-COMPILATION (version 7)
Must circular or recursive objects be compiled correctly? Must the
compiler preserve sharing of substructures?
Proposal NO
Proposal PRESERVE-SHARING-ONLY
Proposal YES
(Expect amendment to change error terminology.)
CONSTANT-COLLAPSING (version 5)
Should the compiler be allowed to "collapse" or coalesce constants
that satisfy a more general equivalence relationship than EQUAL?
Proposal GENERALIZE
CONSTANT-COMPILABLE-TYPES (version 8)
What types of objects can appear as quoted or self-evaluating constants
in compiled code?
Proposal SPECIFY
(Expect amendments to change requirements for functions.)
DEFCONSTANT-NOT-WIRED (**DRAFT** version 6)
How do you delcare a variable to be constant without giving the
compiler permission to make assumptions about its value?
(None of the proposals are ready to be voted on. This issue
is being distributed only for informational purposes.)
DEFINE-OPTIMIZER (version 5)
Provide a macro-like way of specifying source-level optimizations
on function calls.
Proposal NEW-FACILITY
DEFINING-MACROS-NON-TOP-LEVEL (version 8)
Are defining macros such as DEFUN meaningful in non-top-level locations?
Proposal ALLOW
EVAL-WHEN-NON-TOP-LEVEL (version 6)
What does EVAL-WHEN mean when it appears in non-top-level locations?
Proposal GENERALIZE-EVAL
Proposal GENERALIZE-EVAL-NEW-KEYWORDS
LOAD-TIME-EVAL (version 11)
Add a new special form, LOAD-TIME-VALUE.
Proposal R**2-NEW-SPECIAL-FORM
Proposal R**3-NEW-SPECIAL-FORM
(Proposal R**2-NEW-SPECIAL-FORM was approved at the January meeting,
but some additional suggestions were made after the meeting.)
MACRO-CACHING (version 2)
Is it legitimate to cache macro expansions?
Proposal DISALLOW
Proposal RESTRICT
MACRO-ENVIRONMENT-EXTENT (**DRAFT** version 3)
Do environment objects received as the &ENVIRONMENT argument to a
macro have dynamic or indefinite extent?
Proposal INDEFINITE
Proposal DYNAMIC
Proposal DYNAMIC-WITH-COPIER
(Still under active discussion.)
PROCLAIM-ETC-IN-COMPILE-FILE (**DRAFT** version 4)
Are top-level calls to PROCLAIM handled specially by the compiler?
Proposal YES
Proposal NO
Proposal NEW-MACRO
(New rewrite.)
QUOTE-SEMANTICS (version 2) (replaces QUOTE-MAY-COPY)
May COMPILE and EVAL construct equivalent copies of quoted or
self-evaluating constants, or must constants share structure with
the source code for the program? Do the constraints on what objects
are valid constants also apply to COMPILE and EVAL, or only to
COMPILE-FILE?
Proposal NO-COPYING
Proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS
Proposal SAME-AS-COMPILE-FILE
SAFE-CODE (version 1)
What does the "safe code" mean?
Proposal SAFETY-3
SYNTACTIC-ENVIRONMENT-ACCESS (**DRAFT** version 4)
Provide accessors and constructors for lexical environment objects.
Proposal SMALL
Proposal MEDIUM
Proposal LARGE
(New rewrite.)
WITH-COMPILATION-UNIT (version 3)
Provide a way to compile a group of files as a unit for the purposes
of error messages.
Proposal NEW-MACRO
∂14-Mar-89 0938 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:37:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556615; Tue 14-Mar-89 12:35:04 EST
Date: Tue, 14 Mar 89 12:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-ID: <19890314173505.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally favor the COMPILER-LET-CONFUSION:REPAIR proposal, however
I have a couple of comments and questions. Also of course I would want
to see the typo that BarMar found fixed.
What is the interaction between proposals COMPILER-LET-CONFUSION
and DEFINE-OPTIMIZER? Neither proposal says anything about that
as far as I can see. I believe the body of a optimizer must be
executed in the same dynamic environment as the body of a macro.
Cost to Implementors:
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body.
This is not true. A possible implementation technique for such
interpreters, in fact the one I would use, is to save the COMPILER-LET
bindings in a slot in the interpreter's lexical environment in the form
of an alist, and to make the MACROEXPAND-1 function bind those bindings
with PROGV around its call to the macroexpander. Using this technique
instead of fully macroexpanding the body deals with some of the
objections to the REPAIR proposal, I believe. Also promoting this
technique in the proposal would remove the need for the discussion
section to address the side-issue of whether code analyzing programs can
or cannot be written portably (an important issue in its own right, but
not part this one).
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations (the ones from which COMPILER-LET originally came)
continue to use their pre-CLtL semantics. These semantics are useful, though
incompatible with CLtL (which they largely consider to simply be in error).
Could you be more explicit about this? I was unable to figure out what you
are talking about, even after twice reading the introductory portion of the
proposal and the writeup in CLtL. I believe Symbolics Genera is one of those
implementations from which COMPILER-LET originally came and at the same time
implements COMPILER-LET exactly as CLtL specifies, so I must be missing some
important distinction. I'd like to see a precise description of these two
competing semantics and I'd also like to know which, if either, of them is
compatible with the REPAIR proposal.
∂14-Mar-89 0956 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:56:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556621; Tue 14-Mar-89 12:54:02 EST
Date: Tue, 14 Mar 89 12:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132331.AA02562@defun.utah.edu>
Message-ID: <19890314175403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally like DEFINE-OPTIMIZER:NEW-FACILITY, but I would like
to suggest a couple of changes.
I'm not a fan of documentation strings, but shouldn't DEFINE-OPTIMIZER
allow them? Was their omission accidental or intentional?
Instead of returning two values from the body, I suggest returning one
value, or NIL to decline to optimize. If an optimizer wishes to
optimize into a form whose result is NIL, it should return (QUOTE NIL).
After all, if it wishes to optimize into a form whose result is FOO, it
has to return (QUOTE FOO), not FOO. The two values returned by
OPTIMIZE-EXPRESSION-1 are okay, since they are compatible with the two
values returned by MACROEXPAND-1. A reasonable alternative would be to
eliminate the two values at all levels, and also eliminate the special
casing of NIL, and simply specify that one declines to optimize by
returning the original form (compared with EQ). This will work but is
slightly more awkward for the optimizer writer, since &WHOLE would
have to be used. I'd accept this alternative if more people are in
favor of it, but I prefer special-casing NIL. I'd greatly prefer either
of those alternatives over what the proposal says now.
It isn't made clear whether OPTIMIZE-EXPRESSION returns one value
or two. It should be consistent with OPTIMIZE-EXPRESSION-1.
Using FLET and MACROLET shadow...
I assume it was only accidental that LABELS, GENERIC-LABELS, and
GENERIC-FLET were omitted from this list. I am unable to figure
out whether WITH-ADDED-METHODS should be included in this list
or not; I suspect not.
The similar Symbolics Genera facility allows more than one optimizer
to be defined for a given function; the optimizers are invoked in
unspecified order until one succeeds. This feature is actually
used, however I think it is okay to leave it out.
I agree with Barrett's comments quoted in the discussion section.
I'd like to see the proposal amended the way he suggests.
∂14-Mar-89 1005 CL-Compiler-mailer issue WITH-COMPILATION-UNIT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 10:05:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556623; Tue 14-Mar-89 13:03:02 EST
Date: Tue, 14 Mar 89 13:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue WITH-COMPILATION-UNIT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140025.AA02634@defun.utah.edu>
Message-ID: <19890314180303.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose this because I don't think it's finished, however I expect I
would support it if it were finished. It may be that the amount of work
required to finish this is small and the proposal just needs amending.
I don't think it's acceptable to have something like this if its effect
is only defined for warnings, and its effect on compile-time
proclamations, compile-time macro definitions, compile-time defconstant
definitions, compile-time optimizer definitions, compile-time type
definitions, compile-time setf definitions, and compile-time CLOS
definitions is left unspecified.
I think lumping COMPILE and COMPILE-FILE together here reflects
confusion. COMPILE and COMPILE-FILE have very little to do with each
other, and I think it's clear that COMPILE should not be affected in any
way by WITH-COMPILATION-UNIT. Having COMPILE affected by
WITH-COMPILATION-UNIT is as unreasonable as having MACROEXPAND affected
by WITH-COMPILATION-UNIT, if you ask me. I think removing COMPILE would
address Barrett's complaint in the discussion section; that is, I think
having COMPILE-FILE not override an enclosing WITH-COMPILATION-UNIT is
correct.
∂14-Mar-89 1217 CL-Compiler-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:17:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556715; Tue 14-Mar-89 15:09:52 EST
Date: Tue, 14 Mar 89 15:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132355.AA02585@defun.utah.edu>
Message-ID: <19890314200952.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I strongly favor MACRO-ENVIRONMENT-EXTENT:DYNAMIC over any of the other four.
∂14-Mar-89 1232 CL-Compiler-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:32:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556743; Tue 14-Mar-89 15:29:24 EST
Date: Tue, 14 Mar 89 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140008.AA02608@defun.utah.edu>
Message-ID: <19890314202917.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO, primarily because this
allows programs to be clear about the scope of the proclamation:
whether they are making a proclamation for purposes of compile-file or
to affect the running Lisp. If you call the macro at top-level, you're
clearly doing it for compilation. If you call the function at any level,
you're clearly doing it with global scope.
In PROCLAIM-ETC-IN-COMPILE-FILE:NO there is no way to say whether a
PROCLAIM inside an (EVAL-WHEN (COMPILE...) ...) is intended to persist
after the compilation is over, which is just about the only reason
why I prefer PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO over :NO.
I'd like PROCLAIM-ETC-IN-COMPILE-FILE:NO better if it also proposed
to add an optional argument to PROCLAIM that expressed the intended
scope of the proclamation. I'd suggest NIL (the default) for the
global scope and the symbol COMPILE-FILE to limit it to the compilation.
Given this, users who liked DEFPROCLAIM could trivially write it
themselves.
The only thing PROCLAIM-ETC-IN-COMPILE-FILE:YES has going for it is
that it's the status quo, in a subset of implementations. I don't like it.
I agree with Barrett's comments quoted in the discussion section.
The proposal says:
As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DEFPROCLAIM persist after the file has been compiled.
but never says this about PROCLAIM. In all three proposals,
this needs to be said about PROCLAIM. But as you can see from my
comments above, I would rather that we did not leave this unspecified.
The proposal says:
Current Practice:
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
I'm not sure what you thought was not clear. Symbolics Genera does the
same thing that the current practice section says IIM does. In addition
(and I couldn't tell whether IIM does this too or not), the scope of the
PROCLAIM is only the compilation-unit if the PROCLAIM appears at
top-level, but is global and persists forever if the PROCLAIM appears in
an (EVAL-WHEN (COMPILE...) ...). We might change that.
∂14-Mar-89 1310 CL-Compiler-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:09:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556774; Tue 14-Mar-89 15:58:28 EST
Date: Tue, 14 Mar 89 15:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132333.AA02565@defun.utah.edu>
Message-ID: <19890314205826.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor DEFINING-MACROS-NON-TOP-LEVEL:ALLOW except for one thing.
This sentence appears in the proposal but does not appear to have
any relation to the main issue:
The order in which
non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
I can't figure out what this means and the example in the rationale
section that purports to explain this does not shed any light, since in
the example there is no change of order of evaluation. I wouldn't be
surprised if I opposed this if I did understand what it means. Can we
deal with this as a separate issue? In fact the whole point (3) of the
proposal should be moved. That issue should also discuss whether there
are any constraints on whether one top-level form is processed before
the next top-level form is read, in case the one form changes package,
changes readtable, defines a read-syntax, or defines a structure used in
#S read-syntax.
Also, when you say:
Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
I strongly believe that MACROLET must be consistent with this, which
would be a change. Has that been dealt with as a separate issue? If
not, it should either be added to this issue or brought up as a
separate issue, with the interdependency noted in both writeups to
minimize the chance of an inconsistent vote.
∂14-Mar-89 1326 CL-Compiler-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:25:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556792; Tue 14-Mar-89 16:23:12 EST
Date: Tue, 14 Mar 89 16:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132312.AA02542@defun.utah.edu>
Message-ID: <19890314212313.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE.
COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE seems superficially simpler,
but my experience when we tried it at MIT indicates that it does not
work very well. Too often a symbol that had been moved from one package
to another, or had its export status changed, would be silently moved
back to its original package by loading a file. I sort-of agree with
JonL's comment at the end of the discussion section: if we can't agree
on one solution to his issue, I think that in practice there would be
little harm to portable programs if we left it unspecified. The issue
really affects development environments much more than it affects the
language in which portable programs are written, although it does have
some effect on that as well.
∂14-Mar-89 1340 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:40:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556802; 14 Mar 89 16:37:50 EST
Date: Tue, 14 Mar 89 16:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132250.AA02499@defun.utah.edu>
Message-ID: <19890314213750.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
All the things I didn't like in version 3 have been fixed.
I would favor COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY if one change
were made. The proposal says:
Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code.
This means that either the compiletime or the runtime definition
will prevail, but nothing else can happen. It must also be
permissible to signal an error complaining about the discrepancy.
∂14-Mar-89 1351 CL-Compiler-mailer issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:51:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556829; Tue 14-Mar-89 16:49:05 EST
Date: Tue, 14 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SAFE-CODE, version 1
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131726.AA02193@defun.utah.edu>
Message-ID: <19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with SAFE-CODE:SAFETY-3.
I disagree with the usage (in the examples) of "unsafe code" to mean
"all code where the OPTIMIZE quality of SAFETY is not 3." I believe
that "unsafe code" should mean code that is actually unsafe, not code
that an implementation is permitted to treat as unsafe if it wishes. I
believe there should be no portable way to write unsafe code. This is
only a matter of wording. If we need a shorter term for "all code where
the OPTIMIZE quality of SAFETY is not 3" I would suggest "potentially
unsafe code."
∂14-Mar-89 1357 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:56:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556842; Tue 14-Mar-89 16:54:22 EST
Date: Tue, 14 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-ID: <19890314215423.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like COMPILER-VERBOSITY:LIKE-LOAD. This fixes all of the
problems I had with the version 5 proposal.
Like BarMar, I question the need for either of :PRINT and :VERBOSE in
either of LOAD and COMPILE-FILE. But that might be my own cultural
bias, due to the type of systems I use, where it's easy to see what's
going on inside. If other people claim they need these, I'll believe
them.
∂14-Mar-89 1419 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:19:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:03:50 PST
Date: 14 Mar 89 14:02 PST
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890314-140350-1917@Xerox>
Cleanup issues for the next meeting will be tricking out over the next
week.
This issue was distributed prior to the October 1988 meeting,
but not voted on.
!
Issue: ERROR-NOT-HANDLED
References: Interactive Condition Handling (Condition System, Rev 18, p19)
Category: CLARIFICATION/CHANGE
Edit history: 25-Sep-88, Version 1 by Pitman
Problem Description:
For delivery purposes, some implementations will want to leave out
major sections of runtime support in programs that do not require
them. The debugger is one such section.
However, since ERROR may be called implicitly by a number of Common
Lisp built-in functions, and since the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled, the interactive debugger must be retained in
a saved image of any program that might signal an error unless the
compiler can prove that the error will never go unhandled. This
may be undesirable in some cases and may cause unnecessary bloating
of the saved image.
Proposal (ERROR-NOT-HANDLED:PERMIT-TERMINATION):
Permit implementors to designate an implementation-specific mechanism
for asking that unhandled errors cause `termination of the running
program' rather than entry into the system's debugger.
Implementations choosing to offer such a facility must clearly define
the nature and scope of such program termination, since the concept
of `program termination' is an ill-defined concept in present-day
Common Lisp.
Even when program termination rather than debugger entry would be
the ultimate effect of an unhandled error, the value of
*DEBUGGER-HOOK* (if non-NIL) must be called to provide programmers
the ability of customized debugging.
All implementations must at least provide the option of a system
debugger for use in program development.
Test Case:
(ERROR "Foo"), if unhandled, must now enter the debugger.
Under this proposal, it might also `terminate program execution'
in implementations which choose to provide such a facility and to
clearly define that concept.
Rationale:
Although technically an incompatible change, we're dealing at
the very edge of what the user can expect from the system. Once
an error is signalled and not handled, we're in the domain of
implementation-dependent effect anyway.
Current Practice:
Probably no one does this yet.
Cost to Implementors:
None. This change is upward compatible with existing implementations.
Cost to Users:
None.
Cost of Non-Adoption:
Saved Lisp images might be forced to be gratuitously larger than
they need to be in some implementations.
Benefits:
Addressing this issue will make Lisp more able to compete with
other languages which permit small saved images to result from
small user programs.
Aesthetics:
No significant impact.
Discussion:
This change was requested by Christian Queinnec of France
(queinnec@inria.inria.fr). Pitman supports the change.
∂14-Mar-89 1438 CL-Compiler-mailer issue COMPILER-DIAGNOSTICS, version 9
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:38:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556909; Tue 14-Mar-89 17:35:56 EST
Date: Tue, 14 Mar 89 17:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-DIAGNOSTICS, version 9
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131545.AA02075@defun.utah.edu>
Message-ID: <19890314223550.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILER-DIAGNOSTICS:USE-HANDLER, but there are two
things that I think need to be changed:
Conditions of type WARNING may be signalled by the compiler in
situations where ... the compiler can determine
that a situation that "is an error" would result at runtime.
We don't use the term "is an error" any more, do we? In the old
CLtL terms, I think both "is an error" and "signals an error"
situations would justify a warning. I think this part should
be updated to the new error terminology and also should state that
all error situations justify warnings. Of course explicit calls
to the function ERROR don't justify warnings; I don't know whether
the proposal can be phrased in such a way as to make that clear,
or whether it will have to be left to common sense.
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation.
I think this is wrong. The only documentation of the ABORT restart
that I could find says
The purpose of the ABORT restart is generally to allow return to the
innermost ``command level.''
I agree with this, and I believe it means that it is wrong for any
function other than one that establishes a read-eval-print loop or
a command-level to establish an ABORT restart. It would be useful
to have some restart that aborts a portion of the compilation, but
it should be given some other name.
∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:04:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556941; Tue 14-Mar-89 18:02:30 EST
Date: Tue, 14 Mar 89 18:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890314-140350-1917@Xerox>
Message-ID: <19890314230224.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
ERROR-NOT-HANDLED:PERMIT-TERMINATION is okay with me. I would
also support a proposal to replace "the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled" with wording that allowed implementations
to do whatever they want, with perhaps an implementation note that
many implementations prefer an interactive debugger.
∂14-Mar-89 1544 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:44:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 438041; Tue 14-Mar-89 18:42:58 EST
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140019.AA02631@defun.utah.edu>
Message-ID: <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks good so far. A few comments that might help you
along with the draft:
VARIABLE-KIND should return the same second value that FUNCTION-KIND
returns.
It's a good idea to avoid the ambiguous word "may" and say "might",
"must", or "is permitted to".
I would assume that VARIABLE-TYPE is not required to return the
exact declared type specifier, but could return another type
specifier that is equivalent, or possibly another type specifier
that is a supertype. An implementation that canonicalizes type
declarations would do this. For example, if A was declared
(INTEGER 0 4999), VARIABLE-TYPE might return that list, another
list that was EQUAL to it but not EQ, the list (INTEGER (-1) (5000)),
the symbol FIXNUM, or perhaps something else. Similarly OR's and
AND's might be reduced to simpler type specifiers in an implementation
dependent way. If, on the other hand, VARIABLE-TYPE is not permitted
to do this, but must return the exact type specifier used in the
declaration, that would be okay, but should be stated explicitly.
Similar comments apply to FUNCTION-FTYPE of course.
I assume AUGMENT-ENVIRONMENT is permitted to share structure with
its env argument, although the proposal says "a copy of ENV".
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function). That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET. Your rationale argues against this but I strongly believe
that the rationale is wrong. I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.
No way is provided to retrieve declarations other than SPECIAL, TYPE,
FTYPE, and LEXICAL (if PROCLAIM-LEXICAL passes). I think all
declarations should be retrievable, but OPTIMIZE declarations seem
particularly useful to retrieve in macros or optimizers that expand into
different code depending on the safety level or the speed/space
tradeoff. The irregular structure of declarations makes retrieving
them a bit complex, but here's my suggestion:
DECLARATION decl-type name &optional env [Function]
decl-type is a symbol. The interpretation of name depends
on decl-type. If a declaration of that type and name is
in force in the specified environment, it is returned, otherwise
NIL is returned. The following decl-types are specified,
additional implementation-dependent types could be added:
INLINE function-name => T or NIL
NOTINLINE function-name => T or NIL
IGNORE variable-name => T or NIL
OPTIMIZE quality => integer
DECLARATION decl-type => T or NIL
The possible interpreter implementation of COMPILER-LET I mentioned
in another message earlier today would seem to require another
keyword argument to AUGMENT-ENVIRONMENT. Does this mean that we
have to dictate some particular interpreter implementation of
COMPILER-LET? I'm unsure.
Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms. Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT? I'm unsure.
On SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM, my feeling today is that
this should be left out for now, even though I think we will want
something like it later, at the same time that CLOS metaobjects
go in.
Ditto for SYNTACTIC-ENVIRONMENT-ACCESS:LARGE.
∂14-Mar-89 1555 X3J13-mailer LETTER BALLOT -- Sun Microsystems
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:55:09 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA21551; Tue, 14 Mar 89 15:16:32 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA11449; Tue, 14 Mar 89 15:12:40 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26931; Tue, 14 Mar 89 15:16:13 PST
Date: Tue, 14 Mar 89 15:16:13 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903142316.AA26931@clam.sun.com>
To: chapman%aitg.DEC@decwrl.dec.com
Subject: LETTER BALLOT -- Sun Microsystems
Cc: kempf%clam@Sun.COM, peck%clam@Sun.COM, sgadol%clam@Sun.COM,
x3j13@sail.stanford.edu
This is the Sun Microsystems vote.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | | I | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | | A |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
Overall, I'm impressed with the work that has been done on
writing the standard, but not entirely comfortable with the process
I can see for getting from where we are to an actual standard.
CUT-OFF-DATES
I have both general and specific comments about the CUT-OFF-DATES
proposal. The general comments first:
The cutoff dates question causes me some discomfort, and I think
that is because the proposal is not as explicit as it might be.
First, how about stating what the goal for 12/89 is? E.g. a
draft standard approved by X3J13 and ready for release and
outside comments.
Second, as I understand it, the "final changes" dates are for
final changes from the selected reviewers for each section of
the standard, though this is not stated.
The process, as I understand it, is that a set of reviewers will
read each section (or set of tool descriptions) carefully and
submit corrections, etc.. The full committee will then vote on
these.
A proper review will need to be done by subject rather than by sections
of the alphabet. In fact at least one person at Sun has volunteered to
work on a particular subject. Note that Moon expects Symbolics
internal reviewers to do likewise. To me that implies the catalog of
tools must be voted on by subject rather than alphabetically, so I
recommend reorganizing those cutoff dates and votes by subject.
Moon suggests that it will take "several months" for Symbolics
to review the draft standard, and that the availability of
the cleanup process will be important for fixing problems
in the statement of the draft standard. I second this.
Being active in the compiler committee, I feel confident that a
well-constructed section on compilation will *not* be ready by
4/22/89. We need to bring the compiler work to a conclusion as close
to that date as we can, though, even if all is not perfect. The full
committee needs to help make this happen. (Thanks especially to David
Moon for his recent input.)
ERROR-TERMINOLOGY
The error terminology is OK, except for "consequences
are unspecified". That concept is broken, though it
has serious defenders. For example, Dick Gabriel says,
"If we were to drop this term, then every time we are
``explicitly vague'' a valid possibility is that a fatal
error can occur. How is it any better to say that what happens
when some operation happens is ``explicitly vague''."
A typical area of "explicit vagueness" is the destructive operations
on lists. The explicit vagueness here is quite limited. For
some operations any top level cell of certain lists may or may
not be modified. Similar statements apply to other operations.
The consequences are far from being unspecified but harmless.
They are CONSTRAINED but meaningful.
In other situations we may say that order of certain actions
is unspecified or we may say that a side effect may or may not
occur. (For example, numerical operations may be performed
in any of various orders.) All of these are appropriate ways
to state a specification.
Maybe someone will make me suddenly see the light and I'll realize
how silly I've been, but so far the idea of consequences being
"unspecified but harmless" seems more like a witticism than
a useable idea.
SECTION 6.1
Under "Other Information", many of the terms are actually
type specifiers. Wouldn't it be better to say that if a name
is the same as a type specifier, that argument must satisfy
the type specifier?
arguments to the function -- unclear to me
boolean -- I presume this are to be arguments where
all non-NIL values are *treated* alike.
Note that for macros we truly specify *syntax* (at least
for some, e.g. defstruct. For most functions we actually
give a lambda list.
p6-8, item 2b, the keyword :test-not has been flushed from
the sequence functions.
∂14-Mar-89 1610 X3J13-mailer Re: Issue: UNSOLICITED-MESSAGES
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:09:57 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07509; 14 Mar 89 18:01 GMT
Date: Tue, 14 Mar 89 17:58:24 GMT
Message-Id: <8289.8903141758@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, barmar@think.com
Cc: chapman <@decwrl.dec.com:chapman@aitg.dec>, x3j13@sail.stanford.edu
> Why is this problem unique to Lisp? Is there any wording in the C
> standard that explicitly prohibits malloc() from causing output? I
> doubt it, yet I don't think they find this disturbing.
>
> Maybe it's because C people have traditionally been willing to settle
> for less. :-) Seriously, I think it's a clear hole in their standard.
> People would probably flame if things that weren't documented as doing
> I/O were to suddenly start doing it.
As far as I know, the C standard also doesn't say that assignment
doesn't print out "I'm doing an assignment" or, indeed, that y = 6
doesn't also assign 17 to xyzzy. But does it need to make explicit
prohibitions?
The C standard says "In the abstract machine, all expressions are
evaluated as specified by the semantics." Presumably there is an
implication that it doesn't do random other things.
-- Jeff
∂14-Mar-89 1629 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:29:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557038; Tue 14-Mar-89 19:27:03 EST
Date: Tue, 14 Mar 89 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Message-ID: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the output of a single COMPILE-FILE.
(3) relation of two objects in the output of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1636 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:36:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557048; Tue 14-Mar-89 19:34:07 EST
Date: Tue, 14 Mar 89 19:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Supersedes: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Fix some typos in the definitions of the three concepts that I claim
should not be smushed together. Cris Perdue pointed out these typos
earlier, but I forgot to fix them before sending the first copy of this
message.
Message-ID: <19890315003408.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the result of LOAD of the output
of a single COMPILE-FILE.
(3) relation of two objects in the result of LOAD of the output
of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1651 CL-Compiler-mailer issue QUOTE-SEMANTICS, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:51:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557056; Tue 14-Mar-89 19:48:51 EST
Date: Tue, 14 Mar 89 19:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue QUOTE-SEMANTICS, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131721.AA02184@defun.utah.edu>
Message-ID: <19890315004852.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor QUOTE-SEMANTICS:NO-COPYING for two reasons:
(1) it's clearly more aesthetic.
(2) I can't support either of the other two proposals because they use
the words "copying" and "coalescing" without defining their meaning.
My position could be changed to
QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS by adding definitions
for those two words and by a strong argument that the implementation
cost of QUOTE-SEMANTICS:NO-COPYING is too high, since I believe to some
extent JonL's argument (quoted in the discussion section) that EQL of
(some types of) constants does not matter.
I can't imagine any argument that would convince me to
support QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE. I believe Kent's
arguments against it (quoted in the discussion section).
∂14-Mar-89 1700 CL-Compiler-mailer issue MACRO-CACHING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:00:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557059; Tue 14-Mar-89 19:57:55 EST
Date: Tue, 14 Mar 89 19:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue MACRO-CACHING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131647.AA02151@defun.utah.edu>
Message-ID: <19890315005756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support MACRO-CACHING:DISALLOW. I'd like to point out that the
"correct" way to do macro caching is not mentioned anywhere in this
writeup. Perhaps that was justified because there is no portable way to
do it (an implementation can do it, but a user cannot), however I think
omitting it leaves a false impression.
The "correct" way to do macro caching is via a table inside the lexical
environment structure, which has very different properties from a table
keyed by the lexical environment structure, mentioned in the writeup.
I think a shorter writeup might be better. It could simply say that
there is no correct portable way to use *MACROEXPANSION-HOOK* to cache
macro expansions, and that there is no requirement that an implementation
call the macro expansion function more than once for a given form
and lexical environment. This prohibits the incorrect user code discussed
at some length in the existing writeup, leaves implementations license
to do macro caching correctly, and avoids a lot of unnecessary detail.
∂14-Mar-89 1704 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:04:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557069; 14 Mar 89 20:02:04 EST
Date: Tue, 14 Mar 89 20:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131631.AA02140@defun.utah.edu>
Message-ID: <19890315010205.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-COLLAPSING, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557083; Tue 14-Mar-89 20:10:42 EST
Date: Tue, 14 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COLLAPSING, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131622.AA02093@defun.utah.edu>
Message-ID: <19890315011043.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
The proposal says:
State the an implementation is permitted to coalesce constants
appearing in code to be compiled if they are equivalent under the
relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.
I can't understand what this means. The referenced proposal uses
the word "similar", not "equivalent". I'd support this alternate
wording:
Suppose that A and B are two objects used as quoted constants in the
input to COMPILE-FILE, and that A' and B' are the corresponding
objects used as constants in the result of loading the output of
that COMPILE-FILE. If A' is similar as a constant to both A and B,
then it is valid for A' and B' to be EQL even if A and B are not EQL.
This may still be too vague, since "objects in the input to
COMPILE-FILE" means not in the input text file, which doesn't contain
objects, but in the result of applying READ to the input file, and since
"corresponding objects" is not defined.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557096; Tue 14-Mar-89 20:15:39 EST
Date: Tue, 14 Mar 89 20:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131619.AA02090@defun.utah.edu>
Message-ID: <19890315011539.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor CONSTANT-CIRCULAR-COMPILATION:YES except that all references to
EQ should be changed to EQL. There is no reason to require
implementations to be careful about EQ of numbers and characters.
∂14-Mar-89 1731 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:12 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:57:16 PST
Date: 14 Mar 89 14:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
To: x3j13@SAIL.Stanford.EDU
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <890314-145716-2049@Xerox>
Additional Comments include:
"... it's ... late to consider things like this ..."
"YAY!!! This is what "cleanup" is for. Go For It! "
"Sounds like a good idea to me."
!
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):
Define that if an optional argument is given to GENSYM, it does NOT
have a side-effect on GENSYM's internal state.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Test Case:
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman supports the proposal.
----- End Forwarded Messages -----
∂14-Mar-89 1730 CL-Compiler-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:29:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557112; 14 Mar 89 20:27:21 EST
Date: Tue, 14 Mar 89 20:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131544.AA02070@defun.utah.edu>
Message-ID: <19890315012722.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I much prefer the option FLUSH, which was in version 2 but has been
removed. That option was to remove the COMPILED-FUNCTION type.
This type has no portable meaning and never should have existed.
I have no objection to the proposed specification of what the COMPILE
and COMPILE-FILE functions do, but it should be decoupled from the
COMPILED-FUNCTION type and discussed under the rubric of those two
functions. The parts about COMPILER-LET and EVAL-WHEN can probably be
removed (assuming the COMPILER-LET-CONFUSION proposal that eliminates
the possibility of COMPILER-LET binding any variables at run time
passes, and the EVAL-WHEN-NON-TOP-LEVEL proposal passes) since they are
redundant; there is never any interpeter/compiler difference for
COMPILER-LET or EVAL-WHEN any more.
∂14-Mar-89 1731 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:29:58 PST
Date: 14 Mar 89 14:24 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <890314-142958-1976@Xerox>
There are a couple of "additional comments" on the proposal
at the end.
!
Issue: COERCE-INCOMPLETE
Reference: COERCE (p50)
Category: ADDITION/CHANGE
Edit history: Version 1 of COERCE-INCOMPLETE, 26-Feb-88 by M. Ida
Version 1 of COERCE-FROM-TYPE, 20-Jun-88 by Pitman
Version 2 of COERCE-INCOMPLETE, 21-Nov-88 by Pitman
(consolidate previous two proposals)
Version 3 of COERCE-INCOMPLETE, 07-Mar-89 by Pitman
(eliminate unpopular proposal, two new options)
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, if the symbol STRING were permitted as a second argument
to coerce, as in (COERCE NIL 'STRING), there would be two posssible
return values: "" or "NIL". The choice would be arbitrary and would
have to be specified by the documentation. No matter which was chosen,
it would probably turn out to be a problem for some applications at
some times.
Another example is (COERCE (CHAR-CODE #\A) 'STRING). This might
return the same as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in
most ASCII-based implementations -- or it might return "A". Again,
the choice would be arbitrary.
There is clear desire on the part of the user community to lift some of
the existing restrictions on arguments to COERCE, but because of legitimate
concerns about ambiguities, the Common Lisp designers have thus far
refused to do so.
Unfortunately, the failure of COERCE to handle these cases means it is
very difficult to learn to use COERCE. And the fact that COERCE is not
easily learned contributes to difficulty in learning Common Lisp because
instead of a single coercion operator with general purpose semantics, a
number of very special purpose coercion operators must be learned instead.
Some middle ground needs to be found, which neither compromises the
clear semantics and portable nature of COERCE nor complicates COERCE
in a way that makes it unlearnable.
Also, some people have expressed a desire for COERCE to be more
`symmetric.' Usually they seem to mean that they want it to be the case
that if (COERCE x y) works, then (COERCE (COERCE x y) (TYPE-OF x))
should also work. Although this is not an essential desire, it would
certainly be nice to achieve.
Proposal (COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION):
Define COERCE to accept the following equivalences:
1. (COERCE x 'STRING) == (STRING x)
2. (COERCE x 'PATHNAME) == (PATHNAME x)
3. (COERCE x 'RATIONAL) == (RATIONAL x)
Clarify that
4. (COERCE x 'FLOAT) == (FLOAT x)
Rationale:
Many users think of STRING, for example, as ``the way to coerce
something to a string'' and are baffled why COERCE and STRING
disagree on how to do this.
Such users think that if there's a moral battle to be waged
over how to coerce an object to a STRING, the battle has already
been lost by defining the STRING function -- that whatever
decision is made for STRING must also apply to COERCE for the
sake of simplicity.
Similar arguments can be made for PATHNAME, FLOAT, and RATIONAL.
Proposal (COERCE-INCOMPLETE:DEPRECATE):
Deprecate COERCE.
Rationale:
COERCE is not functionally necessary -- no operation that it does
cannot be done in some other way. As such, it is basically just
a matter of syntactic convenience, and perhaps isn't worth having
around if it will be the subject of endless debate. Deprecating
it would allow us to declare this issue a `dead end' and focus our
attention on matters of greater substance.
Current Practice:
Presumably No one implements either of the proposals at this time,
since none are compatible with CLtL.
Cost to Implementors:
COERCE: Small to moderate.
DEPRECATE: None.
Cost to Users:
COERCE: This is an incompatible change. (COERCE 'NIL 'STRING) => ""
but (STRING NIL) => "NIL". How many applications are impacted by
this change is not clear. It would be straightforward to shadow
COERCE with an alternate definition that did the old thing in
cases where people were worried. Once such cases have been
identified, rewriting
(COERCE X 'STRING)
as
(IF X (COERCE X 'STRING) "")
will suffice in most cases.
DEPRECATE: No immediate work would be needed, although many maintained
applications would get upgraded in order to use the primitives that
are `in vogue.'
Cost of Non-Adoption:
People will continue to see and debate the issues alluded to in
the Problem Description.
Benefits:
The cost of Non-Adoption will be avoided.
Aesthetics:
COERCE: Many people will probably see the idea of making
COERCE consistent with STRING, PATHNAME, FLOAT, and
RATIONAL as a clear improvement -- possibly outweighing
the costs of both an incompatible change and a decision
to arbitrarily favor one treatment over the other.
DEPRECATE: Some may take the deprecation of COERCE as an
aesthetic improvement because it eliminates the need to
debate this issue further. Others may see the
``de-centralization'' of coercion as a step backward.
Discussion:
Pitman supports COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION.
Hopefully Moon and Masinter support it, too, since it's
basically patterned after a bunch of mail they were sending
back and forth.
A proposal to extend COERCE to permit a ``view type'' argument
was considered and rejected as too extreme to consider seriously
in the timeframe available.
Pierson suggests that COERCE ought to be a candidate for
generic function status.
Pitman thinks that making [two-argument] COERCE generic would
be a -very- bad idea but believes that his earlier proposal
involving a third `view type' argument might be able to
accomodate such extension.
!
Additional comments
I agree that this is ready to send out. The thing about
COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION that strikes fear
into my heart is that it wipes out CLtL's simple statement that
any sequence type may be converted to any other sequence type,
and starts people asking questions like does
(coerce nil '(vector character)) => "" or "NIL"?
This concern is not reflected at all in the writeup.
I agree that this is ready to send out but I'm inclined to vote
no on both proposals and keep the (unsatisfactory) status quo.
----- -----
I believe that any change to the status quo is incomplete without
providing a coercion mechanism whose "viewpoint" is that of a sequence.
That is effectively what the current COERCE is, overloaded with those
types which do not conflict with SEQUENCE.
Because of the problem of differing viewpoints, I'm inclined to think
that COERCE should be shrunk down to only being a sequence coercion
function, and all other coercions should be handled by the appropriate
functions.
----- -----
∂15-Mar-89 0520 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:19:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 05:14:05 PST
Date: 15 Mar 89 05:13 PST
From: masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890315-051405-3472@Xerox>
At the January '89 meeting, Version 4 of this issue was amended,
and then accepted.
We think there were some wording problems with the amendment,
in that it ended up not saying what we think was intended.
The amendment made some meaningful programs have undefined
behavior, and left the meaning of SIMPLE-ARRAY unclear.
After a good deal of work by the members of the cleanup committee,
we've arrived at the following version, which we would like
to submit to you for consideration as to whether it more
properly reflects the intent of the group.
!
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
users, merely making one kind of nonconforming program fail in all
implementations instead of failing only in some implementations. The
argument here is not that the error checking would not be useful for
developers of portable code, but only that the cost of introducing that
error checking would be exceedingly high for some implementations.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
Pitman, Moon, Gabriel, and Steele support this amended proposal.
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂15-Mar-89 0622 X3J13-mailer BASE-CHARACTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:22:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 06:09:24 PST
Date: 15 Mar 89 06:07 PST
From: masinter.pa@Xerox.COM
Subject: BASE-CHARACTER
To: CL-Characters@SAIL.STANFORD.EDU
cc: X3J13@SAIL.STANFORD.EDU
Message-ID: <890315-060924-3563@Xerox>
There were a couple of points that were only tersly alluded to in my note
on the character proposal.
BASE-CHARACTER
I think most of the confusions and problems with BASE-CHARACTER in the
proposal result from its definition in terms of the 'natural' encoding of
an implementation.
I think defining BASE-CHARACTER exactly as
(UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR)
has all of the right properties. (Recall that UPGRADED-ARRAY-ELEMENT-TYPE
was added by the (passed) proposal in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS.)
This definition is unambiguous and shows the relationship between the
string encoding and array upgrading strategies of the implementation and
the important character types. It ensures STANDARD-CHAR is a subtype of
BASE-CHARACTER.
Whether a character is "base" really only depends on the way that an
implementation represents strings, and not any other properties of the
implementation or the host operating system. Imagine two implementations on
a Unix machine, one of which encodes all strings as 16-bit characters, and
another which has two kinds of strings: 8-bit strings and 16-bit strings.
In the first implementation, the BASE-CHARACTER is CHARACTER: there's only
one kind of string. In the second implementation, the BASE-CHARACTER would
be those that could be stored in an 8-bit string, and it would be a proper
sub-type of CHARACTER.
To make this change requires leaving STANDARD-CHAR in the standard and then
merely defining BASE-CHARACTER in terms of it. Clearly BASE-STRING, if such
a name is necessary, would then just be a shorthand for (VECTOR
BASE-CHARACTER) with all the semantics implied by the array-element-type
proposals.
∂15-Mar-89 0636 X3J13-mailer Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:35:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 06:27:41 PST
Date: 15 Mar 89 06:27 PST
From: masinter.pa@Xerox.COM
Subject: Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890315-062741-3597@Xerox>
Version 4 of this issue (with only a version of
the SELECT-ONLY proposal) was discussed and tabled
at the last meeting.
This version includes two proposals; NEW-MACRO
(favored by many members of the cleanup committee)
and a new version of SELECT-ONLY.
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p182-183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
20-Jan-89, Version 5 by Loosemore
30-Jan-89, Version 6 by Loosemore
10-Mar-89, Version 7 by Loosemore
15-Mar-89, Version 8 by Masinter
(add back SELECT-ONLY)
Related-Issues: DEFPACKAGE (passed)
COMPILE-FILE-SYMBOL-HANDLING
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
A more general problem is that the "Put In Seven Extremely Randoms"
convention described in CLtL is now recognized by many people as being
unsatisfactory for both package definition and package selection.
The DEFPACKAGE macro provides a much cleaner mechanism for package
definition, but there is still a need for a convenient way to select
a package that has well-defined compilation semantics.
Proposal (IN-PACKAGE-FUNCTIONALITY:NEW-MACRO):
Add a new macro:
SELECT-PACKAGE name [macro]
This macro causes *PACKAGE* to be set to the package named NAME,
which must be a symbol or string. An error is signalled if the
package does not already exist. Everything this macro does is also
performed at compile time if the call appears at top-level.
Remove the function IN-PACKAGE from the standard.
Remove the second paragraph of section 11.7 in CLtL. (This includes
the requirement for special compile-time treatment of the various
package functions.)
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
The rationale for proposing SELECT-PACKAGE as a replacement for
IN-PACKAGE, rather than simply changing IN-PACKAGE to have this
behavior, is that such an incompatible change would be confusing to
many people, and would make it more difficult to detect obsolete
usages. There is nothing in this proposal that would prevent
implementations from continuing to provide IN-PACKAGE as an extension.
Making SELECT-PACKAGE a macro rather than a function means that there
is no need to require COMPILE-FILE to handle it specially. Since
DEFPACKAGE is also defined to side-effect the compilation environment,
there is no need to require any of the package functions to be treated
specially by the compiler.
The language in section 11.7 of CLtL puts the burden on
implementations of ensuring that all symbols in a file which is
compiled and loaded end up in the same package that they would if the
source file were loaded interpretively. No implementation can
possibly meet this requirement because, in general, the runtime
behavior of the program cannot be predicted by the compiler.
Current Practice:
Probably no one implements this behavior exactly since it's an
incompatible change to CLtL.
Cost to Implementors:
The SELECT-PACKAGE macro can be implemented trivially by using
EVAL-WHEN in its expansion:
(defmacro select-package (name)
`(eval-when (eval compile load)
(setq *package*
(or (find-package ',name)
(error "Package ~s does not exist." ',name)))))
The changes required to COMPILE-FILE to remove the magic treatment
of the package functions are also likely to be small.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary. Programmers that are now using the "Put In Seven
Extremely Randoms" convention will probably find it straightforward
to convert their code to do a DEFPACKAGE followed by a
SELECT-PACKAGE.
Cost of Non-Adoption:
The specification of COMPILE-FILE will be much more difficult to
understand.
The standard will require compilers to solve the halting problem.
Benefits:
Modular package declarations would be encouraged and errors due
to demand-creation of packages would be easier to detect.
The specification of COMPILE-FILE will be simplified.
There will be a clear statement of the requirements for program
conformance, as relating to usage of packages.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Removing it can't be any worse.
The fact that the currently stated requirements for handling of
the package functions by the compiler are not implementable is
clearly not aesthetic.
!
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many will
want to make IN-PACKAGE signal an error. This change would be
straightforward to implement. The cost may not be trivial in all
cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary.
In some cases, no changes would be necessary since files may
already be doing IN-PACKAGE in situations where the author is
hoping he's made sure the real package declaration is already
loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without
appropriate uses of the :USE or :NICKNAMES or without appropriate
calls to EXPORT, etc. afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Some people feel this change would be an aesthetic improvement.
Others feel that an incompatible change to IN-PACKAGE would merely
be confusing.
!
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some people may find proposal NEW-MACRO more palatable if it merely
deprecated IN-PACKAGE, instead of removing it entirely.
Loosemore and Moon support proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO.
Pitman says:
I support NEW-MACRO, though would really prefer you change "remove" to
"deprecate". Making this an incompatible change is gratuitous.
∂15-Mar-89 0924 CL-Characters-mailer BASE-CHARACTER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:24:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557489; Wed 15-Mar-89 12:22:00 EST
Date: Wed, 15 Mar 89 12:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: BASE-CHARACTER
To: CL-Characters@SAIL.STANFORD.EDU
cc: X3J13@SAIL.STANFORD.EDU
In-Reply-To: <890315-060924-3563@Xerox>
Message-ID: <19890315172201.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
After thinking it over, I agree with Larry Masinter's comments
in the referenced message and the suggestion to define BASE-CHARACTER
as (UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR).
∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:36:35 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124413; 15 Mar 89 12:34:29 EST
Date: Wed, 15 Mar 89 12:34 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890315-051405-3472@Xerox>
Message-ID: <19890315173420.1.BARMAR@OCCAM.THINK.COM>
Date: 15 Mar 89 05:13 PST
From: masinter.pa@xerox.com
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
Hooray! We finally got our collective acts together on this one!
barmar
∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:48:17 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:44:45 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:46:05 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:42:51 EST
Date: Wed, 15 Mar 89 12:42:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151742.AA02653@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 14 Mar 89 14:56 PST <890314-145716-2049@Xerox>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
Does KMP intend that GENSYM not be sticky for an integer argument
as well? That is, there is no way to reset the counter?
--Guy
∂15-Mar-89 1016 X3J13-mailer Issue: EXTRA-RETURN-VALUES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:16:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557537; Wed 15-Mar-89 13:12:57 EST
Date: Wed, 15 Mar 89 13:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242235.AA14585@decwrl.dec.com>
Message-ID: <19890315181252.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
This one took longer than the others to answer because it is
a more difficult issue.
Date: 24 Feb 89 17:35
From: chapman%aitg.DEC@decwrl.dec.com
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
Unless it is explicitly allowed in the standard,
if a standard function
returns a different number of return values from the number
specified by the standard, the results are unspecified.
I see a couple of problems with this. First, it is bootless to
prohibit extra return values without also forbidding returning
fewer values than specified. For example, when SUBTYPEP returns
NIL NIL, both NILs must actually be returned, not defaulted.
Second, I don't understand how "the results are unspecified" can be
correct here. First of all, that term doesn't appear in the error
terminology, and I don't know whether you meant "the return values are
unspecified" or "the consequences are unspecified". But I don't see
how you could mean either of those, since in fact what happens when
a certain number of values is returned is fully specified by the
language, and there is neither ambiguity nor implementation freedom.
If we look at the Rationale:
The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."
I think what you must have actually meant to propose is: Functions
specified in the standard must return exactly the number of values
specified in the standard, no more and no fewer. You could phrase this
as a requirement on implementations or as something that a conforming
program is permitted to assume, I don't much care which.
I found 21 functions in the LISP package in Symbolics Genera 7.4 that
return multiple values. Is this the correct number? Just as it was
useful to know that there are exactly 775 symbols in the LISP package
(in CLtL Common Lisp), it would be a useful check to publish the number
of functions that are supposed to return more than one value, and also
the number that are supposed to return no values.
I found two functions that return a different number of values than
CLtL specifies. GETHASH returns a third value, the key it found,
to go with the value it found (this might not be EQL to the argument
when the test is EQUAL or EQUALP). READ-LINE returns two additional
values, the delimiter character and the input-editor argument given
to the delimiter character. The first of these is a useful feature
that Common Lisp ought to have, the second is a necessary extension
for our environment that is not obviously useful in other environments.
After making and thinking about that assessment, my feeling is that I
would vote for this proposal if it was reworded in a way that I could
understand (which might or might not be what I suggested above) and if a
few specific functions (list to be supplied later) were specified to
allow additional values. I think this list would include all of the I/O
functions and would not include any of the arithmetic functions. I
haven't yet consulted with anyone else at Symbolics on this opinion,
though.
∂15-Mar-89 1018 X3J13-mailer BASE-CHARACTER
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:17:14 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 13:13:21 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 13:14:40 EST
Received: by verdi.think.com; Wed, 15 Mar 89 13:11:29 EST
Date: Wed, 15 Mar 89 13:11:29 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151811.AA02727@verdi.think.com>
To: CL-Characters@sail.stanford.edu
Cc: X3J13@sail.stanford.edu
Subject: BASE-CHARACTER
Larry's suggestion about defining BASE-CHARACTER to be simply
(UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR) has a great deal
of charm, and I don't see anything wrong about it.
So I support it.
--Guy
∂15-Mar-89 1227 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:27:28 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA14532; Wed, 15 Mar 89 12:27:45 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA13443; Wed, 15 Mar 89 12:23:50 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA28038; Wed, 15 Mar 89 12:27:22 PST
Date: Wed, 15 Mar 89 12:27:22 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903152027.AA28038@clam.sun.com>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
Cc: x3j13@sail.stanford.edu
Discussion continued on cl-editorial.
∂15-Mar-89 1446 X3J13-mailer Issue ERROR TERMINOLOGY
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Is it the case that ``fatal'' is well-defined? If so, ``harmless'' is
simply something that is not fatal. According to my mathematics
education, that renders the term well-defined.
``Indeed, there is no way to invoke GC in Common Lisp and with a few
exceptions such as messages, GC must have NO side effects.''
Unsolicited messages can happen, and there is a proposal on the
cl-editorial table to render them harmless. If GC can have no side
effects, then why not state that and not wonder about unsolicited
messages? If we did that, then any Common Lisp that does print a
progress note is *out* of conformance.
Also, as I've said several times, rehashing, termination of processes,
progress messages, flushing IO buffers, closing streams, and a list of
possibly hundreds of things are side effects of GC that should be
guaranteed harmless (that is, not fatal).
``> Some things are not immediately harmful but may cause
> trouble later on.
Yes, lots of things are that way.''
The definition of fatal puts no time constraints on the fatality. Therefore,
neither does its negation.
``> By ``unpredictable but harmless'', I think we are in effect saying
> ``not completely unpredictable''. That is, we promise something but
> don't quite say what it is. For example, Lisp will presumably not
> break off and start playing chess. But maybe it's harmless to start
> playing chess.''
The beauty of a specification is knowing what not to say in order to
allow rational interpreters the freedom to interpret rationality now
and in the unpredictable future. There is considerable genius in the
fine line that Steele tread in CLtL on this. Does anyone rationally
think that a Common Lisp would be taken seriously that while GCing
broke out in a game of chess or an Irish gig? I refuse to seriously
debate with anyone who would use that as an example of something that
we must utter one word in the specification to prevent.
``As far as I can see, the only reasonable option is to specify
some range of possible consequences. The constraints, whatever
they may be, make it possible to reason about what the program
will do.''
The reason this won't easily work is that it presumes that we are able
to accurately predict future implementation techniques and even to
fully comprehend current ones. I'm sure that KMP or I could supply an
endless stream of new and bizarre cases that have to be explicitly
dealt with. (I single out KMP because he has uncanny creativity.)
But, I'll change the debate a little. I've claimed that ``harmless''
is well-defined if and only if ``fatal'' is well-defined or at least
defined well enough. So, to convince me that ``harmless'' should be
pitched, you must convince me that ``fatal'' must be pitched.
-rpg-
∂15-Mar-89 1451 CL-Compiler-mailer Issue SAFE-CODE, version 1
To: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.'' This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.
-rpg-
∂15-Mar-89 1506 CL-Editorial-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89 15:06:13 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11469; 15 Mar 89 19:24 GMT
Date: Wed, 15 Mar 89 19:21:20 GMT
Message-Id: <2039.8903151921@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
To: Cris Perdue <cperdue@sun.com>, chapman <@decwrl.dec.com:chapman@aitg.dec>
Cc: kempf <@sun.com:kempf@clam>, peck <@sun.com:peck@clam>,
sgadol <@sun.com:sgadol@clam>, x3j13@sail.stanford.edu,
cl-editorial@sail.stanford.edu, rpg <@sail.stanford.edu:rpg@lucid.com>
Perhaps this discussion should be in cl-editorial...
> From: Cris Perdue <cperdue@com.sun>
> The error terminology is OK, except for "consequences
> are unspecified". That concept is broken, though it
> has serious defenders. For example, Dick Gabriel says,
>
> "If we were to drop this term, then every time we are
> ``explicitly vague'' a valid possibility is that a fatal
> error can occur. How is it any better to say that what happens
> when some operation happens is ``explicitly vague''."
Perhaps the problem is that "harmless" is not very well defined.
Maybe we can convince ourselves that ``the consequences of the garbage
collector when invoked'' are harmless, but how many other examples can
we find? Some things are not immediately harmful but may cause
trouble later on. For example, are the consequences of using EQ to
compare numbers harmless? Suppose we know that a fatal error will not
immediately occur. Is that enough to make it harmless (in this case)?
[I know this is most likely to be a case where the ``return values are
unspecified'', but it was the best I could do on short notice, and we
can ask whether these consequences would be ``harmless'' even if they
wouldn't be described as such in the standard.]
By ``unpredictable but harmless'', I think we are in effect saying
``not completely unpredictable''. That is, we promise something but
don't quite say what it is. For example, Lisp will presumably not
break off and start playing chess. But maybe it's harmless to start
playing chess.
> A typical area of "explicit vagueness" is the destructive operations
> on lists. The explicit vagueness here is quite limited. For
> some operations any top level cell of certain lists may or may
> not be modified. Similar statements apply to other operations.
> The consequences are far from being unspecified but harmless.
> They are CONSTRAINED but meaningful.
This is an interesting example. First, there's the question ``the
consequences of what?'' The consequences of applying the destructive
operation? The consequences of doing anything that depends on whether
or not cells were modified? We really have to see how these phrases
are used in the actual description of a function.
Maybe what we want is this:
The result is a list with certain (specified) properties.
The side effects on cells in the argument list are unspecified.
In addition, there might be a general warning that the consequences of
depending on unspecified side effects are undefined.
In an earlier message, Cris Perdue said:
Let's pick a few actual examples where the language definition is
proposed to say "consequences are unspecified". (Go ahead, I
challenge you.) I think we will find that the description will
have to be more specific than that. It can make sense to say that
"effect X may or may not occur". It can make sense to say that
"data structure Y may be modified arbitrarily". If we can define a
set of effects that we consider harmless, and change "unpredictable
but harmless" to just "harmless", or some such, that could also
make sense, but not the current language.
I am not quite convinced by this argument. We have to be careful not
to make too much undefined. If we consider some operation, some
things may be specified, some things left open, and so on. The
description may have to be ``more specific'' in that we shouldn't
describe the whole thing as ``unspecified'' when we can instead say
something more precise; but that doesn't show that some parts of the
description cannot reasonably use ``unspecified'' or ``undefined''.
Besides, this argument applies just as well to ``undefined'' as it
does to ``unspecified'' -- there would be the same need to be more
specific. So again I suspect it is the ``harmless'' that is really at
fault.
Anyway, the draft C standard makes a somewhat different distinction
between ``unspecified'' and ``undefined''. In particular, correct
programs may have unspecified behavior; those with undefined behavior
are incorrect, or at least nonportable:
Unspecified behavior -- behavior, for a correct program construct
and correct data, for which the Standard imposes no requirements.
Undefined behavior -- behavior, upon use of a nonportable or
erroneous program construct, of erroneous data, or of
indeterminately-values objects, for which the Standard imposes no
requirements. Permissible undefined behavior ranges from ignoring
the situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of a
diagnostic message), to terminating translation or execution (with
the issuance of a diagnostic message).
There is also a category of ``implementation-defined behavior".
An example: in a function call if the argument types or the number of
arguments are wrong [this is said more precisely in the standard]
``the behavior is undefined''. However: ``The order of evaluation of
the function designator, the arguments, and subexpressions within the
arguments is unspecified, but there is a sequence point before the
actual call."
The Rationale (a separate document) says:
The terms unspecified behavior, undefined behavior, and
implementation-defined behavior are used to categorize the result of
writing programs whose properties the Standard does not, or cannot,
completely describe. The goal of adopting this categorization is to
allow a certain variety among implementations which permits quality
of implementation to be an active force in the marketplace, as well
as to allow certain popular extensions, without removing the cachet
of conformance to the standard. An appendix to the standard, A.6,
catalogs those behaviors that fall into one of these three
categories.
Unspecified behavior gives the implementor some latitude in
translating programs. This latitude does not extend so far as
failing to translate the program.
Undefined behavior gives the implementor license not to catch
certain program errors that are difficult to diagnose. It also
identifies areas of possible conforming language extension: the
implementor may augment the language by providing a definition of
the officially undefined behavior.
From all this I conclude that we probably do need both unspecified and
undefined. However, it is unclear exactly what distinction they
should express.
[The C standard also distinguishes between strictly conforming [more or
less: portable] programs and conforming programs.]
-- Jeff
∂15-Mar-89 1553 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 15:52:37 PST
Received: by ti.com id AA13974; Wed, 15 Mar 89 15:08:09 CST
Received: from Kelvin by tilde id AA23610; Tue, 14 Mar 89 11:36:42 CST
Message-Id: <2814888931-7906489@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 14 Mar 89 11:35:31 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
Subject: Re: Issue: EXTRA-RETURN-VALUES
In-Reply-To: Msg of 24 Feb 89 17:35 from chapman%aitg.DEC@decwrl.dec.com
> Proposal: EXTRA-RETURN-VALUES:NO
> Unless it is explicitly allowed in the standard,
> if a standard function
> returns a different number of return values from the number
> specified by the standard, the results are unspecified.
>
>
> Rationale:
>
> The reason is that
> additional arguments are visible to otherwise portable programs. "For
> instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
> will try to pass the wrong number of arguments to CONS if FLOOR returns an
> extra value."
This may be a bit of over-kill. I suggest making this restriction only
for functions which the standard specifies as returning multiple values.
For functions that the standard says return one value, there would be no
reason for a portable program to go out of its way to accept more than
one value from them, so additional values shouldn't hurt.
Also, "the results are unspecified" doesn't seem to be the right
terminology to use here since this is intended to be a restriction on
the implementation. How about:
Unless it is explicitly allowed in the standard, functions which are
specified to return other than one value may not be extended by
implementations to return more values than specified.
∂15-Mar-89 1603 X3J13-mailer Feb. 21 letter ballot
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 16:00:39 PST
Received: by ti.com id AA14034; Wed, 15 Mar 89 15:09:30 CST
Received: from home by tilde id AA26164; Tue, 14 Mar 89 13:07:13 CST
Received: by home id AA15845; Tue, 14 Mar 89 13:07:05 CST
Date: Tue, 14 Mar 89 13:07:05 CST
From: David Bartley <bartley@home.csc.ti.com>
Message-Id: <8903141907.AA15845@home>
To: x3j13@sail.stanford.edu
Subject: Feb. 21 letter ballot
Reply-To: Bartley@ti-csl.csc.ti.com
This is TI's vote on the Feb. 21 letter ballot:
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | Y | | |
------------------------------------------------------------------------
Concerning ERROR-TERMINOLOGY: We understand that this section is
undergoing a significant rewrite.
(By the way, in the definition of CONFORMING CODE, shouldn't there be
a third point saying that conforming code does not depend on the
results of any "undefined" or "unspecified" situations?)
Concerning Section 1.8: This writeup is too terse to be very meaningful
---it looks like a preliminary outline instead of a final draft.
Concerning Section 2.3: Page 2-13 of the draft concerns David Gray
because it does not include any of the classes from page 1-17 of
88-002R. Why did we go through all that hassle of redefining the
FUNCTION type if it is not going to be defined here as a class?
Shouldn't all of the classes on page 1-17 be included?
--db--
∂15-Mar-89 1722 X3J13-mailer Bartley's Comments
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
David writes:
``(By the way, in the definition of CONFORMING CODE, shouldn't there be
a third point saying that conforming code does not depend on the
results of any "undefined" or "unspecified" situations?)''
The descriptions of unspecified and undefined already state exactly this.
Do you think it should be repeated in the definition of conforming code?
-rpg-
∂15-Mar-89 1756 X3J13-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 17:56:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 17:17:14 PST
Date: 15 Mar 89 17:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
To: x3J13@sail.stanford.edu
line-fold: NO
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <890315-171714-1269@Xerox>
!
Issue: BREAK-ON-WARNINGS-OBSOLETE
Forum: Cleanup
References: *BREAK-ON-WARNINGS* (CLtL p432, CL Condition System p40)
*BREAK-ON-SIGNALS* (CL Condition System p25)
Category: CLARIFICATION/CHANGE
Edit history: 07-Mar-89, Version 1 by Pitman
Problem Description:
With the advent of *BREAK-ON-SIGNALS*, *BREAK-ON-WARNINGS* is
redundant and unnecessary.
Proposal (BREAK-ON-WARNINGS-OBSOLETE:DEPRECATE):
Deprecate *BREAK-ON-WARNINGS*.
Test Case:
N/A
Rationale:
This will lead to simplification of the description of WARN.
Not only are the two variables overkill, but they have an effect
in an identifiably but uselessly distinct place.
Current Practice:
Since deprecation is not removal, presumably everyone who conforms
is compatible.
Cost to Implementors:
Since the feature is deprecated rather than flushed: none.
Cost to Users:
Since the feature is deprecated rather than flushed: none.
Users should get used to writing (SETQ *BREAK-ON-SIGNALS* 'WARNING)
rather than (SETQ *BREAK-ON-WARNINGS* T).
Cost of Non-Adoption:
The definition of WARN will be gratuitously cluttered.
Benefits:
Cost of non-adoption is avoided.
Aesthetics:
Slight improvement.
Discussion:
Pitman thinks this is a good idea, but doesn't think a lot of time
should be wasted discussing the issue if there is strong opposition.
∂15-Mar-89 1853 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 18:53:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03073; Wed, 15 Mar 89 17:50:24 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04907; Wed, 15 Mar 89 17:50:16 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903160050.AA04907@defun.utah.edu>
Date: Wed, 15 Mar 89 17:50:14 MST
Subject: Re: Issue: EXTRA-RETURN-VALUES
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Tue, 14 Mar 89 11:35:31 CST
> Date: Tue, 14 Mar 89 11:35:31 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
>
> This may be a bit of over-kill. I suggest making this restriction only
> for functions which the standard specifies as returning multiple values.
> For functions that the standard says return one value, there would be no
> reason for a portable program to go out of its way to accept more than
> one value from them, so additional values shouldn't hurt.
I disagree. I've been known to use an idiom like
(multiple-value-call #'foo (fn1) (fn2))
where FN1 is a standard Common Lisp function which is supposed to return
one value, and FN2 is a function that returns multiple values. If FN1
is allowed to return extra values, this won't work.
-Sandra
-------
∂15-Mar-89 1941 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 89 19:40:55 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Wed, 15 Mar 89 21:39:48 CST id AA08835 for cl-compiler@sail.stanford.edu
Posted-Date: Wed, 15 Mar 89 21:38:06 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA16529; Wed, 15 Mar 89 21:38:06 CST
Date: Wed, 15 Mar 89 21:38:06 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903160338.AA16529@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 15:50:07 -0700 <8903132250.AA02499@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
If we permit the compiler to signal warnings for functions where the
compile-time environment signature is different from the function call
being compiled, why do we prohibit it for generic functions?
From COMPILE-ENVIRONMENT-CONSISTENCY:
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not ... It is, however,
permissible for the compiler to emit warning messages when
compiling calls to functions that are defined in the compiletime
environment, but where the wrong number or type of arguments
are supplied.
But then in CLOS-MACRO-COMPILATION:
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function. The compiler may
perform tests for lambda-list congruence only between the DEFGENERICs
and DEFMETHODs for a given generic function name that appear within
the file being compiled, and not against a generic function of the
same name which exists in the compile-time environment.
∂16-Mar-89 0601 X3J13-mailer Re: issue COMPILER-VERBOSITY, version 6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:01:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 05:48:37 PST
Date: 16 Mar 89 05:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3J13@sail.stanford.edu
Message-ID: <890316-054837-3596@Xerox>
The current practice of this proposal says that one implementation has a
:VERBOSE that is used for what this proposal calls :PRINT, gives no current
examples of :VERBOSE, etc. I'm suspicious of a proposal to add something
that is significantly more complex than what any current implementation
already has.
COMPILE-FILE is significantly more part of the "environment" than LOAD is,
and I think that the less we specify its behavior, the better off we are.
While there are useful programmatic portable invocations of LOAD where
controlling the output behavior portably is important, the case for
portable control of output behavior of COMPILE-FILE is much less strong.
What about environments that support incremental compilation? Where
compilation is handled by a background process? Wouldn't this be
unnecessary junk for them to add?
If we have some doubts about whether some of these 'puppies' are really
useful, shouldn't we leave them behind? Not require them?
Larry
∂16-Mar-89 0632 X3J13-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:32:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 06:23:30 PST
Date: 16 Mar 89 06:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 14 Mar 89 20:27 EST
To: cl-compiler@sail.stanford.edu
cc: X3J13@sail.stanford.edu
Message-ID: <890316-062330-3633@Xerox>
I think the previous sentiment was more strongly toward removing
COMPILED-FUNCTION rather than tightening its definition. However, in the
heat of the FUNCTION-TYPE discussion, this seemed to be a controversial
backward incompatibility (why not just leave it in, but leave it
unspecified?)
I've extracted some quotes about COMPILED-FUNCTION from the CL-CLEANUP
discussion on FUNCTION-TYPE. Of course, these are taken out of context...
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 02 MAR 87 21:29:49 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar
87 21:27:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82Date: Tue, 3
Mar 87 00:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 3 Mar 87 00:26 EST
It might be wise to add LEXICAL-CLOSURE and INTERPRETED-FUNCTION data
types, to go along with the COMPILED-FUNCTION type that already exists.
These three would be disjoint subtypes of FUNCTION, but not necessarily
an exhaustive partition. There might be other ways to slice the space
of types, since it's not so clear what a function not inside a closure
is good for. Alternatively we could flush COMPILED-FUNCTION and say
that the subtypes of FUNCTION are all implementation-dependent. But I
think having COMPILED-FUNCTION without the others is weird.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 21:56:23 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87
21:53:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 00:53:51-EST
Date: Mon, 9 Mar 87 00:53 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them.
- - - - - - - - -
Return-Path: <RPG@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 23:54:05 PST
Date: 08 Mar 87 23:51 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Possibly these should not be required to be pairwise disjoint (?).
I think we shouldn't presume that all implementations implement
functions as closures. I can imagine an implementation with
COMPILED-FUNCTIONs, INTERPRETED-FUNCTIONs, COMPILED-CLOSUREs,
and INTERPRETED-CLOSUREs.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 09 MAR 87 08:07:46 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87
08:01:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 10:57:49-EST
Date: Mon, 9 Mar 87 10:57 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Well, these make sense only in systems that do support both compiled and
interpreted code. In compiler-only or interpreter-only systems, I guess
the best move would be to say that every function is a member of both of
these subtypes: it is both a fast function and a slow function.
Now you're the one who is letting the user see internal stuff that is
none of his concern. All of these functions are closures, in that they
no longer have any free variables waiting to be closed. In some cases,
there may have been none in the first place, and implementors may want
to use some efficient internal form in such cases, but is there any
reason the user needs to know that? A confusing concept that does him
no good (I think).
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 10 MAR 87 07:54:56 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar
87 07:48:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89098; Tue
10-Mar-87 01:57:50 EST
Date: Tue, 10 Mar 87 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... I vacillate between
saying that all of the subtypes of FUNCTION are implementation-dependent
and shouldn't be standardized (thus COMPILED-FUNCTION should be
removed), and saying that programs might want to know this information,
so all the plausible subtypes should have standard names, even if they
aren't distinct in some implementations. The only thing I feel strongly
and consistently about is that COMPILED-FUNCTION should not be the only
standardized subtype of FUNCTION; it should either acquire some siblings
or go away.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 MAY 87 00:13:57 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May
87 00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already
implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be
flushed.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 17 MAY 87 19:32:45 PDT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87
19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 87 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P. That's what I proposed in version 3. The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example. Then there's the question of whether closures are, or can be,
a separate subtype. In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment. However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.
In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
- - - - - - - - -
Date: 29 May 87 21:18 PDT
Subject: Issue: FUNCTION-TYPE (version 4)
From: Masinter.pa
Proposal FUNCTION-TYPE:REDEFINE
...
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 01 JUN 87 21:23:10 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun
87 21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue
2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
If it also removes the COMPILED-FUNCTION type-specifier, say so here.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Masinter.pa@Xerox.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 JUL 87 12:58:35 PDT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 12:54:07
PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
From: Masinter.pa
... My notes [from X3J13 meeting] include ... that we be more consistent
about justifying removing COMPILED-FUNCTION-P (i.e., why bother?) ...
- - - - - - - - -
Date: 23 Oct 87 11:51 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (Version 6)
here is a revised version... I left COMPILED-FUNCTION and
COMPILED-FUNCTION-P as subtypes of FUNCTION.
...
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
...
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations are
free to define other subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.
- - - - - - - - -
(wording preserved through several iterations)
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 16 FEB 88 09:41:39 PST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88
09:39:23 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA23751; Tue, 16 Feb 88 10:39:08 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA25191; Tue, 16 Feb 88 10:39:04 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8802161739.AA25191@orion.utah.edu>
Date: Tue, 16 Feb 88 10:39:02 MST
Also, I have a question about 1b, where it states that COMPILED-FUNCTION
is a subtype of FUNCTION. Does this imply that it must be a *proper*
subtype? For example, in the Lisp I've been working on sporadically for
my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a
compiled function object (it's a closure which will apply the lambda
expression to the function arguments). Likewise I can conceive of
implementations which compile everything and don't have an "interpreter"
at all. I think this needs to be clarified.
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 19 FEB 88 14:37:22 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88 14:34:11
PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST
Date: 19 Feb 88 14:17 PST
From: Masinter.pa
I intended not to require that it not be a "proper" subtype in the sense
that
there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP.
This can be clarified.
- - - - - - - - -
Return-Path: <edsel!jonl@labrea.Stanford.EDU>
Received: from labrea.Stanford.EDU by Xerox.COM ; 24 FEB 88 10:14:38 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:20 PST
Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88
10:03:43 PST
Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST
Date: Wed, 24 Feb 88 10:09:26 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Lucid Common Lisp distinguishes "compiled" closures which exist for the
purpose of supporting entry into the interpreter from functions which are
truly compiled. It only takes a bit in a header word. If an
implementation
really doesn't support an interpreter, then having every function be
COMPILED-FUNCTIONP doesn't sound like much of a loss.
But most implementations in fact do support an interpreter -- which
typically runs code at anywhere from 30 to 600 times slower than when
compiled. Thus it seems reasonable to require COMPILED-FUNCTIONP in
those implementations to be false on, say,
(eval '#'(lambda (x) (list x)))
no matter what underlying technique is used to support interpreter
closures.
- - - - - - - - -
Date: 4 Sep 88 13:39 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO
This is the final version of the FUNCTION-TYPE issue, as passed at the June
88 X3J13 meeting; that is, it incorporates the amendments that were adopted
before the issue was adopted.
...
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
∂16-Mar-89 0713 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:13:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:07:49 PST
Date: 16 Mar 89 07:07 PST
From: masinter.pa@Xerox.COM
To: x3J13@sail.stanford.edu
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
line-fold: NO
Message-ID: <890316-070749-3717@Xerox>
!
Issue: TIME-ZONE-NON-INTEGER
References: Section 25.4.1 (Time Functions) (p. 443-444)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
Problem Description:
CLtL states that the time zone part of Decoded Time is an integer. However,
it is possible to have a non-integer time-zone.
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Rationale:
For CL to accommodate all possible time designations, it is necessary
to allow time zone to be non-integer.
Some places in the world are on half-hour or quarter-hour times.
Current Practice:
VAX LISP allows time zone to be non-integer.
Adoption Cost:
Shouldn't be too big a change.
Benefits:
See Rationale.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂16-Mar-89 0720 X3J13-mailer Issue: LOAD-TRUENAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:20:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:13:53 PST
Date: 16 Mar 89 07:13 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LOAD-TRUENAME (Version 1)
To: x3J13@SAIL.Stanford.EDU
Message-ID: <890316-071353-3747@Xerox>
!
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
!
Additional Comments:
"I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES. I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename. The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename. This includes file systems with symbolic
links and some pathname systems with logical pathnames."
"I favor this. I would even favor either of the other two ideas even at
this `late date'. The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.
I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them."
∂16-Mar-89 0708 CL-Compiler-mailer Re: Issue SAFE-CODE, version 1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:08:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:03:17 PST
Date: 16 Mar 89 07:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue SAFE-CODE, version 1
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 Mar 89
14:51 PST
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Message-ID: <890316-070317-3708@Xerox>
I'm guessing that Moon's objections are more serious than yours.
Frankly, as long as we're playing definitions, I think the problem lies
with
"Define that, formally, the term ``safe code'' is code refers to any
code in which the OPTIMIZE quality for SAFETY has a value of 3."
I don't think this is a good definition. It is probably good to define that
"any code in which the OPTIMIZE quality for SAFETY has a value 3" is "safe
code", but there is other code that is "safe" too.
It seems pretty awkward to say that:
(locally (declare (optimize (safety 0))) (list 1 2 3))
is "unsafe" or "nonsafe" or "potentially non-safe". We could use the words
that way, but it is pretty confusing.
Counter-proposal: say "declared safe" or "not declared safe", since the
issue is not the (English) safety of the code but the declarations in
effect?
∂16-Mar-89 0719 X3J13-mailer Re: issue LOAD-TIME-EVAL, version 11
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:19:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21484; Thu, 16 Mar 89 08:16:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05509; Thu, 16 Mar 89 08:16:32 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161516.AA05509@defun.utah.edu>
Date: Thu, 16 Mar 89 08:16:30 MST
Subject: Re: issue LOAD-TIME-EVAL, version 11
To: masinter.pa@Xerox.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 06:45 PST
> Date: 16 Mar 89 06:45 PST
> From: masinter.pa@Xerox.COM
>
> Um, I looked for and didn't find a justification for why what was passed at
> the last meeting was inadequate. I'm puzzled as to why there are now two
> proposals when there was one before, what the differences are between them,
> etc.
What happened is that we got some e-mail on this issue after the
meeting, describing in more detail some objections to the wording of
the proposal that had been discussed very briefly at the meeting.
This person thought that the original wording was too vague and that
we would have trouble being more explicit about the semantics it was
intended to specify, and suggested some new wording for slightly
different semantics. I think it is the consensus of the compiler
committee that the new language is an improvement.
The changed section of the proposal is clearly marked in the writeup
that was distributed. It has to do with under what circumstances it
is permissible to cache LOAD-TIME-VALUE expressions.
-Sandra
-------
∂16-Mar-89 0831 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:31:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 08:20:29 PST
Date: 16 Mar 89 08:19 PST
From: masinter.pa@Xerox.COM
Subject: Issue DESCRIBE-UNDERSPECIFIED, v.1
To: x3j13@SAIL.STANFORD.EDU
line-fold: NO
Message-ID: <890316-082029-3881@Xerox>
!
Forum: Cleanup
Issue: DESCRIBE-UNDERSPECIFIED
References: CLtL p441-2
88-002R, DESCRIBE function
Category: CHANGE, ADDITION
Edit history: Version 1, 10-Mar-89, Kim A. Barrett
Problem description:
The CLOS Specification (X3J13 Document 88-002R) changes the definition of the
function DESCRIBE, making it a generic function. However, it does not specify
any of the protocol needed to make user-defined methods interact properly to
produce some of the effects mentioned in CLtL. For example, CLtL says that
sometimes the method for describing an object will involve describing
something that it finds inside the object, and that such recursive
descriptions are indented appropriately. How do user-written methods achieve
this indentation? Must they arrange for the indentation explicitly, or is
there some automatic mechanism that handles it?
The new specification does not easily lend itself to certain kinds of features
which some implementations have included in their versions of DESCRIBE, such
as analogues to the printer's depth limits (*PRINT-DEPTH*) and circular
structure detection during recursion (*PRINT-CIRCLE*).
In addition, DESCRIBE does not take a stream argument, instead always doing
output to *STANDARD-OUTPUT*. This means that a program which wants to use
DESCRIBE to output some information to a particular stream must rebind
*STANDARD-OUTPUT* around the call to DESCRIBE. This is a nuisance, and is
also potentially a bad idea in implementations which have interrupts and such.
Proposal DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT:
Remove the section of 88-002R which specifies that DESCRIBE is a generic
function. Modify DESCRIBE to accept an optional second stream argument, which
defaults to *STANDARD-OUTPUT*. The value of this argument is the stream which
output will be directed to. Specify that DESCRIBE is implemented in terms of
the generic function DESCRIBE-OBJECT, described below.
DESCRIBE-OBJECT object stream [Generic Function]
The generic function DESCRIBE-OBJECT writes a description of an object to a
stream. The function DESCRIBE-OBJECT is called by the DESCRIBE function; it
should not be called by the user.
Each implementation is required to provide a method on the class
STANDARD-OBJECT and methods on enough other classes so as to ensure that
there is always an applicable method. Implementations are free to add
methods for other classes. Users can write methods for DESCRIBE-OBJECT for
their own classes if they do not wish to inherit an implementation-supplied
method.
ARGUMENTS:
The first argument is any Lisp object. The second argument is a stream; it
cannot be T or NIL.
VALUES:
The values returned by DESCRIBE-OBJECT are unspecified.
REMARKS:
Methods on DESCRIBE-OBJECT may recursively call DESCRIBE. Indentation,
depth limits, and circularity detection are all taken care of automatically,
provided that each method handles exactly one level of structure and calls
DESCRIBE recursively argument if there are more structural levels.
If this rule is not obeyed, the results are undefined.
In some implementations the stream argument passed to a DESCRIBE-OBJECT
method is not the original stream, but is an intermediate stream that
implements parts of DESCRIBE. Methods should therefore not depend on the
identity of this stream.
Rationale:
This proposal was closely modeled on the CLOS description of PRINT-OBJECT,
which was well thought out and provides a great deal of functionality and
implementation freedom. The same implementation techniques applicable to
PRINT-OBJECT will be applicable to DESCRIBE-OBJECT.
The reason for making the return values for DESCRIBE-OBJECT unspecified is to
avoid forcing users to include explicit (VALUES) in all their methods.
DESCRIBE will take care of that.
Current practice:
Probably nobody does precisely what this proposal suggests.
Cost to Implementors:
A fair amount of work may be required, since every method/subfunction of
DESCRIBE in an implementation may need at least some fixing to be in line with
this proposal. On the other hand, that work may already be needed in order to
conform to 88-002R, and this proposal may make the conversion easier by
simplifying the translation of an existing implementation of DESCRIBE.
Cost to Users:
Any users who are using an implementation which supports the current CLOS
specification of DESCRIBE and have defined their own methods will have to
change them. CLOS is sufficiently recent that this probably isn't a big
problem.
Those users who have made use of implementation-specific hooks into DESCRIBE
to define their own methods will likely have to change, but that was already
the case.
Users who are currently binding *STANDARD-OUTPUT* around calls to DESCRIBE may
wish to change their code.
Cost of non-adoption:
Portable DESCRIBE methods may be difficult to write because the protocol they
must follow is insufficiently specified.
Benefits:
The constraints on DESCRIBE methods are better specified, making it easier to
write such methods properly.
Aesthetics:
Minimal.
Discussion:
An additional change which is not included in the present proposal would be to
make the syntax of DESCRIBE and DESCRIBE-OBJECT be
DESCRIBE object &optional stream &key
DESCRIBE-OBJECT object stream &key
allowing implementation-specific extensions to the arguments. A possible
standard keyword argument is :VERBOSE, which might be used to specify how much
output to produce.
It might be desirable to define some new describe control variables analogous
to the printer control variables, ie. *DESCRIBE-LEVEL* and *DESCRIBE-CIRCLE*,
and possibly *DESCRIBE-LENGTH*.
-------
----- End Forwarded Messages -----
∂16-Mar-89 0854 X3J13-mailer Issue: CLOS-CONDITIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:54:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 08:44:08 PST
Date: 16 Mar 89 08:43 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CLOS-CONDITIONS (Version 4)
To: X3J13@SAIL.Stanford.EDU
line-fold: NO
Message-ID: <890316-084408-3922@Xerox>
There've been various comments on this version; most of the
relevant discussion centers on whether the metaclass of
condition classes should be specified. Exerpts from
the mail appear at the end.
!
Status: DRAFT
Issue: CLOS-CONDITIONS
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
10-Mar-89, Version 4 by Pitman (remove unsupported options)
Problem Description:
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Proposal (CLOS-CONDITIONS:INTEGRATE):
1. Define that condition types are CLOS classes.
2. Define that condition objects are CLOS instances.
3. Functions such as SIGNAL, which take arguments of class names, are
permitted to take class objects. Such class objects must still be
subclasses of CONDITION.
4. Define that slots in condition objects are normal CLOS slots. Note
that WITH-SLOTS can be used to provide more convenient access to the
slots where slot accessors are undesirable.
5. Incompatibly change the syntax of a slot in DEFINE-CONDITION
to be compatible with a DEFCLASS slot specification.
An implication of this change is that forms like
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR)
((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
6. Permit multiple parent-types to be named in the list of parent types.
Define that these parent types are treated the same as the superior
class list in a CLOS DEFCLASS expression.
7. Eliminate the :CONC-NAME option to DEFINE-CONDITION.
8. Define that condition reporting is mediated through the PRINT-OBJECT
method for the condition type (class) in question, with *PRINT-ESCAPE*
always being NIL. Specifying (:REPORT fn) in the definition of a
condition type C is equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
Rationale:
These changes are consistent with the intent of the X3J13 endorsement
of CLOS and the Common Lisp Condition System.
Although items 5 and 7 are incompatible with the interim condition
handling which we've been working with, the overall proposal significantly
improves compatibility with CLOS.
This compatibility will make the language seem less fragmented, and
probably more learnable because there will be fewer paradigms to learn.
Also, items 5 and 7 in particular are an improvement for reasons
unrelated to CLOS if only because they get rid of the need for symbol
concatenation, a process which has been seen to cause problems because
of the transient nature of the binding of *PACKAGE*.
Examples:
Slot specifiers...
A slot specifier of X is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X) is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X V) would no longer be valid.
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
would be rewritten
(DEFINE-CONDITION FOOBAR (FOO BAR)
((X :INITARG :X :READER FUBAR-X)
(Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ())
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
(ERROR 'OOPS)
>>Error: Oops! Something went wrong.
Current Practice:
Some implementations supporting CLOS probably already do this,
or something very similar.
Cost to Implementors:
If you really have CLOS, this is very straightforward.
Cost to Users:
Small, but tractable.
The main potential problems are:
- :CONC-NAME. There is nothing that keeps an implementation from
continuing to support :CONC-NAME for a short while until old code
has been upgraded.
- The incompatible change to slot syntax. Again, it is possible to
unambiguously recognize a 2-list as old-style syntax and an
implementation can provide interim compatibility support during
a transition period.
Even if implementations did not provide the recommended compatibility
support, users could trivially shadow DEFINE-CONDITION and provide the
support themselves, expanding into the native DEFINE-CONDITION in the
proper syntax.
In any case, the total number of uses of DEFINE-CONDITION at this
point is probably quite small. Searching for them and repairing
each by hand is probably not an expensive operation.
Cost of Non-Adoption:
Conditions will seem harder to manipulate than other user-defined types.
People will wonder if CLOS is really something we're committed to.
Benefits:
A more regular, more learnable language.
Aesthetics:
Improved.
Discussion:
Gregor, Pierson, Moon, and Pitman support this proposal.
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
The sense of the cleanup committee was that it was acceptable for
a vendor to identify a CLOS-free subset of Common Lisp, but that since
the position of X3J13 seems to be that no resources should be devoted
to work on subsets, it was inappropriate for us to work out the details
of that subset ourselves. Since nothing about this proposal would
impede such a subset, we took that to be adequate basis for presenting
this single proposal.
Moon thinks we might want to add condition types for the errors
CLOS might signal. Richard Mlynarik thinks we should add a generic
function, REPORT-CONDITION, which is used for reporting conditions.
Both of these issues should probably be pursued under separate cover.
!
"One comment is that you should explicitly mention bootstrapping
concerns under cost to implementors. If you just leave it out,
someone may think it is a difficult problem. "
"This isn't any sort of clarification. The actual clarification required
-- which has been requested several times, and not just by myself -- is
what the *METACLASS* of condition types is.
Condition types may be "CLOS classes" without being STANDARD-CLASSes
Condition objects may be "CLOS instances" without being STANDARD-OBJECTs.
Just what are "normal CLOS slots"? As I see it, the "normalcy" or
otherwise of slots is determined by the metaclass.
My opinion for some time has been that condition types should not be
STANDARD-CLASSes but instead something like READ-ONLY-CLASS.
Conceptually, It Is An Error to modify the slots of condition objects,
which are supposed to be immutable descriptions of part of the state of
a computation. Implementationally,
(setf (slot-value <condition-object> <slot-name>) <new-value>) should
signal an error.
(I also think that conditions in particular have a strong need for
something like :REQUIRED-INIT-KEYWORDS, but that's another story.)
Even if you decide to make condition classes' metaclass STANDARD-CLASS,
the point is that you need to state this, so that users may define
condition classes and mixins using DEFCLASS."
"I do not agree that it is a -necessary- thing to specify the Meta-Class
of conditions because all intended uses of conditions can be done
without this information.
I agree that it is a -possibly useful- thing to do, but there is a down
side to it -- it would unnecessarily tie the hands of people who want
implementation flexibility for one reason or another."
"... If we don't specify the metaclass, then users
won't know what other classes they can mix in when defining condition
classes. It may seem weird, but I can imagine someone wanting to mix
in an arbitrary class into a condition class.
I think we should just say that the class CONDITION is an instance of
STANDARD-CLASS, and that by default DEFINE-CONDITION defines standard
classes. Sure it might be nice to do the read only class thing but I
don't think this is a good time to design a special purpose metaclass
for this. "
∂16-Mar-89 0928 CL-Compiler-mailer Issue SAFE-CODE, version 1
To: cl-compiler@SAIL.Stanford.EDU
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The point of these definitions is to lay out terminology that
enables programmers to know with certainty on what ground they stand
with respect to the specification. ``Safe code'' is a technical term
that means that the code was ``processed'' under this declaration.
This means intuitively that it is as safe (English word) as it can get.
But it also means that it is ``safe code'' in the CL jargon, and eveything
we say about safe code there is also true of it.
The meaning of safe code (English phrase), as in ``as safe as it can
get,'' is spelled out in the specification as the sequence of statements
we make about the attributes of safe code. It might be that some or all of
those attributes apply to code processed under lower safety optimization
levels, but the programmer can be sure only when the highest safety level
is used.
I think Moon's problem is that the usual practice is to borrow English
words for these technical terms, and that works fine until the
negation of the term is needed. We want some word to mean ``not `safe' ''.
``Unsafe'' is an available English word that does not mean the
complement of ``safe'', it means the reverse of safe. Thus, the parallel
senses of the technical pair ``safe/unsafe'' are not the same as the
vernacular pair safe/unsafe.
Also, the definitions of the terms point out that what is defined as
``unsafe code'' might actually be exactly as safe (English) as ``safe code.''
-rpg-
∂16-Mar-89 0958 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:57:58 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124433; Wed 15-Mar-89 19:37:26 EST
Date: Wed, 15 Mar 89 19:37 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: Issue: EXTRA-RETURN-VALUES
To: David N Gray <Gray@dsg.csc.ti.com>
cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <2814888931-7906489@Kelvin>
Message-ID: <19890316003719.1.BARMAR@OCCAM.THINK.COM>
Date: Tue, 14 Mar 89 11:35:31 CST
From: David N Gray <Gray@dsg.csc.ti.com>
> Proposal: EXTRA-RETURN-VALUES:NO
> Unless it is explicitly allowed in the standard,
> if a standard function
> returns a different number of return values from the number
> specified by the standard, the results are unspecified.
>
>
> Rationale:
>
> The reason is that
> additional arguments are visible to otherwise portable programs. "For
> instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
> will try to pass the wrong number of arguments to CONS if FLOOR returns an
> extra value."
This may be a bit of over-kill. I suggest making this restriction only
for functions which the standard specifies as returning multiple values.
For functions that the standard says return one value, there would be no
reason for a portable program to go out of its way to accept more than
one value from them, so additional values shouldn't hurt.
But MULTIPLE-VALUE-CALL permits multiple arguments, some of which might
be calls to functions documented as returning only one valid, e.g.
(multiple-value-call #'three-arg-function (cons x y) (floor x y))
MV-CALL is being used to get the multiple values of FLOOR passed as the
second and third argument to THREE-ARG-FUNCTION, but this will fail if
CONS returns the wrong number of values.
barmar
∂16-Mar-89 0958 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:58:20 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124441; 16 Mar 89 12:16:49 EST
Date: Thu, 16 Mar 89 12:16 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
To: masinter.pa@xerox.com
cc: x3J13@sail.stanford.edu
In-Reply-To: <890316-070749-3717@Xerox>
Message-ID: <19890316171639.5.BARMAR@OCCAM.THINK.COM>
Date: 16 Mar 89 07:07 PST
From: masinter.pa@xerox.com
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Just to show you, when I become a billionaire I'll form my own country
and give it an irrational time zone (e in the winter, sqrt(2) in the
summer).
Seriously, is there any particular reason not to allow any non-complex
number as a time zone?
barmar
∂16-Mar-89 0957 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:57:06 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124431; Wed 15-Mar-89 19:28:46 EST
Date: Wed, 15 Mar 89 19:28 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Cris Perdue <cperdue@sun.com>, chapman <@decwrl.dec.com:chapman@aitg.dec>,
kempf <@sun.com:kempf@clam>, peck <@sun.com:peck@clam>, sgadol <@sun.com:sgadol@clam>,
x3j13@sail.stanford.edu, cl-editorial@sail.stanford.edu, rpg <@sail.stanford.edu:rpg@lucid.com>
In-Reply-To: <2039.8903151921@subnode.aiai.ed.ac.uk>
Message-ID: <19890316002837.0.BARMAR@OCCAM.THINK.COM>
A while back I proposed (to the Editorial committee) a definition of
"harmless" that I still like: Equivalent to an arbitrary conforming
program. The point of this definition is to say that the consequences
of the situation are undefined, but it can't do anything that a valid
program can't do (if we had a denotational semantics, or a virtual
machine specification as I believe the C standard does, we could
probably use that to specify this). For instance, it won't result in
pointers to unallocated data being stored in the application's data, or
changing components of function objects. Undefined consequences would
allow such things, and they can result in secondary effects such as
crashing the system or the process dumping core. Note that my
definition includes signaling an error among the harmless consequences.
Yes, this definition allows such situations to result in playing chess,
and if the computer is controlling a bomb silo it could also result in
starting World War III. I don't think a general definition of
"unspecified" can possibly disallow these things. We might want to
rethink the applicability of the word "harmless" in this case. I think
market forces are adequate to guarantee that the actual results in any
particular implementation will be reasonable, and we won't have
computers all over the country playing chess when you ask them to CONS.
By the way, I've decided that the "consequences of the garbage collector
are unspecified" example is totally bogus. The garbage collector is
completely transparent to a Common Lisp program. The usual
counterargument (which I used to give) is that GC usually changes the
output of the ROOM function, but so can CONS, MAKE-ARRAY, etc.; the
language doesn't even guarantee that (PROGN (ROOM) (ROOM)) will print
the same output twice (it probably won't if ROOM conses). It can also
be argued that GC can be detected by noticing how long operations take,
but on time-sharing systems there are other reasons why an operation may
take a long time. GC may reorder the elements in a hash table, but we
never guarantee that MAPHASH of a hash table will consistently process
the elements in the same order, and SETF of GETHASH may also rehash the
table. I challenge someone to write a conforming Common Lisp program
GC-P that takes as an argument a function, applies the function, and
returns a boolean result indicating whether a GC occurred during the
function execution.
If we can't come up with another example of an unspecified situation,
perhaps we should just throw out the term and stop fighting about it.
barmar
∂16-Mar-89 0958 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:58:47 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124445; 16 Mar 89 12:31:52 EST
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: masinter.pa@xerox.com
cc: cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <890316-062330-3633@Xerox>
Message-ID: <19890316173142.7.BARMAR@OCCAM.THINK.COM>
I'll just reiterate something I said at one of the meetings. One
portable use I can think of for the COMPILED-FUNCTION type is as a
declaration to allow compiler optimization. If a function knows (or
requires) that a parameter is a compiled function it can declare that
and the implementation may be able to optimize the FUNCALL better.
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures (well, at least it doesn't accept them in Genera 7.2),
but they satisfy the type specifier, but it would be nice if there were
a standard set of primitives that would allow one to write something
that does what the above tries to do.
barmar
∂16-Mar-89 1040 X3J13-mailer Re: Issue ERROR TERMINOLOGY
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:40:10 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08149; 16 Mar 89 18:31 GMT
Date: Thu, 16 Mar 89 18:29:06 GMT
Message-Id: <2499.8903161829@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue ERROR TERMINOLOGY
To: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 15 Mar 89 1446 PST
> Is it the case that ``fatal'' is well-defined? If so, ``harmless'' is
> simply something that is not fatal. According to my mathematics
> education, that renders the term well-defined.
"Harmless" does not mean "not fatal".
"Undefined" means the standard imposes no constraints (and irrational
implementors can do whatever they want and still have a conforming
implementation). But "unspecified" imposes some constraints. I
didn't find "harmless" a sufficiently enlightening description of
these constraints. If no one feels inclined to suggest something
better now, I am happy to wait and see how "unspecified" gets used in
the standard before deciding whether or not "harmless" works.
∂16-Mar-89 1044 X3J13-mailer Issue: CLOSED-STREAM-OPERATION (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 09:51:25 PST
Date: 16 Mar 89 09:43 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATION (Version 7)
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-095125-4330@Xerox>
Version 5 of issue CLOSED-STREAM-OPERATION was brought up at
the January 1989 meeting.
The proposal CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY was amended at
that meeting; the amended version passed.
Version 5 said
"If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed without error but the return value is not specified."
The amendment was to change the wording so that CLOSE would
return NIL if given a closed stream, viz:
" If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed with out error but the return value will be NIL."
Kent Pitman has made an argument that the amendment
was ill-considered.
I find his argument convincing.
I think procedurally we can vote to reconsider &
revoke the amendment, i.e., revert to Version 5.
Excerpts from the discussion:
Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by Xerox.COM ; 06 FEB 89 10:12:19 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534168; Mon 6-Feb-89 13:11:33 EST
Date: Mon, 6 Feb 89 13:11 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
...
I think one ought not be able to depend
on the result in this case [of CLOSE of a closed stream]
because implementations might reasonably differ
about whether the first CLOSE really closed the stream. As such,
(LIST (CLOSE *TERMINAL-IO*) (CLOSE *TERMINAL-IO*))
might reasonably return (T T) or (T NIL), for example, depending on whether
the implementation represents the concept of `open-ness' for all streams.
The same is true for string streams.
The issue is even weirder for composite (eg, broadcast) streams where some
streams are initially open and others are not, since I think we have no
clear theory of whether such a stream is opened or closed.
...
Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by Xerox.COM ; 15 FEB 89 07:04:19 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539477; Wed 15-Feb-89 10:03:58 EST
Date: Wed, 15 Feb 89 10:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
What's weird about this whole thing is that CLOSE-CONSTRUCTED-STREAM
talks about the effect of most operations being `unspecified' after
CLOSE.
Unless you intend it to be an implication of CLOSE-CONSTRUCTED-STREAM
that you actually carry a CLOSED-P bit around in every stream so you
can tell if the stream is open or not and return the right value from
CLOSE, then it's a bad idea to legislate that CLOSE returns a certain
value, because you can't really guarantee that value.
If you do intend me to carry around a CLOSED-P bit, why bother to
claim that the effect of I/O to the stream after it's closed is
`unspecified.' My assumption before was that it was unspecified in
case I want to define it, but suddenly it sounds like I'm not really
allowed to extend it -- I'm just permitted to optimize out the error
checks for the sake of efficiency. If this is so, why not just put it
in the domain of `should signal' so that at least the users could get
some mileage out of it because my implementation pretty much has its
hands tied at this point.
We get calls all the time from users who claim we're in violation of
things that really CLtL leaves vague. This will be such a thing given
the way it's all worded.
Here I am implementing CLOSE. I -really- want to implement it correctly.
I am willing to do anything necessary to make it return the right value
as long as what I do is something that is backed up in writing.
Here you are designing CL -- creating the writing that will back me up.
If you cannot show me how to write CLOSE in a way so that I can simply
point to a sentence in the manual that explains off my behavior whenever
anyone complains so I can get them off the phone and get back to work,
then you owe me a sentence in the manual that says that I'm entitled to
do whatever I feel like and the user cannot depend on it.
False security is worse than no security at all.
∪End of message∪
∂16-Mar-89 1051 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:51:31 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA06620; Thu, 16 Mar 89 13:49:18 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07280; Thu, 16 Mar 89 13:47:38 EST
Message-Id: <8903161847.AA07280@mist.>
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
Cc: x3j13@sail.stanford.edu, cl-editorial@sail.stanford.edu
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
In-Reply-To: Your message of Wed, 15 Mar 89 19:28:00 -0500.
<19890316002837.0.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 13:47:36 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 15 Mar 89 19:28 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
A while back I proposed (to the Editorial committee) a definition of
"harmless" that I still like: Equivalent to an arbitrary conforming
program. The point of this definition is to say that the consequences
of the situation are undefined, but it can't do anything that a valid
program can't do (if we had a denotational semantics, or a virtual
machine specification as I believe the C standard does, we could
probably use that to specify this). For instance, it won't result in
pointers to unallocated data being stored in the application's data, or
changing components of function objects. Undefined consequences would
allow such things, and they can result in secondary effects such as
crashing the system or the process dumping core. Note that my
definition includes signaling an error among the harmless consequences.
I like this idea.
∂16-Mar-89 1044 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 09:59:01 PST
Date: 16 Mar 89 09:57 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-095901-4371@Xerox>
There are some additional comments at the end.
!
Issue: COERCE-INCOMPLETE
Reference: COERCE (p50)
Category: ADDITION/CHANGE
Edit history: Version 1 of COERCE-INCOMPLETE, 26-Feb-88 by M. Ida
Version 1 of COERCE-FROM-TYPE, 20-Jun-88 by Pitman
Version 2 of COERCE-INCOMPLETE, 21-Nov-88 by Pitman
(consolidate previous two proposals)
Version 3 of COERCE-INCOMPLETE, 07-Mar-89 by Pitman
(eliminate unpopular proposal, two new options)
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, if the symbol STRING were permitted as a second argument
to coerce, as in (COERCE NIL 'STRING), there would be two posssible
return values: "" or "NIL". The choice would be arbitrary and would
have to be specified by the documentation. No matter which was chosen,
it would probably turn out to be a problem for some applications at
some times.
Another example is (COERCE (CHAR-CODE #\A) 'STRING). This might
return the same as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in
most ASCII-based implementations -- or it might return "A". Again,
the choice would be arbitrary.
There is clear desire on the part of the user community to lift some of
the existing restrictions on arguments to COERCE, but because of legitimate
concerns about ambiguities, the Common Lisp designers have thus far
refused to do so.
Unfortunately, the failure of COERCE to handle these cases means it is
very difficult to learn to use COERCE. And the fact that COERCE is not
easily learned contributes to difficulty in learning Common Lisp because
instead of a single coercion operator with general purpose semantics, a
number of very special purpose coercion operators must be learned instead.
Some middle ground needs to be found, which neither compromises the
clear semantics and portable nature of COERCE nor complicates COERCE
in a way that makes it unlearnable.
Also, some people have expressed a desire for COERCE to be more
`symmetric.' Usually they seem to mean that they want it to be the case
that if (COERCE x y) works, then (COERCE (COERCE x y) (TYPE-OF x))
should also work. Although this is not an essential desire, it would
certainly be nice to achieve.
Proposal (COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION):
Define COERCE to accept the following equivalences:
1. (COERCE x 'STRING) == (STRING x)
2. (COERCE x 'PATHNAME) == (PATHNAME x)
3. (COERCE x 'RATIONAL) == (RATIONAL x)
Clarify that
4. (COERCE x 'FLOAT) == (FLOAT x)
Rationale:
Many users think of STRING, for example, as ``the way to coerce
something to a string'' and are baffled why COERCE and STRING
disagree on how to do this.
Such users think that if there's a moral battle to be waged
over how to coerce an object to a STRING, the battle has already
been lost by defining the STRING function -- that whatever
decision is made for STRING must also apply to COERCE for the
sake of simplicity.
Similar arguments can be made for PATHNAME, FLOAT, and RATIONAL.
Proposal (COERCE-INCOMPLETE:DEPRECATE):
Deprecate COERCE.
Rationale:
COERCE is not functionally necessary -- no operation that it does
cannot be done in some other way. As such, it is basically just
a matter of syntactic convenience, and perhaps isn't worth having
around if it will be the subject of endless debate. Deprecating
it would allow us to declare this issue a `dead end' and focus our
attention on matters of greater substance.
Current Practice:
Presumably No one implements either of the proposals at this time,
since none are compatible with CLtL.
Cost to Implementors:
COERCE: Small to moderate.
DEPRECATE: None.
Cost to Users:
COERCE: This is an incompatible change. (COERCE 'NIL 'STRING) => ""
but (STRING NIL) => "NIL". How many applications are impacted by
this change is not clear. It would be straightforward to shadow
COERCE with an alternate definition that did the old thing in
cases where people were worried. Once such cases have been
identified, rewriting
(COERCE X 'STRING)
as
(IF X (COERCE X 'STRING) "")
will suffice in most cases.
DEPRECATE: No immediate work would be needed, although many maintained
applications would get upgraded in order to use the primitives that
are `in vogue.'
Cost of Non-Adoption:
People will continue to see and debate the issues alluded to in
the Problem Description.
Benefits:
The cost of Non-Adoption will be avoided.
Aesthetics:
COERCE: Many people will probably see the idea of making
COERCE consistent with STRING, PATHNAME, FLOAT, and
RATIONAL as a clear improvement -- possibly outweighing
the costs of both an incompatible change and a decision
to arbitrarily favor one treatment over the other.
DEPRECATE: Some may take the deprecation of COERCE as an
aesthetic improvement because it eliminates the need to
debate this issue further. Others may see the
``de-centralization'' of coercion as a step backward.
Discussion:
Pitman supports COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION.
Hopefully Moon and Masinter support it, too, since it's
basically patterned after a bunch of mail they were sending
back and forth.
A proposal to extend COERCE to permit a ``view type'' argument
was considered and rejected as too extreme to consider seriously
in the timeframe available.
Pierson suggests that COERCE ought to be a candidate for
generic function status.
Pitman thinks that making [two-argument] COERCE generic would
be a -very- bad idea but believes that his earlier proposal
involving a third `view type' argument might be able to
accomodate such extension.
!
Additional comments:
"... The thing about
COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION that strikes fear
into my heart is that it wipes out CLtL's simple statement that
any sequence type may be converted to any other sequence type,
and starts people asking questions like does
(coerce nil '(vector character)) => "" or "NIL"?
... I'm inclined to vote
no on both proposals and keep the (unsatisfactory) status quo."
"I believe that any change to the status quo is incomplete without
providing a coercion mechanism whose "viewpoint" is that of a sequence.
That is effectively what the current COERCE is, overloaded with those
types which do not conflict with SEQUENCE.
Because of the problem of differing viewpoints, I'm inclined to think
that COERCE should be shrunk down to only being a sequence coercion
function, and all other coercions should be handled by the appropriate
functions."
∂16-Mar-89 1045 X3J13-mailer DRAFT Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 10:30:53 PST
Date: 16 Mar 89 10:24 PST
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: CONDITION-RESTARTS (Version 1)
To: x3j13@SAIL.Stanford.EDU
line-fold: NO
Message-ID: <890316-103053-4587@Xerox>
There will possibly be a new version of this issue available
at the meeting. Additional comments excerpted at the end...
!
Issue: CONDITION-RESTARTS
Forum: Cleanup
References: Common Lisp Condition System
Category: CHANGE
Edit history: 18-Jan-89, Version 1 by Pitman
Problem Description:
It was noted in the condition system document itself, and many people have
complained privately, that a major weakness of the condition system is the
inability to know whether a particular restart is associated with a
particular signalling action.
The problem being addressed shows itself in situations involving recursive
errors. The programmer wants to make sure that a restart obtained from
FIND-RESTART or COMPUTE-RESTARTS is in fact present for the purpose of
handling some particular error that he is actively focussed on, and not
for some other (outer) error which he was not actively trying to handle.
Proposal (CONDITION-RESTARTS:PERMIT-ASSOCIATION):
1. Define that it is an error for SIGNAL to be called on a condition
more than once.
2. Introduce a function COPY-CONDITION:
COPY-CONDITION condition [Function]
Returns a copy of the given condition.
3. Introduce a macro WITH-CONDITION-RESTARTS which can be used to
dynamically bind the association between a condition and a set
of restarts.
WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
[Macro]
Evaluates CONDITION-FORM and RESTARTS-FORM, the results of which
should be a condition and a list of restarts, respectively. Then
evaluates the body of forms in implicit-progn style, returning the
last form. While in the dynamic context of the body, the function
COMPUTE-RESTARTS will, when given an argument that was the result
of evaluating the CONDITION-FORM, return the list of restarts that
was the result of evaluating the RESTARTS-FORM.
Only the innermost call to WITH-CONDITION-RESTARTS with a given
condition is relevant. In this way, the set of restarts associated
with a given condition can be dynamically extended or restricted.
Usually this macro is not used explicitly in code, since
SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS handle most of the
common cases in a way that is syntactically more concise.
4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
and STORE-VALUE to permit an optional condition object as an argument.
When the extra argument is not supplied, these functions behave
exactly as defined before. (Restarts are considered without
prejudice to whether they have been associated with conditions.)
When this argument is supplied, only restarts with the associated
with the given condition are considered. In all other respects, the
behavior is the same.
Passing a condition argument of NIL is treated the same as passing
no condition argument.
5. Add two new macros SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS:
SIGNAL-WITH-RESTARTS condition &rest restart-clauses [Macro]
This does several things:
1. It enters a context in which the indicated RESTART-CLAUSES
are available. They have the same form as the clauses in
a RESTART-CASE.
2. It evaluates CONDITION expression. [This is done after the
restarts are instantiated because the restarts are probably
still useful in the debugger if an error occurs during the
evaluation of the condition.] The result of the evaluation
must be a condition object.
3. It associates the condition which resulted from the evaluation
with the restarts established in step 1, using the equivalent
of WITH-CONDITION-RESTARTS.
4. It calls SIGNAL on the same condition.
ERROR-WITH-RESTARTS condition &rest restart-clauses [Macro]
Like SIGNAL-WITH-RESTARTS but uses ERROR rather than SIGNAL
in step 4.
6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
to signal and to make restarts available, use the equivalent of
WITH-CONDITION-RESTARTS to associate the conditions they signal with
the defined restarts, so that users can make reliable tests not only
for the restarts being available, but also for them being available
for the right reasons.
Rationale:
1. The ability to recycle a condition object (including the ability to
resignal a condition) means that the same condition object might be
simultaneously active for two different purposes. In such a case,
no test (not even EQ) would suffice to determine whether a particular
restart belonged with a particular signalling action, since the
condition could not uniquely identify the signalling action. By saying
that a given condition may only be signalled once, we guarantee that
the condition can serve as a unique identifier for a signalling action.
2. Since there may now be some code which has begun to rely on the ability
to re-signal a condition, COPY-CONDITION will help to make this
transition easier. Instead of
(SIGNAL already-signalled-condition)
one can write:
(SIGNAL (COPY-CONDITION already-signalled-condition))
3. This is is the minimal level of support needed to set up an
association between restarts and conditions.
4. This provides a natural interface for retrieving and using the
information about the associations between conditions and restarts.
5. This provides a natural interface for the most common case of
wanting to signal a restart with some associated conditions.
Test Case:
(HANDLER-BIND ((ERROR #'(LAMBDA (C) (SIGNAL C)))) (SIGNAL "Test"))
was permissible, but this proposal makes it an error.
(DEFUN TEST-CONDITION-STUFF (OFFER-EXTRA-RESTART
USE-CONDITION-ARGUMENT
USE-FOUND-RESTART)
(HANDLER-BIND ((CONDITION
#'(LAMBDA (C)
(LET ((R0 (FIND-RESTART 'USE-VALUE))
(R1 (IF USE-CONDITION-ARGUMENT
(FIND-RESTART 'USE-VALUE C)
(FIND-RESTART 'USE-VALUE))))
(IF (AND R1 USE-FOUND-RESTART)
(INVOKE-RESTART R1 (EQ R0 R1))
(USE-VALUE (EQ R0 R1)))))))
(HANDLER-BIND ((CONDITION
#'(LAMBDA (C)
(USE-VALUE
(IF OFFER-EXTRA-RESTART
(WITH-RESTARTS
(SIGNAL (COPY-CONDITION C))
(USE-VALUE (X) (LIST 'EXTRA X)))
(SIGNAL (COPY-CONDITION C)))))))
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'SIMPLE-CONDITION
:FORMAT-STRING "Test")
(USE-VALUE (X) X)))))
Previously, this was an error because it uses non-existent primitives, but
if you assume that
- COPY-CONDITION is implemented in the `obvious' way
- SIGNAL-WITH-RESTARTS just uses WITH-RESTARTS and SIGNAL
- FIND-RESTART ignores its last argument
in the obvious naive ways, it is possible to compare the old and new behavior:
Current Proposed
(TEST-CONDITION-STUFF NIL NIL NIL) => T T
(TEST-CONDITION-STUFF NIL NIL T) => T T
(TEST-CONDITION-STUFF NIL T NIL) => T T
(TEST-CONDITION-STUFF NIL T T) => T T
(TEST-CONDITION-STUFF T NIL NIL) => T (EXTRA T)
(TEST-CONDITION-STUFF T NIL T) => T (EXTRA T)
(TEST-CONDITION-STUFF T T NIL) => T (EXTRA NIL)
(TEST-CONDITION-STUFF T T T) => T NIL
Current Practice:
Presumably no implementation does this yet.
Cost to Implementors:
Several small, relatively modular changes.
Cost to Users:
Except for the change to the recyclability of restarts, this change is
upward compatible.
Probably very few if any users currently take advantage of recycling
restarts, so the cost to users of this change is very slight.
Even in the case where recycling is used, a straightforward rewrite in
terms of COPY-CONDITION is probably feasible.
Cost of Non-Adoption:
Use of restarts would not be nearly as reliable.
Benefits:
It would be possible to write code which was considerably more robust.
Aesthetics:
Some people might consider this proposal to make things slightly better
because it avoids some ambiguities. Others might consider it to make
things slightly worse because it adds additional complexity.
Discussion:
Pitman thinks a change of this sort is important.
!
"CONDITION-RESTARTS:PERMIT-ASSOCIATION looks fine to me.
It would certainly clean things up in some code I'm working on.."
"I strongly favor this proposal; it removes the major objection that I
had to the CL condition system as it developed.
However, I don't favor the COPY-CONDITION function. I don't think it's
necessary. More importantly, you have not proposed any concrete specification
of what it does, and unless someone does, it cannot be included in the
language. Fortunately, I think we can just drop it, as I doubt that any
portable program would use it in any significant way that could not just
as well be done with a tiny amount of code using other existing primitives.
[generally agreed]
" .. how (should) the condition/restart association
might be implemented -- is some kind of alist structure held by a
special variable what was intended, or ought the condition have a
restarts slot? ... it's pretty obvious that the relation should be externally
represented. It's important that the association not be done by a slot
in the condition because if you carry around the condition object after
you're done signalling, you don't want it to contain useless and/or
misleading information about restarts that no longer exist."
"... syntax to SIGNAL-WITH-RESTARTS and
ERROR-WITH-RESTARTS should be:
SIGNAL-WITH-RESTARTS signal-argument-list &rest restart-clauses
ERROR-WITH-RESTARTS signal-argument-list &rest restart-clauses
so that you would write
(SIGNAL-WITH-RESTARTS ('FOOD-COLOR-ERROR :FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
rather than
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
If you wanted to use MAKE-CONDITION, you would then write:
(SIGNAL-WITH-RESTARTS ((MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK))
...restart clauses...)
The advantage of what he proposes is that you could write
(SIGNAL-WITH-RESTARTS ("Bad ~S color" 'FOOD)
...restart clauses...)
and a condition object would be created implicitly as with SIGNAL. A
possible disadvantage is that
(SIGNAL-WITH-RESTARTS (FOO BAR BAZ)
...restart clauses...)
might look to someone like the FOO in (FOO BAR BAZ) named a function
rather than a variable. "
"... even better would be
(WITH-CONDITION-RESTARTS signal-form &rest restart-clauses)
where signal-form must be an invocation of SIGNAL, ERROR, WARN, or
perhaps a few others, or a macro that expands into such an invocation.
WITH-CONDITION-RESTARTS must signal an error at all levels of safety if
it does not recognize the signal-form. This is "weird" because it uses
a form for something other than evaluation (but not unprecedented; this
is exactly what SETF does). The advantage is that it just nests with an
existing syntax instead of inventing a new, awkward syntax.
Note that I stole the "good name" WITH-CONDITION-RESTARTS for this
commonly used syntax. The less commonly used primitive that just sets
up the restarts without signalling doesn't need as good a name."
"... the syntax for WITH-CONDITION-RESTARTS should be
WITH-CONDITION-RESTARTS condition-form restarts-form &BODY forms
rather than
WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
which it is now. Does anyone else have an opinion?
This is probably a good idea. I'd probably name this one
WITH-CONDITION-RESTARTS-INTERNAL. But are we sure that this operation
needs to be named in the standard
"
∂16-Mar-89 1117 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:16:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558656; Thu 16-Mar-89 14:13:55 EST
Date: Thu, 16 Mar 89 14:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: Aaron Larson <alarson@src.honeywell.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903160338.AA16529@pavo.src.honeywell.com>
Message-ID: <19890316191343.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 21:38:06 CST
From: alarson@src.honeywell.com (Aaron Larson)
If we permit the compiler to signal warnings for functions where the
compile-time environment signature is different from the function call
being compiled, why do we prohibit it for generic functions?
I would say that what CLOS-MACRO-COMPILATION (which I have not reviewed yet)
is clearly incorrect. Perhaps CLOS-MACRO-COMPILATION was trying only to rule
out signalling an error for a lack of lambda-list congruency between
compile-time and run-time, but went overboard and ruled out warnings
as well. I think warnings in this circumstance can be desirable, but
errors are certainly wrong.
∂16-Mar-89 1146 X3J13-mailer Issue ERROR TERMINOLOGY, dpANS C
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:44:03 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 14:40:15 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 14:41:04 EST
Received: by verdi.think.com; Thu, 16 Mar 89 14:37:31 EST
Date: Thu, 16 Mar 89 14:37:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161937.AA05048@verdi.think.com>
To: barmar@Think.COM
Cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, cperdue@sun.com,
@decwrl.dec.com:chapman@aitg.dec, @sun.com:kempf@clam,
@sun.com:peck@clam, @sun.com:sgadol@clam, x3j13@sail.stanford.edu,
cl-editorial@sail.stanford.edu, @sail.stanford.edu:rpg@lucid.com
In-Reply-To: Barry Margolin's message of Wed, 15 Mar 89 19:28 EST <19890316002837.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue ERROR TERMINOLOGY, dpANS C
Date: Wed, 15 Mar 89 19:28 EST
From: Barry Margolin <barmar@Think.COM>
A while back I proposed (to the Editorial committee) a definition of
"harmless" that I still like: Equivalent to an arbitrary conforming
program ...
Yes, this definition allows such situations to result in playing chess,
and if the computer is controlling a bomb silo it could also result in
starting World War III. I don't think a general definition of
"unspecified" can possibly disallow these things. We might want to
rethink the applicability of the word "harmless" in this case....
How about renaming "harmless" to be "arbitrary"?
--Guy
∂16-Mar-89 1205 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:03:57 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 14:41:11 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 14:42:22 EST
Received: by verdi.think.com; Thu, 16 Mar 89 14:39:11 EST
Date: Thu, 16 Mar 89 14:39:11 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161939.AA05061@verdi.think.com>
To: barmar@Think.COM
Cc: masinter.pa@xerox.com, x3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Thu, 16 Mar 89 12:16 EST <19890316171639.5.BARMAR@OCCAM.THINK.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
Date: Thu, 16 Mar 89 12:16 EST
From: Barry Margolin <barmar@Think.COM>
Date: 16 Mar 89 07:07 PST
From: masinter.pa@xerox.com
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Just to show you, when I become a billionaire I'll form my own country
and give it an irrational time zone (e in the winter, sqrt(2) in the
summer).
Seriously, is there any particular reason not to allow any non-complex
number as a time zone?
barmar
When you become a billionaire, you'll probably find that
you get a better approximation to e or sqrt(2) with a moby
bignum rational than with a float.
--Quux
∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-PRINT-NAME, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 11:42:46 PST
Date: 16 Mar 89 11:29 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COPY-SYMBOL-PRINT-NAME, v.2
to: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-114246-4951@Xerox>
!
Issue: COPY-SYMBOL-PRINT-NAME
References: COPY-SYMBOL (p. 169)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
15-MAR-89, Version 2 by Chapman
Problem Description:
The description of COPY-SYMBOL states that it "returns a new uninterned
symbol with the same print name as sym (its first argument)". The words
"the same as" are not defined in CLtL. Do they mean EQ, EQUAL, ...?
Proposal (COPY-SYMBOL-PRINT-NAME:EQUAL)
The description of COPY-SYMBOL should read as follows:
"COPY-SYMBOL returns an uninterned
symbol whose print name is STRING= to
the print name of the symbol that is the first argument to COPY-SYMBOL."
Suggested implementation note:
The string should not be copied unnecessarily. In this case, the uninterned
symbol's print name would be EQ to the print name of the argument symbol.
Rationale:
This clarification resolves any possibility of ambiguity.
Current Practice:
Medley did this: the symbol names didn't really have a string header and
some symbol names (the "initial symbols" ) had a different place for
storing the actual characters than symbols created later. Unfortunately,
that means that SYMBOL-NAME has to CONS.
It wasn't so much a problem for Interlisp since most of the "string"
functions in Interlisp will take symbols, but in Common Lisp, it is a
performance hit. Poor design, but there's no reason to require SYMBOL-NAME
to return EQ strings.
In this case, the strings aren't EQ even though the string characters are
shared. (Think of it as strings displaced to a shared area.)
Adoption Cost:
?
Benefits:
Less ambiguity in the specification, and potentially more portable code.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-COPY-PLIST, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 11:27:49 PST
Date: 16 Mar 89 11:27 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COPY-SYMBOL-COPY-PLIST, v.1
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-112749-4871@Xerox>
The only discussion on this issue was whether it was necessary
to clarify (some thought it was) and whether a more general
"copy the list means COPY-LIST" was necessary (probably not.)
There was no controversy on the proposal itself.
!
Issue: COPY-SYMBOL-COPY-PLIST
References: COPY-SYMBOL (p 169), COPY-LIST (p 268), COPY-TREE (p
269).
Category: CLARIFICATION
Edit history: 10-Jan-89, Version 1 by Margolin
Problem Description:
The description of COPY-SYMBOL, where the COPY-PROPS optional argument
is non-NIL, says that a copy of the property list is used as the new
symbol's property list. However, there are several ways in which a list
may be copied, most notably COPY-LIST and COPY-TREE, and the description
doesn't say which mechanism should be used.
Proposal (COPY-SYMBOL-COPY-PLIST:COPY-LIST)
Clarify that when COPY-SYMBOL copies the property list of the symbol, it
is as if (COPY-LIST (SYMBOL-PLIST sym)) were used as the new symbol's
property list.
Rationale:
COPY-LIST is the simplest list-copying primitive. The result of this
copy is that GET returns EQL results for the two symbols until one of
the property lists is altered, but altering either of the property lists
doesn't affect the other. This is current practice in the
implementations I tested, and probably what most users assume.
Current Practice:
Symbolics Genera and Sun Common Lisp currently implement this. I
suspect most others do, too.
Cost to Implementors:
Little or none.
Cost to Users:
None unless they've been assuming some other type of copy.
Benefits:
Less ambiguity.
Aesthetics:
Well, I like it.
∂16-Mar-89 1213 X3J13-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 12:00:57 PST
Date: 16 Mar 89 11:59 PST
From: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-120057-5042@Xerox>
I think this is one of the more important issues to consider,
in that it is addresses one of the most frequently noted
performance issues in Common Lisp. We've examined a large number
of proposals and alternatives to allow declaration of dynamic extent
in Common Lisp.
!
Forum: CLEANUP
Issue: DYNAMIC-EXTENT
References: Scope and Extent
Category: ADDITION
Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
11-Jan-89, Version 3 by Masinter (Moon's proposal)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Problem Description:
Sometimes a programmer knows that a particular data structure
will have only dynamic extent. In some implementations, it is
possible to allocate such structures in a way that will make them
easier to reclaim than by general purpose garbage collection
(eg, on the stack or in some temporary area). Currently, however,
there is no way to request the use of such an allocation mechanism.
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
this declaration are names of variables. The declaration asserts that
the value which is initially held by the indicated variable will have
dynamic extent. [In the case of an iteration variable, the declaration
asserts that on every iteration, the initial value of that variable
for the iteration will have dynamic extent.]
It is permissible for an implementation to simply ignore this declaration.
In implementations which do not ignore it, the compiler (or interpreter)
is free to make whatever optimizations are appropriate given this
information; the most common optimization is to stack-allocate the
initial value of the object. What data types (if any) can have dynamic
extent will can vary from implementation to implementation.
Since stack allocation of the initial value entails knowing at the
object's creation time that the object can be stack-allocated, it is
not generally useful to declare DYNAMIC-EXTENT for variables for
which have no lexically apparent initial value. For example,
(DEFUN F ()
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
...))
would permit those compilers which wish to do so to stack-allocate the
list in X. However,
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
could not typically permit a similar optimization in G because it would
be a modularity violation for the compiler to assume facts about G from
within F. Only an implementation which was willing to be responsible for
recompiling F if G's definition changed incompatibly could stack-allocate
the list argument to G in F.
Other interesting cases are:
(PROCLAIM '(INLINE G))
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
and (DEFUN F ()
(FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
(G (LIST 1 2 3))))
where some compilers might realize the optimization was possible and others
might not.
An interesting variant of this is the so-called `stack allocated rest list'
which can be achieved (in implementations supporting the optimization) by:
(DEFUN F (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
...)
Note here that although the initial value of X is not explicit, the F
function is responsible for assembling the list X from the passed arguments,
so the F function can be optimized by the compiler to construct a
stack-allocated list instead of a heap-allocated list in implementations
which support such.
The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable. To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears. An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW. A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
Examples:
In
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses. None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y. However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."
- - - - - - - -
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
This is particularly instructive. Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the "proper parts" of I, which this declaration
requires the body of the DOTIMES not to "save"? If the value of I is 3,
and the body does (SETQ FOO 3), is that an error? The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers. In an implementation where EQ and EQL are
equivalent for 3, then 3 is not a "proper part" because (EQ I (+ 2 1))
is true, and therefore there is another way to access the object besides
going through I. On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is a "proper part", but any other 3 is not. Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous. Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.
- - - - - - - -
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
(PRINT X)
NIL)
PRINT does not "save" any part of its input.
This prints (1 2 3)
- - - - - - - -
(DO ((L (LIST-ALL-PACKAGES) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRINT (CAR L)))
prints all packages; none of the newly-allocated list structures are saved.
- - - - - - - -
(DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
(ADD 1 2 3) => 6
I.e., useful way to declare that &REST lists have dynamic extent
- - - - - - - -
(DEFUN ZAP (X Y Z)
(DO ((L (LIST X Y Z) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRIN1 (CAR L))))
(ZAP 1 2 3)
prints 123
- - - - - - - -
(DEFUN ZAP (N M)
;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
;; It may be slow, but with a good compiler at least it
;; doesn't waste much heap storage. :-)
(LET ((A (MAKE-ARRAY N)))
(DECLARE (DYNAMIC-EXTENT A))
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
(SETF (AREF A I) (RANDOM (+ I 1))))
(AREF A M)))
(< (ZAP 5 3) 3) => T
- - - - - - - -
The following are in error, since the value of X is used outside of its
extent:
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
(PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
NIL)
- - - - - - - -
Rationale:
This permits a programmer to offer advice to an implementation about
what may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Since a number of implementations offer this capability and there
is demand from users for access to the capability, this ``codifies
existing practice.''
Because this approach is purely lexical, it does not interact badly with
other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
by same name) would.
Current Practice:
Symbolics Genera and Symbolics Cloe offer stack allocation, though not
in this strategy.
[KMP thinks that] Lucid supports the proposal.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
A previous version of this proposal suggested primitives STACK-LET
and STACK-LET*. Consensus was that the more general declaration facility
would be more popular.
Pitman supports the DYNAMIC-EXTENT:NEW-DECLARATION.
Actually, a blurry issue is whether
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
=> 1
is well-defined. I refer to these stack-allocated things as being invalid
return values, but in fact we might want to say that they're ok to return
but that you just can't do any serious operations on them (ie, you can't
expect them to still be lists, etc.) Can anyone imagine a pointer into
unallocated stack causing problems for their GC? If so, we could be more
clear on this point.
The examples are tricky:
"I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works."
!
Additional comments:
... I really like this rewrite a lot. It's quite
clever in the way it presents things in order to get additional flexibility.
However, I do have a few comments I'd like to see addressed before this
gets to a vote...
* I like the concept "proper part" a lot but I don't like the name.
The term "proper" for proper lists has to do with well-formed-ness
and in this context you're suggesting an incompatible meaning which
is confusing.
I suggest instead a term like "internal", "intrinsic", "private",
"unshared", etc.
[The concept of "unshared" makes me immediately scared about the
whole quote-may-copy morass, but I don't have time to think through
right now whether that's an issue that needs further clarification
or if it's just a red herring.]
* I like the concept of "saved" but it has the problem that it isn't
easy to bring up "out of context" since "save" has a lot of connotations.
If it were possible to come up with a more unique term, I think it
would help in lunch table conversations when people start getting
screwed by things that were `unintentionally saved' and others can't
figure out what they mean out of context.
* I think your list of definitions for saved is pretty good, but I'd
still like to see an abstract definition, and then the concrete cases
listed beneath it. That way, we are protected from weird unintentional
interpretations if someone discovers that the set was not exhaustive
and needs to include their new case under the abstract description
because the concrete list doesn't accomodate things.
* What about things like:
(DEFUN FOO (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
(MAPL #'PRINT X)
T)
Genera's Dynamic Windows (DW) had bugs in its first release because the
window history recorded the object which was printed. Put another
way, PRINT did unexpected "saving" on some streams. The situation with
DW was treated as a bug and now DW correctly detects stack-allocated
things and does not try to save them, so this would work now.
However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
- - - - - - -
re: However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
PDP10 MacLisp had a similar problem w.r.t pdlnums. That is why
"identity" functions were so troublsome for it -- in order to
return a guaranteed safe value, it typically had to copy it's
pdlnum argument, thereby making some cases of "fast arithmetic"
code much worse than interpreted code! [Remember PRINT in MacLisp?
it returns T rather than it's argument for just this reason.]
It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal? "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database. But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.
∂16-Mar-89 1212 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 11:49:11 PST
Date: 16 Mar 89 11:46 PST
From: masinter.pa@Xerox.COM
Subject: *DRAFT* Issue: DESTRUCTURING-BIND, v.2
to: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-114911-4982@Xerox>
This issue is draft; there will hopefully be a new version before
the meeting.
The discussion centers around what lambda-list keywords should be
allowed.
&ENVIRONMENT:
everybody says disallow
&WHOLE:
Moon said allow (the second time.)
NIL:
Moon says allow as a way of ignoring.
KMP says OK, maybe in other places too.
Discussion of IGNORE led to new issue.
&BODY:
KMP makes case for disallowing, but says
allow.
There was some additional discussion that resulted in the
related issues of DEFMACRO-LAMBDA-LIST and IGNORE-VARIABLE.
I'd be happy with a proposal that said NIL is ignored,
&WHOLE and &BODY are allowed, and that &ENVIRONMENT
is disallowed. I'd like to make sure it was consistent
with LOOP.
!
Issue: DESTRUCTURING-BIND
Forum: Cleanup
References: DEFMACRO (CLtL pp145-151),
The LOOP Facility (X3J13/89-004)
Category: ADDITION
Edit history: 24-Jan-89, Version 1 by Pitman
25-Jan-89, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
Common Lisp programmers have frequently complained that the
destructuring facility used by DEFMACRO is not made available
for use in ordinary programming situations involving list data.
The presence of a destructuring facility in the recently adopted
LOOP facility will be likely to make the absence of a separable
destructuring facility all the more apparent.
Prior to the introduction of LET into Maclisp, many people wrote
their own LET macros. A popular expansion was in terms of a DO
which did not iterate. eg,
(LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
While this practice `worked,' it was not perspicuous and contributed
substantially to non-readability: not only were the macros hard to
understand, but the surface interface itself was not standardized
and varied in subtle ways. For example, some LET macros allowed GO
statements while others did not.
There is now considerable danger that a lot of people will write
DESTRUCTURING-BIND variants in terms of a LOOP expression that
immediately returns.
(DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
Since the destructuring offered by LOOP is different in subtle ways
from the destructuring offered by DESTRUCTURING-BIND in implementations
offering that primitive natively, gratuitous headaches could result.
Proposal (DESTRUCTURING-BIND:NEW-MACRO):
Provide a macro called DESTRUCTURING-BIND which behaves like the
destructuring bind in DEFMACRO. Specifically...
DESTRUCTURING-BIND lambda-list expression {decl|doc}* {form}* [Macro]
Binds the variables specified in LAMBDA-LIST to the corresponding
values in the tree structure resulting from evaluating EXPRESSION,
then evaluates the FORMS in the body.
Anywhere in the LAMBDA-LIST where a parameter name may appear, and
where ordinary lambda-list syntax (as described in CLtL section 5.2.2)
does not otherwise allow a list, a lambda-list may appear in place of
the parameter name. When this is done, then the argument form that
would match the parameter is treated as a (possibly dotted) list, to
be used as an argument forms list for satisfying the parameters in
the embedded lambda-list.
If any of the lambda list keywords &OPTIONAL, &REST, &KEY,
&ALLOW-OTHER-KEYS and &AUX appears in the lambda list, it is treated
as with any other lambda-list.
If the lambda list keyword &BODY appears, it is treated as a synonym
for &REST.
If the lambda list keyword &WHOLE appears, it must be followed by a
single variable that is bound to the entire expression at the current
level. &WHOLE and the following variable should appear first in the
list, before any other parameter or lambda-list keyword.
It is also permissible for any level of the LAMBDA-LIST to be dotted,
ending in a parameter name. This situation is treaed exactly as if
the aprameter name that ends the list had appeared preceded by &REST
in a proper list. For example, the notation (X Y . Z) is equivalent
to (X Y &REST Z).
If the result of evaluating the expression does not match the
destructuring pattern, the consequences are undefined. Implementations
are not required to signal an error in this case, but neither are they
permitted to extend the behavior by defining it to be harmless.
Clarify that the destructuring done by LOOP does not permit the use of
any lambda-list-keywords. Further clarify that in LOOP, proper lists
are implicitly `&REST var' (where the non-use of var is quietly ignored).
Hence, it is permissible to have:
(LOOP FOR (X Y) ON '(A B C D) COLLECT (CONS X Y)) => ((A . B) (C . D))
but it is not permissible to have:
(DESTRUCTURING-BIND (X Y) '(A B C D) (CONS X Y))
since the pattern does not match. One must instead write:
(DESTRUCTURING-BIND (X Y &REST Z) '(A B C D)
(DECLARE (IGNORE Z))
(CONS X Y))
Test Case:
(DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper
(DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
`((ALPHA) ,@(IOTA 3))
(LIST A B THREE TWO ONE))
=> (ALPHA BEE 3 2 1)
Rationale:
The proposal directly addresses the stated problem, and is current practice
in numerous implementations. Our charter effectively dictates that where
feasible we should try to head off the widespread development of uselessly
different variants of commonplace tools.
Current Practice:
Symbolics Genera, Envos Medley, TI Explorer, and Lucid CL all offer
DESTRUCTURING-BIND, though the details vary slightly.
The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
the pattern is not matched. The TI Explorer version does not.
Cost to Implementors:
Very small. In most cases, it's a matter of renaming and/or exporting an
already existing symbol. In a few cases, a very small amount of
`program interface' code would have to be written.
Cost to Users:
None. This is an upward compatible change.
Cost of Non-Adoption:
Loss of the Benefits and Aesthetics cited below.
Benefits:
Users will get a powerful feature they have asked for on many occassions.
In implementations which `autoload' code, it would be better for this
support to be separable so that people could do DESTRUCTURING-BIND
without demand loading all other LOOP support.
Aesthetics:
Defining this macro centrally for the Common Lisp community will reduce
subtle deviations, which will in turn have positive aesthetic impact.
Discussion:
JonL observes that although LOOP does destructuring, it can't directly
make use of the DESTRUCTURING-BIND interface suggested here.
Pitman and Gray think a facility of this sort is a good idea, though
obviously the details may still need a little fleshing out before the
proposal is ready for vote.
To date, the excuse for not satisfying this request has been a
religious war between factions who want to destructure lists by
writing
(DESTRUCTURING-BIND (var1 var2 var3) exp . body)
and those who want to destructure lists by writing
(DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)
The advantage of the former approach is that it is notationally
concise for the common case of destructuring a list. The disadvantage
is that it is not extensible to accomodate abstract kinds of
destructuring.
The advantage of the latter approach is that it allows interesting
extensions that accomodate data-hiding, such as:
(DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
(DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
and later the ability to change the representation of a FOO without
updating the associated binding forms. The disadvantage is that it
is more verbose in the common case of destructuring a list, and still
even more verbose for nested lists.
Although destructuring has always existed in DEFMACRO, this has not
been adequate precedence for deciding the outcome of the religious war
because DEFMACRO only needs to destructure programs, and programs are
generally made up only of lists -- not arbitrary user-defined abstract
data types.
∂16-Mar-89 1221 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:20:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558750; Thu 16-Mar-89 15:18:32 EST
Date: Thu, 16 Mar 89 15:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DESCRIBE-UNDERSPECIFIED, v.1
To: masinter.pa@Xerox.COM, Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <890316-082029-3881@Xerox>
Message-ID: <19890316201824.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I think this is unnecessary, but I do not strongly oppose it.
The proposed division of labor between the DESCRIBE function and
the DESCRIBE-OBEJCT generic function could be implemented by
an :AROUND method for the existing DESCRIBE generic function.
The claim that binding *STANDARD-OUTPUT* is dangerous in the
presence of interrupts is false, since many things bind
*STANDARD-OUTPUT* and any reasonable interactive interrupt
handler must rebind the standard streams, the print control
variables, etc.
I don't strongly oppose this since it might be worthwhile just
for the symmetry with the PRINT-OBJECT generic function.
∂16-Mar-89 1241 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:41:00 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 15:36:50 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 15:38:04 EST
Received: by verdi.think.com; Thu, 16 Mar 89 15:34:53 EST
Date: Thu, 16 Mar 89 15:34:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903162034.AA05881@verdi.think.com>
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 16 Mar 89 11:59 PST <890316-120057-5042@Xerox>
Subject: Issue DYNAMIC-EXTENT: a remark
This is the last paragraph of the proposal DYNAMIC-EXTENT:NEW-DECLARATION:
The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable. To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears. An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW. A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
I believe that the words indicated above should be replaced by
"the extent of the binding for which the delaration was made".
The reference appears to be to a point in time. Scopes are in space;
the beginning of a scope is a character position in the text (or
something like that). Extents are in time. Is this what you meant?
--Conan the Pedantrian (a.k.a. Guy)
∂16-Mar-89 1436 X3J13-mailer Fatal vesus Harmless
To: x3j13@SAIL.Stanford.EDU
CC: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
This is my last attempt at making my argument. I don't think there is much
else I can say to persuade you.
I wrote:
``The definition of fatal puts no time constraints on the fatality. Therefore,
neither does its negation.''
Let's define the term ``win'' to mean ``doesn't crash or abnormally
terminate''; basically, it is the bad case that the definition of
``fatal'' talks about. Let ``lose'' mean ``not win.''
Here are two partially formal definitions of ``fatal'' and ``harmless.''
The program P has consequences that are fatal if there
exists a sequence of conforming programs, P1,...,Pj,Pj+1,...,Pn, where
(progn P1...Pn) wins, but (progn P1...Pj P Pj+1...Pn) loses.
That is, the execution of P eventually leads to fatality in some program.
The program P has consequences that are harmless if
for all sequences of conforming programs, P1,...,Pj,Pj+1,...,Pn, where
(progn P1...Pn) wins, (progn P1...Pj P Pj+1...Pn) also wins.
That is, the execution of P never leads to fatality in any program.
There might be an infinite amount of hair to make this precise, but that's
the idea. And, there is some question about how different we allow the
behavior of the programs with P to be from the behavior of the programs
without P. (The language of the definitions of these terms are meant to
warn people to beware that behavior is in jeopardy.) But, the terms are
related by a negation with respect to the degree to which they are
well-defined.
I think part of the problem of understanding comes from the question of
side effects noticeable to conforming programs. A program with harmless
consequences can have side effects; notice our partly formal definition
doesn't say anything about what the programs do.
We all believe harmless a garbage collector that moves objects from place
to place where the movement is unnoticeable by conforming programs. Probably
most of us believe harmless a garbage collector whose progress is displayed.
I think none of us believes harmless a garbage collector that sets to
NIL all property lists of symbols in the USER package.
I think most of use believe harmful a garbage collector that changes the
order of properties on property lists.
However, consider an implementation of Common Lisp that uses a very hairy
representation for property-list lists. These lists have the feature that
sometimes the garbage collector will re-order their properties according
to some LRU bits to aid performance. Of course, through extreme hair, the
GC won't change the order if some piece of the property list is stored
somewhere other than the property list itself. Think of it as an
optimization that is conservatively performed.
Nowhere does the CL specification state that the order of properties
remains constant if the property list is not explicitly altered. Do those
of us who believed harmful the GC that changed property list order believe
this GC harmful? Or did some of us change our votes?
Suppose we alter the definition of symbol-plist from this:
``This returns *the* list the contains the property pairs of <symbol>;
the contents of the property-list cell are *extracted* and returned.''
to this:
``This returns *a* list the contains the property pairs of <symbol>;
the contents of the property-list cell are *copied* and returned.''
Now does the order-changing GC seem more harmless? It certainly has
less transparent behavior.
Suppose we explicitly specified that the order of properties on a property
list could change from time to time, possibly by GC actions. We have
defined the GC to be non-transparent, but is it harmless?
The sense of the definitions come from the partially formal definitions.
I think these definitions are pesuasive regarding the usefulness of a
term like ``harmless.''
I believe those definitions are difficult to make formal without some
very detailed computational or semantic model. The series of strange
GC behaviors with respect to property lists should make us leery of
making these definitions too precise at the expense of deciding these
cases one way when in five years we will wish we could decide them
the other way.
Specifications such as the one we are writing are communications
among people, and therefore absolute precision is impossible without
overspecification.
-rpg-
∂16-Mar-89 1418 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:18:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558915; Thu 16-Mar-89 17:15:26 EST
Date: Thu, 16 Mar 89 17:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DYNAMIC-EXTENT: a remark
To: Guy Steele <gls@Think.COM>
cc: masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: <8903162034.AA05881@verdi.think.com>
Message-ID: <19890316221519.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 15:34:53 EST
From: Guy Steele <gls@Think.COM>
A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
I believe that the words indicated above should be replaced by
"the extent of the binding for which the delaration was made".
That would change the meaning, since the declaration might not be attached
to a binding.
The reference appears to be to a point in time. Scopes are in space;
the beginning of a scope is a character position in the text (or
something like that). Extents are in time. Is this what you meant?
You're right that there is something wrong with this wording. How about
if it said "at the beginning of execution of the forms in the scope of
the declaration"? Do declarations have extents? If so, could it say
"at the beginning of the extent of the declaration"?
∂16-Mar-89 1424 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:23:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558923; Thu 16-Mar-89 17:20:36 EST
Date: Thu, 16 Mar 89 17:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
To: barmar@Think.COM
cc: Guy Steele <gls@Think.COM>, masinter.pa@xerox.com, x3J13@sail.stanford.edu
In-Reply-To: <8903161939.AA05061@verdi.think.com>
Message-ID: <19890316222034.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 14:39:11 EST
From: Guy Steele <gls@Think.COM>
Date: Thu, 16 Mar 89 12:16 EST
From: Barry Margolin <barmar@Think.COM>
Date: 16 Mar 89 07:07 PST
From: masinter.pa@xerox.com
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Just to show you, when I become a billionaire I'll form my own country
and give it an irrational time zone (e in the winter, sqrt(2) in the
summer).
When you become a billionaire, you'll probably find that
you get a better approximation to e or sqrt(2) with a moby
bignum rational than with a float.
As a billionaire, you'll be able to afford to do all your processing
with indefinite-precision exact arithmetic.
Does Guy have inside information on when Barry will become a billionaire?
∂16-Mar-89 1443 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:43:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558959; Thu 16-Mar-89 17:39:16 EST
Date: Thu, 16 Mar 89 17:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
cc: masinter.pa@xerox.com, cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <19890316173142.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890316223916.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
I'll just reiterate something I said at one of the meetings. One
portable use I can think of for the COMPILED-FUNCTION type is as a
declaration to allow compiler optimization. If a function knows (or
requires) that a parameter is a compiled function it can declare that
and the implementation may be able to optimize the FUNCALL better.
But as someone said the last time this suggestion was brought up, if
there is no portable meaning of the COMPILED-FUNCTION type and no
portable way to create an object of that type, no useful correct program
can contain this declaration.
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures
You just glimpsed the tip of the iceberg.
∂16-Mar-89 1354 X3J13-mailer Issue: DYNAMIC-EXTENT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:54:21 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 16:49:45 EST
Date: Thu, 16 Mar 89 16:50 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: DYNAMIC-EXTENT
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu
In-Reply-To: <890316-120057-5042@Xerox>
Message-Id: <19890316215008.1.BARMAR@OCCAM.THINK.COM>
re: However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
...
It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal? "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database. But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.
I don't think that solves the problem. Yes, in a system where PRINT
saves its argument the compiler could detect that in
(defun print-em (&rest stuff)
(declare (dynamic-extent stuff))
(print stuff))
the declaration is obviously in error and may be ignored (or it might
generate a warning). In the case of Genera Dynamic Windows, whether
PRINT saves is actually an attribute of the stream, so it is
questionable whether the compiler should override the declaration
(perhaps the programmer knows that the function will only be called with
*STANDARD-OUTPUT* bound to a non-saving stream). Also, what about the
function
(defun process-em (&rest stuff)
(declare (dynamic-extent stuff))
(frobnicate stuff))
If FROBNICATE hasn't been written yet the compiler has no way of
knowing whether it calls any system functions that save the argument.
I think that if we really want this declaration (and I'd like to see it
included, as it is the right compromise for a long-standing problem) we
MUST say something about passing dynamic data to standard functions. I
think it would be sufficient to say that if the standard doesn't specify
that an argument must be saved then a dynamic object must be acceptable.
In other words, if a user reading the standard can't infer that an
argument will be saved then a conforming program may pass dynamic data
in that argument. This means that PRINT must accept a dynamic object,
and it is the implementation's responsibility to solve the potential
problems if it normally saves what PRINT prints.
barmar
∂16-Mar-89 1356 CL-Compiler-mailer Issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:56:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558883; Thu 16-Mar-89 16:53:42 EST
Date: Thu, 16 Mar 89 16:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SAFE-CODE, version 1
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, masinter.pa@Xerox.COM
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
In-Reply-To: <svXEG@SAIL.Stanford.EDU>,
<890316-070317-3708@Xerox>,
<1avs40@SAIL.Stanford.EDU>,
<19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890316215335.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Either "nonsafe code" or "code not declared safe" has better connotations
for me than "unsafe code." I don't really want to get too deeply involved
in choosing the terminology here (if I did, I would be on the editorial
committee), I only wanted to point out that the word used in version 1
of the proposal had an unwanted connotation for me.
∂16-Mar-89 1551 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 15:51:26 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 17:59:11 EST
Date: Thu, 16 Mar 89 18:00 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: masinter.pa@xerox.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: <890316-095901-4371@Xerox>
Message-Id: <19890316230020.6.BARMAR@OCCAM.THINK.COM>
There's an inconsistency in the names of the proposals. In the Proposal
sections, the two proposals are named LIMITED-ARBITRARY-EXTENSION and
DEPRECATE. But in some other sections they are called COERCE and
DEPRECATE.
Problem with DEPRECATE: Didn't we specify that the way to convert a
lambda expression into a function object is to use (COERCE x 'FUNCTION)?
Or did we also define a new function that does this?
barmar
∂16-Mar-89 1603 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 16:02:40 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 17:45:15 EST
Date: Thu, 16 Mar 89 17:46 EST
From: Barry Margolin <barmar@Think.COM>
Subject: *DRAFT* Issue: DESTRUCTURING-BIND, v.2
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu
In-Reply-To: <890316-114911-4982@Xerox>
Message-Id: <19890316224608.4.BARMAR@OCCAM.THINK.COM>
Date: 16 Mar 89 11:46 PST
From: masinter.pa@xerox.com
Current Practice:
The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
the pattern is not matched. The TI Explorer version does not.
Actually, Genera offers TWO versions of DESTRUCTURING-BIND:
SYMBOLICS-COMMON-LISP:DESTRUCTURING-BIND and
ZETALISP:DESTRUCTURING-BIND. The former signals an error, while the
latter does not (it's probably very similar to the Explorer version,
since they are genetically closer).
barmar
∂16-Mar-89 1726 X3J13-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 17:25:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 16:55:22 PST
Date: 16 Mar 89 16:49 PST
From: masinter.pa@Xerox.COM
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)
to: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-165522-6151@Xerox>
The discussion on this issue pointed out that it would
extend the range of MAKE-STRING so that it was no
longer restricted to return a SIMPLE-STRING, which
might break some type-inference.
!
Issue: MAKE-STRING-FILL-POINTER
References: CLtL p.302
Related issues: none that I know of
Category: ADDITION
Edit history: Version 1, 20-Oct-88, by Moon, for discussion
Problem description:
Once again I lost because I expected to be able to use MAKE-STRING
to create a string with a fill-pointer, and I couldn't. I had to use
a more long-winded MAKE-ARRAY call instead.
Proposal (MAKE-STRING-FILL-POINTER:ALLOW):
Give MAKE-STRING a :FILL-POINTER argument, with the same syntax and
semantics as the :FILL-POINTER argument to MAKE-ARRAY.
Examples:
(make-string 80 :fill-pointer 0)
Test Cases:
See examples.
Rationale:
I frequently expect it to be allowed and am surprised when it's not.
Current practice:
I know of no implementations that support this.
Cost to Implementors:
5 cents.
Cost to Users:
none
Cost of non-adoption:
none
Performance impact:
none
Benefits:
Increased language consistency.
Esthetics:
Increased language consistency.
Discussion:
Other MAKE-ARRAY options that one might want to allow, but are
not already allowed or proposed, are :INITIAL-CONTENTS, :ADJUSTABLE,
:DISPLACED-TO, and :DISPLACED-INDEX-OFFSET. A strong case could be
made for :ADJUSTABLE (I use an implementation where it doesn't matter,
so I don't care about that), I don't think anyone would care about the
other three.
∂16-Mar-89 1746 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 17:45:59 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559088; Thu 16-Mar-89 19:18:34 EST
Date: Thu, 16 Mar 89 19:18 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: barmar@Think.COM
cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <19890316230020.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <890316191820.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 18:00 EST
From: Barry Margolin <barmar@Think.COM>
...
Problem with DEPRECATE: Didn't we specify that the way to convert a
lambda expression into a function object is to use (COERCE x 'FUNCTION)?
Or did we also define a new function that does this?
Re-read FUNCTION-TYPE. The thing Beckerle really wanted and finally
got (over my objection) was that COERCE did nothing `hard' ... What
it ended up being able to be do can be expressed by #'IDENTITY and
#'SYMBOL-FUNCTION.
(COERCE x 'FUNCTION) ==
(ETYPECASE X
(SYMBOL (SYMBOL-VALUE X))
(FUNCTION X))
I don't really think anything more needs to be provided, even if we
DEPRECATE coerce.
∂16-Mar-89 1745 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 17:45:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA18011; Thu, 16 Mar 89 00:34:36 PST
Message-Id: <8903160834.AA18011@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA18011; Thu, 16 Mar 89 00:34:36 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 Mar 89 03:24
To: x3j13@sail.stanford.edu
Subject: Issue: EXTRA-RETURN-VALUES
Issue: EXTRA-RETURN-VALUES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
10-MAR-89, Version 3 by Chapman
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
A function that is specified by the standard must return EXACTLY the number
of return values specified by the standard.
Rationale:
The reason is that
additional arguments are visible to otherwise portable programs. For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value.
Current Practice:
At least one implementation returns extra values for certain functions
not currently specified to return those values.
Adoption Cost:
Implementations and their associated documentation that now contain
functions that return extra values will have to change.
Benefits:
Programs will potentially become more portable.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂16-Mar-89 1801 X3J13-mailer SYMBOL-MACROLET-SEMANTICS, version 6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 18:01:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 17:46:06 PST
Date: 16 Mar 89 17:44 PST
From: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: SYMBOL-MACROLET-SEMANTICS, version 6
line-fold: NO
Message-ID: <890316-174606-6317@Xerox>
This is a proposal to amend version 5, passed in January 1989 in Kauai.
Version 6 amends version 5 to require PSETQ to behave like PSETF,
to require MULTIPLE-VALUE-SETQ to accept symbol macros (but not
general SETF places), and to specify the interaction with the
*MACROEXPAND-HOOK* function.
We would like to have the proposal reconsidered, and
accepted as amended.
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
14-Mar-89, Version 6 by Steele
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
In addition, it would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
as well as DECLARE within SYMBOL-MACROLET forms.
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Furthermore PSETQ of a symbol defined as a symbol macro will
behave as if it were a PSETF, and MULTIPLE-VALUE-SETQ will behave
as if SETQ were used on each variable to be set.
When MACROEXPAND or MACROEXPAND-1 sees a symbol macro, it calls
the value of *MACROEXPAND-HOOK* in the same manner as for an
ordinary macro. The three values given to the hook function
in this case will be an expansion function, a form (in this case
the symbol naming the symbol macro), and an environment. The
only guaranteed property of the expansion function is that when
it is applied to the form and the environment it will return the
correct expansion of the symbol macro. (In particular, nothing
it said in this specification whether the expansion is conceptually
stored in the expansion function, the environment, or both.)
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
∂16-Mar-89 2103 X3J13-mailer Issue: EXIT-EXTENT, v.6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 21:03:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 21:00:49 PST
Date: 16 Mar 89 20:52 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT, v.6
to: X3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <890316-210049-6699@Xerox>
This version was distributed in hardcopy form at the
January 1989 meeting, but was tabled.
There are two proposals.
!
Issue: EXIT-EXTENT
References: CATCH, THROW (p 142),
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Version 6, 8-Jan-89, Masinter, fix some bugs
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
An "exit" refers to a point from which control can be transferred.
For a THROW or RETURN-FROM, the "exit" is the corresponding CATCH
or BLOCK body. For a GO, the "exit" is the form within the TAGBODY
which was being executed at the time the GO is performed.
The extent of an exit is dynamic; it is not indefinite. The extent
of an exit begins when the corresponding form (CATCH, BLOCK or TAGBODY
clause) is entered. When the extent of an exit has ended, it is no
longer legal to return from it.
The extent of an exit is not the same thing as the scope of the
designator by which the exit is identified. For example, a BLOCK
name has lexical scope but the extent of its exit is dynamic; the
scope of a CATCH tag could differ from the extent of the CATCH's
return point. (That's part of what is at issue here.)
The ambiguity at issue arises for the case where there are transfers
of control from the cleanup clauses of an UNWIND-PROTECT.
When a transfer of control is initiated by GO, RETURN-FROM or THROW,
a variety of events occur before the transfer of control is complete.
In particular,
(a) the cleanup clauses of any intervening UNWIND-PROTECT clauses
are evaluated,
(b) intervening dynamic bindings of special variables and catch tags
are undone,
(c) intervening exits are "abandoned", i.e., their extent ends and it
is no longer legal to attempt to transfer control through them,
(d) the extent of the exit being invoked ends,
(e) control is finally passed to the target.
The order of these events is not explicit in CLtL, however. The
implementation note on p.142 gives a clue about the interweaving
of (a) and (b), but there are differing opinions about the times
at which (c) and (d) may occur. In particular,
Is it legal for an implementation to end the extent of all
intervening exits before processing the cleanup clauses of intervening
UNWIND-PROTECTs?
What is the dynamic context at the time UNWIND-PROTECT clauses are
evaluated: how is the unwinding of dynamic bindings intertwined with
evaluation of UNWIND-PROTECT cleanup clauses?
Proposal (EXIT-EXTENT:MINIMAL):
The extent of an exit--whether it is being "abandoned" because it is
being passed over, or it is itself the target exit--ends as soon as
the transfer of control is initiated. That is, the events (c) and (d)
at the beginning of the initiation of the transfer of control. In the
language of the implementation note on p.142, the extent ends at the
beginning of the second pass. It is an error to attempt a transfer
of control to an exit whose dynamic extent has ended.
Otherwise, events (a) and (b)--the undoing of dynamic binding of special
variables and CATCH tags, and the execution of UNWIND-PROTECT cleanup
clauses--are performed in the order corresponding to the reverse order
in which they were established, as implied by the implementation note
on p.142. The effect of this is that the cleanup clauses of an UNWIND-PROTECT
will see the same dynamic bindings of variables and CATCH tags as were
visible when the UNWIND-PROTECT was entered.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL. A program that presumed a longer extent
would be in error. Implementations may support longer extents for
exits than is required by this proposal; in particular, an
implementation which allowed the larger extent of the MEDIUM
proposal below would still conform.
Proposal (EXIT-EXTENT:MEDIUM):
The events of (a), (b), (c) and (d) are interwoven in the reverse
order in which they were established. In particular, the extent of
a passed-over exit ends when control reaches a frame that was
established before the exit was established.
In particular, it is legal, during the evaluation of an UNWIND-PROTECT
cleanup form executed because of a non-local transfer of control, to
initiate a new transfer of control to an exit intervening between the
UNWIND-PROTECT and the original target; the original processing of
transfer of control is abandoned.
Examples:
;; Error under either proposal: BLOCK exits normally before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error under either proposal: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error under either proposal: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
;;returns 2 under MEDIUM, is error under MINIMAL
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
;; because the catch of B is passed over by
;; the first THROW, hence portable programs must assume its dynamic extent
;; is terminated. The binding of the catch tag is not yet disestablished
;; and therefore it is the target of the second throw.
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; the following is an error under MINIMAL; the extent of the
;; inner catch terminates as soon as the THROW commences, even
;; though it remains in scope. Thus, the THROW of :SECOND-THROW
;; sees the inner CATCH, but its extent has ended.
;; under MEDIUM, it prints "The inner catch returns :SECOND-THROW"
;; and then returns :OUTER-CATCH.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
;; Following returns 10 under either proposal. The inner
;; CATCH of A is passed over, but because that CATCH
;; is disestablished before the THROW to A is executed,
;; it isn't seen.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
;; Following is an error under MINIMAL because the extent of
;; the (CATCH 'FOO ...) exit ends when the (THROW 'FOO ...)
;; commences.
;; Under MEDIUM, the pending exit to tag FOO is discarded by the
;; second THROW to BAR and the value 4 is transferred to
;; (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...)
;; then returns the 4 because its first argument has returned
;; normally. XXX is not printed.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;; Following returns 4 under either proposal; XXX is not printed.
;; The (THROW 'FOO ...) has no effect on the scope of the BAR
;; catch tag or the extent of the (CATCH 'BAR ...) exit.
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;;The following are legal and print 5 under either proposal:
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect (return)
(print x))))
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect
(if (test) (return))
(print x))))
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.
For MEDIUM: Giving exits a longer extent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target BLOCK or CATCH at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, it is possible for a throw or non-local exit
to be effectively "stopped" by an UNWIND-PROTECT cleanup clause that
performs a non-local transfer of control to a passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter extent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all non-local exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangeably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the non-local exit
that caused the cleanup clause to be invoked.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
The extent of an object with dynamic extent is the extent of the form
which created it. Code which is executed "within" that form is within
the extent of the object(s). This applies to all dynamic objects, such
as special variable bindings, not just exits. Actually, I think the intent
of the implementation note on p.142 is fairly clear and supports this
interpretation. The supposedly ambiguous use of "frame" should be read
as something like "form which establishes a dynamic extent". It might be
clearer if the last sentence were changed to read something like:
"On the second pass the stack is actually unwound. Each form which establishes
a dynamic extent is undone in reverse order of creation until the matching
CATCH is reached. The meaning of undoing a form depends on the type of form.
For UNWIND-PROTECT, it means executing the cleanup forms. For CATCH it means
removing the CATCH tag. For dynamic bindings it means undoing the binding,
restoring the previous saved value. {This is not an exhaustive listing of the
possibilities.}"
----- End Forwarded Messages -----
∂16-Mar-89 2220 X3J13-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:20:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:18:04 PST
Date: 16 Mar 89 22:17 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <890316-221804-6820@Xerox>
Unfortunately, there have been no new versions of this
produced since it was last distributed, labelled DRAFT, to X3J13
prior to the October, 1988 meeting in Fairfax.
Excerpts from the mail on this are appended.
!
Issue: FUNCTION-COERCE-TIME
References: SET-MACRO-CHARACTER (p362),
SET-DISPATCH-MACRO-CHARACTER (p364),
MAP (p249), MAPL (p129), ...
Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
Functions using a positional predicate (SORT, DELETE-IF, ...)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
(changes to presentation of all proposals per Masinter's comments)
Status: For Internal Discussion
Problem Description:
Many functions which accept arguments which are to be treated functionally
but which are not of type FUNCTION. This functionality can be very useful,
but the time at which the coercion is accomplished must be made clear.
Proposal (FUNCTION-COERCE-TIME:LAZY):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is delayed until the function is about to be called and is done anew
every time the function is to be called. That is, passing a non-function
functional argument, F, is equivalent to passing
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
Rationale:
One of the main reasons that it may be useful to pass a non-function
instead of a function is to accomplish indirection which allows later
redefinitions to take proper effect. Early binding would tend to
thwart the usefulness of such indirection and force people into
notationally more clumsy devices.
Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is done immediately. That is, all such functions treat a non-function
functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead.
Rationale:
This is easier to implement since the coercion is done up front and
no further worry about uncoerced functions is needed internally.
Also, inlining of mapped functions (without using temporary storage
to hold a cached value of the function being mapped) can be done
without needing to know whether the function being inlined will
affect the place which holds the functional argument being passed.
Proposal (FUNCTION-COERCE-TIME:HYBRID):
Specify that when a non-function (eg, a symbol) is used as a
functional argument to an operator, the coercion of that non-function
to a function must be done immediately if the functional argument is
to be used only internally to the function (eg, SORT or MAPCAR).
Otherwise, if the functional argument's use persists beyond the end
of the call to the operator (eg, SET-MACRO-CHARACTER), any coercion is
delayed until the function is about to be called and is done anew every
time the function is to be called.
That is, functions like SORT and MAPCAR are permitted to treat a
non-function functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead. However, functions like SET-MACRO-CHARACTER
would treat a non-function functional argument, F, as if
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
were passed instead.
Rationale:
Debugging is enhanced for operations such as SET-MACRO-CHARACTER
without needlessly hampering useful optimizations to things like
SORT or MAPCAR, which very rarely require this facility.
Test Cases:
(DEFVAR *SOME-FUNCTIONS*
(LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))
; Control situation A
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4)
; Control situation B
(LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
(LIST (MAPCAR FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 1 1) 4)
; Interesting Situation 1
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-1
or ((1 1 1 1) 4) ;Ambitious-1
; Interesting Situation 2
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR 'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-2
or ((1 1 1 1) 4) ;Ambitious-2
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(EXPT (READ STREAM) (OR N 1)))
(SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3 81)
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(+ (READ STREAM) (* (OR N 0) 0.01)))
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3.0 3.04) ;Lazy-3
(3 81) ;Ambitious-3
Proposal LAZY requires LAZY-1, LAZY-2, LAZY-3.
Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
Proposal HYBRID requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.
Current Practice:
Implementations are permitted to differ in when they do the coercion since
the coercion time is not clearly spelled out.
(In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
only if the original value of the function definition is not cached.)
[Some info below is based on empirical testing -- I didn't look at the
source or try to see how speed/safety affect things. -kmp]
Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
and compiled.
Both Symbolics Genera and Symbolics Cloe implement LAZY-2.
Symbolics Genera implements LAZY-3.
Symbolics Cloe implements AMBITIOUS-3.
Cost to Implementors:
[Costs may vary widely depending on current practice.
I'll leave this one open for now pending feedback from others. -kmp]
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
A very important aspect of the language would be left unspecified.
Portability would suffer.
Benefits:
HYBRID has the benefit of making things like readmacros easier to debug.
LAZY offers the additional benefit of being able to repair certain
functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
and then to proceed the error (in implementations offering that restart
option) in a way that makes the ongoing call to SORT or MAPCAR notice
the repairwork right away.
Aesthetics:
Since this is a visible aspect of the language, anything which clarified
the behavior that a programmer might expect would seem to improve the
aesthetics somewhat.
Discussion:
This issue was raised by Nick Gall and written up by Pitman.
Pitman supports FUNCTION-COERCE-TIME:HYBRID.
!
Additional comments:
There was some concern about the proposal wording, because
it was trying to allow for the possibility that implementations
might extend other objects (e.g., lists that begin with
LAMBDA) to "coerce" to functions, and the proposal should
apply for them, too.
This made the wording of the proposal pretty awkward, though.
- - - - - -
The writeup for the LAZY option should mention that this might cause a
substantial performance hit in some implementations.
Of the options presented, I prefer AMBITIOUS. However, I would really
much rather see this whole issue left explicitly vague in the
standard.
- - - -
notes from Cleanup meeting (Fairfax, 1988):
Eliminate the AMBITIOUS proposal. Continue to evolve the
HYBRID and LAZY variants.
Relation to DEBUG quality.
There was some discussion about the idea of permitting vagueness
(ie, making LAZY/AMBITIOUS optional in some places).
X3J13 meeting:
Some people weren't completely convinced that the HYBRID proposal
would feel predictable enough. Others disagreed.
- - - - - - - -
Well, the main reason why I prefer "AMBITIOUS" to "HYBRID" is that it
seems kind of peculiar to make an exception for the two functions,
SET-MACRO-CHARACTER and SET-DISPATCH-MACRO-CHARACTER. Besides being
different from all the other functions that take functional arguments,
it makes them different from the pathname functions (which always
coerce non-pathname "pathname" arguments to pathnames) and the package
functions (which always coerce non-package "package" arguments to
packages).
Also, I disagree that there is no performance penalty, although it's
certainly small in comparison to the rest of the reader's processing.
For example, A-Lisp has a fast, opencoded funcall primitive that it
uses when its argument is guaranteed to be a function, which is *much*
faster than a normal funcall (by a factor of at least 20).
I don't feel really strongly about this -- HYBRID is not really all
that objectionable to me, and I would vote for it if AMBITIOUS is
thrown out.
-------
... I'm thinking of a revision which might lean more toward
explicitly vague on some of these issues. At the same time,
I'd like to encourage the use of the DEBUG and/or SPEED quality
to help compilers lean toward LAZY in the slow/easy-to-debug
case and AMBITIOUS in the fast/hard-to-debug case. There are
some details to be worked out, though...
∂16-Mar-89 2254 X3J13-mailer Issue: HASH-TABLE-ACCESS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:53:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:51:36 PST
Date: 16 Mar 89 22:51 PST
From: masinter.pa@Xerox.COM
Subject: Issue: HASH-TABLE-ACCESS (version 2)
to: X3J13@sail.stanford.edu
Line-fold: NO
Message-ID: <890316-225136-6875@Xerox>
Version 1 of this issue was distributed prior
to the October 1988 meeting.
This version was produced in response to
comments there.
Additional comments are at the end.
!
Issue: HASH-TABLE-ACCESS
References: hash-tables (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
13-Oct-88, version 2 by Walter van Roggen
Problem Description:
There are many characteristics of hash-tables which are specified upon
creation but are not accessible afterwards.
Proposal: (HASH-TABLE-ACCESS:PROVIDE)
Add the following functions to the language:
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
HASH-TABLE-TEST hash-table
Returns the test used for comparing keys in the hash table.
By default the value will be EQL.
Current Practice:
VAX LISP and Lucid 3.0 implement the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
For example, it would allow programs to gain statistics about hash
table usage that might enable better tuning.
Discussion:
None of these are required to be SETF'able, though some might be
reasonable implementation-dependent extensions. Including such
modification abilities might constrain some implementations unduly.
This first appeared in ">GLS>clarifications.text" of 12/06/85.
!
Additional Comments:
Adding accessors for hash tables seems like a reasonable idea to me,
but I don't like the idea of being able to SETF them.
- - - - -
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
I don't think the "current" values of these are well defined except in
reference to one particular implementation technique (I believe the
corresponding arguments to make-hash-table are advisory in nature and can be
ignored when not applicable). For instance, can you describe what an
implementation using alists should return from each of these functions?
I do support the addition of HASH-TABLE-TEST.
- - - - - - -
Well, I think there would be some leeway on the return values for
HASH-TABLE-REHASH-SIZE/REHASH-THRESHOLD/SIZE too.
If an implementation really did implement them with association lists,
perhaps reasonable return values would be:
HASH-TABLE-REHASH-SIZE 1
HASH-TABLE-REHASH-THRESHOLD 1.0
HASH-TABLE-SIZE the length of the association list
- - - - - - -
I still would like to see SETF enabled for:
HASH-TABLE-REHASH-SIZE
HASH-TABLE-REHASH-THRESHOLD
At issue is the rate of "rehashing" between successive, novel entries
into the table, and the rate of consing to maintain the table. [Perhaps
this would be clearer if there were a function in the language called
REHASH; Lucid 3.0 has such a function, and Interlisp-D had such a function.]
Of course, the setf methods for these two accessors would do a good deal of
argument and consistency checking. So what possible harm could come from
permitting the user to alter these parameters after initial creation? those
implementations that substitute alists for "hash-tables" can try to adapt to
this view, that some kind of "rehash" step [with some determined cost] is
done after the entry which first makes:
(hash-table-count x) > (* (hash-table-size x)
(hash-table-rehash-threshold x))
be true [assuming a floating-point value for the threshold]. This is part
of the whole point for having "hash tables" in the language.
- - - - -
I'm quite sympathetic to being able to SETF some of the hash-table readers,
but I didn't think it appropriate to require of all implementations.
- - - - - -
The value of HASH-TAbLE-REHASH-SIZE and HASH-TAbLE-REHASH-THRESHOLD are
implementation dependent, and guaranteed to be greater than or equal to the
values given to MAKE-HASH-TABLE, and idempotent, in that if you make a hash
table with the same values as a given hash table then the -REHASH-SIZE and
-REHASH-THRESHOLD of the newly created one will be the same as the input
values. (This says that they may be thresholded upward in some
implementation-dependent-manner.)
HASH-TABLE-SIZE should be greater than or equal to the count of things
MAPHASH would iterate over, and HASH-TABLE-TEST will return one of the
symbols EQ EQL EQUAL (or, if HASH-TABLE-TESTS passes, EQUALP), even if #'EQ
#'EQUAL #'EQL are given.
Normally implementation-dependent-extensions are explicitly discouraged;
I'm no longer sure at the momemnt whether PACKAGE-CLUTTER would explicilty
disallow such extensions unless they are explicitly allowed, but we should
be cautious in throwing around phrases like "might be
reasonable implementation-dependent extensions" if we don't mean it. I
would take that out, actually.
∂16-Mar-89 2244 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:43:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:40:08 PST
Date: 16 Mar 89 22:34 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME, v.1
To: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-224008-6866@Xerox>
This issue has been renamed several times; however, it is
the same old issue. I say this lest anyone think we can
'two week' it away.
We didn't have a 'letter ballot' and so we have to talk
about it. Maybe.
Additional Comments are at the end; including a fairly substantial
additional proposal.
!
Issue: FUNCTION-NAME
References: SETF rules for what -place- can be (pp.94-7)
FBOUNDP function (p.90)
FMAKUNBOUND function (p.92)
FUNCTION special form (p.87)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
88-002R pages 1-21, 2-21, 2-26, 2-39, 2-44, 2-46, 2-51, and 2-55
(There are additional references for the MEDIUM and LARGE
proposals, but they are not listed here. They're obvious.)
Related issues: SETF-FUNCTION-VS-MACRO, SETF-PLACES (both subsumed by this)
Category: ADDITION
Edit history: Version 1, 23-Jan-89, by Moon
(based on discussion at X3J13 meeting)
Problem description:
The Common Lisp Object System needs a well-defined way to relate the name
and arguments of a writer function to those of a reader function, because
both functions can be generic and can have user-defined methods. The way
that was adopted into Common Lisp when X3J13 voted to accept document
88-002R was to use a list (SETF reader) as the name of the writer function.
Some changes to the non-object-oriented portion of Common Lisp are required
in order to support this.
This issue has three proposals.
Proposal (FUNCTION-NAME:SMALL):
Add a new concept "function-name" (called "function-specifier" in
88-002R). A function-name is either a symbol or a 2-element list whose
first element is the symbol SETF and whose second element is a symbol.
Implementations are free to extend the syntax of function-names to
include lists beginning with additional symbols other than SETF.
Add a new function (FDEFINITION function-name), which returns the
current global function definition named by function-name, or signals
an error if there is no global function definition. This follows all
the same rules listed for SYMBOL-FUNCTION in CLtL p.90.
Add SETF of FDEFINITION to change the current global function definition
named by a function-name. This follows all the same rules listed for
SETF of SYMBOL-FUNCTION in CLtL p.90.
Change the FBOUNDP and FMAKUNBOUND functions, and the FUNCTION special
form, to accept function-names in place of symbols. Implementation
defined extensions to the syntax of function-names cannot use the
symbol LAMBDA, since FUNCTION already uses that symbol.
Change the rules for SETF places (CLtL pp.94-7) by adding the following
clause after all the existing clauses:
- Any other list whose first element is a symbol, call it reader.
In this case, SETF expands into a call to the function named by the
list (SETF reader). The first argument is the new value and the
remaining arguments are the values of the remaining elements of
-place-. This expansion occurs regardless of whether reader or
(SETF reader) is defined as a function locally, globally, or not at
all. For example,
(SETF (reader arg1 arg2...) new-value)
expands into a form with the same effect and value as
(LET ((#:temp-1 arg1) ;force correct order of evaluation
(#:temp-2 arg2)
...
(#:temp-0 new-value))
(FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)).
Change the functions GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE
to implement the above change to the rules.
Document that a function named (SETF reader) should return its first
argument as its only value, in order to preserve the semantics of SETF.
Change the macro DEFGENERIC and the function ENSURE-GENERIC-FUNCTION to
refer to the function FDEFINITION where they now refer to the function
SYMBOL-FUNCTION.
Change the macros DEFCLASS, DEFGENERIC, and DEFMETHOD, the special forms
GENERIC-FLET and GENERIC-LABELS, and the functions DOCUMENTATION and
ENSURE-GENERIC-FUNCTION to use the term "function-name" where they now
use the term "function-specifier" or "function specifier".
Rationale for FUNCTION-NAME:SMALL:
This is the minimum change to Common Lisp needed to do what 88-002R says
about (SETF reader). Giving implementations freedom to extend the syntax
of function-names allows for current practice. Changing the name from
"function-specifier" to "function-name" avoids confusion and improves
consistency with the rest of the language, at the cost of a few small
changes to 88-002R.
Proposal (FUNCTION-NAME:MEDIUM):
Everything in FUNCTION-NAME:SMALL, and in addition:
Change the DEFUN macro to accept a function-name for its name argument,
instead of only accepting a symbol. If function-name is (SETF sym),
the body is surrounded by an implicit block named sym.
Rationale for FUNCTION-NAME:MEDIUM:
Keeping DEFUN consistent with DEFMETHOD is a good idea. Also 88-002R
says "The name of a generic function, like the name of an ordinary
function, can be either a symbol or a two-element list whose...", which
implies this change to DEFUN.
Proposal (FUNCTION-NAME:LARGE):
Everything in FUNCTION-NAME:MEDIUM, and in addition the following
numbered points, each of which could be adopted independently,
except where explicitly noted:
1. Change the function COMPILE to accept a function-name as its name
argument.
2. Change the function DISASSEMBLE to accept a function-name as its name
argument.
3. Change the FTYPE, INLINE, and NOTINLINE declarations and proclamations
to accept function-names, not just symbols, as function names.
4. Change the FLET and LABELS special forms to accept a function-name in
the name position, not just a symbol.
5. Change the TRACE and UNTRACE macros to accept function-names, not just
symbols, in the function name positions.
6. Change the ED function to accept (ED function-name) in place of
(ED symbol).
7. Change the syntax of a function call to allow a function-name as the
first element of the list, rather than allowing only a symbol.
8. Change the DEFMACRO macro and the MACROLET special form to accept a
function-name in the name position, not just a symbol. Change the
MACRO-FUNCTION function to accept function-names, not just symbols.
Change the last rule for SETF places to use
((SETF reader) #:temp-0 #:temp-1 #:temp-2...)
in place of
(FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)
so that (SETF reader) can be defined as a macro. This depends on item
7. If item 4 is rejected, MACROLET should be stricken from this item.
9. Add an optional environment argument to FDEFINITION, SETF of
FDEFINITION, FBOUNDP, and FMAKUNBOUND. This is the same as the
&environment argument to a macroexpander. This argument can be used to
access local function definitions, to access function definitions in the
compile-time remote environment, and to modify function definitions in
the compile-time remote environment.
10. Change the second, third, fourth, fifth, seventh, and ninth rules for
SETF places so that they only apply when the function-name refers to the
global function definition, rather than a locally defined function or
macro. (The ninth rule is the one that refers to DEFSETF and
DEFINE-SETF-METHOD; the other rules listed are the ones that list
specific built-in functions). The effect of this change is that SETF
methods defined for global functions are ignored when there is a local
function binding; instead, the function named (SETF reader), which may
have a local function binding, is called. This change is most useful
in connection with item 4, but does not actually depend on it.
11. Clarify that the eighth rule for SETF places (the one for macros)
uses MACROEXPAND-1, not MACROEXPAND.
Rationale for FUNCTION-NAME:LARGE:
This extends the new feature throughout the language, in order to make
things generally more consistent and powerful. Point by point:
1,2,3 - one should be able to compile, examine, and make declarations
about functions regardless of whether they are named with symbols or
with lists.
4 - locally defined non-generic SETF functions are a logical companion
to locally defined generic SETF functions, which can be defined with
GENERIC-FLET or GENERIC-LABELS. They make sense on their own, since one
might define a local reader function and want a local writer function
to go with it.
5,6 - one should be able to apply development tools to functions
regardless of how they are named. The function DOCUMENTATION was already
updated to work for function-names by 88-002R. There might be some
difficulty with implementation-dependent syntax extensions to TRACE and
UNTRACE conflicting with this new syntax.
7 - this restores consistency between the FUNCTION special form and the
first element of a function call form.
8 - it seems more consistent to allow macros to be named the same way
that ordinary functions are named. However, this might be considered
redundant with DEFSETF.
9 - this is not needed by the "chapter 1 and 2" level of CLOS, but might
be used by the metaobject based implementation of ENSURE-GENERIC-FUNCTION.
10 - this change was in SETF-FUNCTION-VS-MACRO and makes item 4 more useful.
11 - this change was in SETF-FUNCTION-VS-MACRO and is a good idea, but
actually is independent of everything else being proposed here.
Examples:
;This is an example of the sort of syntax 88-002R allows
(defmethod (setf child) (new-value (parent some-class))
(setf (slot-value 'child parent) new-value)
(update-dependencies parent)
new-value)
(setf (child foo) bar)
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this, if the MEDIUM or LARGE
;proposal is adopted.
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;The preceding example would have to be defined like this
;if only the SMALL proposal is adopted. This is a method
;all of whose parameter specializer names are T.
(defmethod (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when the earlier rules do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars
(cdr form)
(list new-value)
`(funcall #'(setf ,(car form)) ,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
Current practice:
No implementation supports exactly what is proposed. Symbolics Genera
and the TI Explorer support something close to the MEDIUM proposal, but
differing in a number of details. Symbolics Genera supports items 1, 2,
3, 6, and 11, and modified forms of items 5 and 8, of the LARGE proposal.
Moon considers this proposal's variations from Symbolics current practice
to be an improvement, although incompatible in some cases.
Many implementations currently support only symbols as function names.
Symbolics Genera and the TI Explorer have some additional function-name
syntaxes.
Cost to Implementors:
The SMALL and MEDIUM proposals are estimated to be no more than 50 lines
of code and require no changes to the "guts" of the interpreter and
compiler. Most of the code for this can be written portably and was
shown on two slides at the X3J13 meeting.
Some of the changes in the LARGE proposal are trivial, some require
the compiler to use EQUAL instead of EQ to compare function names, and
items 4, 7, and 8 might require a more substantial implementation
effort. Even that effort is estimated to be negligible compared to
the effort required to implement CLOS.
Cost to Users:
No cost to users, other than program-understanding programs, since this
is an upward compatible addition.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new feature,
but otherwise they will still work.
Cost of non-adoption:
We would have to make some other language change since the language
became inconsistent when 88-002R was adopted.
Performance impact:
This has no effect on performance of compiled code. It might slow
down the compiler and interpreter but not by very much.
Benefits:
CLOS will work as designed.
Esthetics:
Some people dislike using anything but symbols to name functions.
Other people would prefer that if the change is to be made at all,
the LARGE proposal be adopted so that the language is uniform in its
treatment of the new extended function names. Other proposals for
how to deal with SETF in CLOS were considerably less esthetic,
especially when package problems are taken into account.
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
Discussion:
Moon supports at least FUNCTION-NAME:MEDIUM. He does not necessarily
approve of all parts of FUNCTION-NAME:LARGE.
!
Additional Comments:
On the whole, I like this presentation much better than either of the
other two writeups that were circulated previously. I suspect that it
might be necessary to vote on each of the items in the LARGE proposal
individually, though. I think I would support items 1, 2, and 11, and
don't have any particular objections to 3, 5, and 6. For item 4, if
consistency with GENERIC-FLET and GENERIC-LABELS is an object, another
alternative is to change those two special forms to be like ordinary
FLET and LABELS, instead of vice versa.
- - - - - - -
I support FUNCTION-NAME:MEDIUM and may support LARGE once I think about
it some more.
As I explained in Hawaii, support for either of these is based on the
:conc-name bugs being removed from the condition system. Of course, I
believe the best way to do that is to CLOSify it.
- - - - - - - -
I'm still thinking about this, but while I am I wanted point out that
MEDIUM is unacceptable to me because I don't think FLET and DEFUN should
disagree on what they permit as defined names. If FLET were added to
MEDIUM, I suspect I'd think it was an internally consistent position.
LARGE has an appeal to me in general, but I'm still mulling over
the specifics.
- - - - - - - - - -
I favor the FUNCTION-NAME:LARGE proposal, because it defines a single,
useful notion of what a function name is. The other proposals have
the flaw that there are two kinds of function names: symbols, and
extended names, with only some of the Lisp primitives accepting the
latter. This may be convenient for some implementations, for the
short term, but it fragments the language.
I have two other comments on the proposal.
A. Reducing the Cost to Implementors
One observation you could put in the Cost To Implementors section is
that none of the SMALL, MEDIUM, or LARGE proposals require changes to
the "guts" of the interpreter and compiler. This is because an
implementation is free to use plain symbols internally to name
functions, and use a hack like JonL's SETF:|3.FOO.BAR| mapping to
convert non-symbol names to symbols. This conversion would be done as a
part of parsing the handful of forms which accept function names, and
then all other passes of the interpreter and compiler (the "guts") would
just see symbols. (By "parsing" I mean ensuring the right number and
type of syntactic subforms. You can see that this is a very early and
simple stage of processing.) Or, Lisp compilers with an "alphatization"
phase could perform function name symbolization at that phase.
B. Finishing the Job of Regularization
I'd like to suggest two additions to your smorgasbord of options in the
FUNCTION-NAME:LARGE section of the proposal. One addition would
regularize a major special case of functions--lambda expressions. The
other addition would reaffirm an unstated regularity in the language,
that function names can stand in for functions under FUNCALL and APPLY.
Not only can the treatment of symbolic and setf-list function names be
regularized, but lambda too can be treated in a consistent manner.
If these two points are added to your proposal, the language as a whole
would have a completely uniform treatment of functions and function
names. Here they are:
13. Declare that any function name is a suitable argument to FUNCALL and
APPLY. In such a case, the function name is passed to FDEFINITION,
and the result (which may in turn be a function name) is called.
That is, the following two expressions are equivalent, when fname
is a function name:
(FUNCALL fname x y)
<==>
(FUNCALL (FDEFINITION fname) x y)
Note that the definition is sought in the global environment.
Compare with the rule which applies to a function name occurs,
syntactically, as the car of a list in code:
(fname x y)
<==>
(FUNCALL (FUNCTION fname) x y)
<==> (under proposal item 9)
(FUNCALL (FDEFINITION fname <local-environment>) x y)
12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
whose cdr is a well-formed lambda argument list and body) is a function
name. The effects of the function name accessors on lambda expressions
are as follows. FDEFINITION returns an implementation-defined value which
is the function specified the lambda expression, closed in the global
environment. This FDEFINITION value cannot be changed by SETF.
FBOUNDP always returns T, and MAKUNBOUND is an error.
Esthetics:
The effect of items 11 and 12 is to complete the regularization of
Common Lisp's treatment of functions and function names. The total
effect of proposal items 1 through 12 is that Lisp has just two notions
for referencing function objects: FUNCTIONS, which are Lisp objects that
directly represent executable code, and FUNCTION NAMES, which can denote
functions. Symbols, SETF function names, and lambda expressions are all
examples of the latter notion. The former notion is highly
implementation dependent. Function names can occur as syntactic
entities in code. FUNCALL and APPLY work uniformly on both functions
and function names, with a consistent semantics.
Lambda expressions are often thought to denote "anonymous" functions, so
it may seem paradoxical to treat them as names. The paradox is only
apparent, since the expression itself has the properties of a Lisp
function name: It is (typically) a cons tree which can be read, printed,
and stored in source files, and it denotes a well-defined Lisp function.
Benefit to Users:
Function names are useful for representing objects in remote
environments, because they need not be bound at all times to the same
function, or to any function, and because they are typically stable in
meaning across reads and prints, where plain functions are not.
Programs which deal simultaneously with remote and local environments,
such as CLOS, can probably be simplified, since function names
can be used uniformly, rather than an ad-hoc mixture of functions
and function names.
The language as a whole become more uniform from these additions and
clarifications, making it easier to learn and use. (See Esthetics.)
Cost to Implementors:
Interpreters which currently have a special case check for application
of lambda expressions would need to modify this check to call
FDEFINITION when a list of any sort is encountered. Note that all
Common Lisps already must perform some such check, since lambda
expressions can be funcalled (and this is currently a very special case,
the only standard case of a list being funcalled). This means that
every Lisp already has a place to insert the required call to
FDEFINITION.
In some implementations, FDEFINITION of a lambda expression could be that
lambda-expression itself. In others featuring a pre-eval codewalk, the
walk would be done by FDEFINITION, which would return an appropriate
closure.
Cost of Non-adoption:
Rather than two notions for function references (functions and function
names), there would be several notions, each corresponding to the valid
inputs for particular group of primitives. APPLY and FUNCALL would
accept functions, symbolic names, and lambda expressions, but not setf
function names. FDEFINITION and its kind would accept symbols and setf
function names but not lambda expressions. If the :LARGE proposal is
not adopted, this fragmentation would also apply to the various syntaxes
involving function names; some names would be acceptable to DEFUN
but not to FLET, etc.
- - - - - - - - - - - - -
> 13. Declare that any function name is a suitable argument to FUNCALL and
> APPLY. In such a case, the function name is passed to FDEFINITION,
> and the result (which may in turn be a function name) is called.
I don't think this is such a good idea. The case of automatically coercing
a symbol to a function is needed because it provides a portable mechanism
for indirect addressing of a function; I haven't seen a reason to need this
for non-symbol function specs. But more important is that coercing a
symbol to a function is a trivial operation that is reasonable to do at
run time on each call without adding a significant amount of overhead.
FDEFINITION, on the other hand, is a much more expensive operation -- at
best it might use GET to do a property list lookup, or it could be using
string-append and INTERN to convert the name to a symbol. In either case,
I think this is more work than you want to do on each call.
> 12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
> whose cdr is a well-formed lambda argument list and body) is a function
> name. The effects of the function name accessors on lambda expressions
> are as follows. FDEFINITION returns an implementation-defined value which
> is the function specified the lambda expression, closed in the global
> environment. This FDEFINITION value cannot be changed by SETF.
> FBOUNDP always returns T, and MAKUNBOUND is an error.
The exceptions for SETF and MAKUNBOUND show that this is not really as
consistent as you might like. Furthermore, the FUNCTION special form would
have to treat a LAMBDA expression as a function, not a function name, in
order for it to be lexically scoped. It seems like this might just cause
confusion rather than consistency.
∂16-Mar-89 2334 X3J13-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 23:34:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 23:32:03 PST
Date: 16 Mar 89 23:31 PST
From: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
Subject: Issue LOOP-AND-DISCREPANCY, version 1
line-fold: NO
Message-ID: <890316-233203-6953@Xerox>
!
Issue: LOOP-AND-DISCREPANCY
References: Loop Facility document X3J13/89-004
Related issues:
Category: CHANGE CLARIFICATION
Edit history: Version 1, 15-Mar-88 by Steele
Problem description:
The treatment of the AND conjunction in FOR/AS and WITH clauses is not
consistent. Examples of the use of WITH are also not consistent in this
respect.
Page 2-5 implies by example that when AND is used to join two
FOR/AS clauses, the word FOR or AS must occur after the word AND.
Page 2-31 has formal syntax specifying that when AND is used to join two
WITH clauses, the word WITH must *not* occur after the word AND. Examples
on that page are consistent with this specification.
Page 2-41 has an example in which WITH is repeated after AND.
Proposal (LOOP-AND-DISCREPANCY:NO-REITERATION):
Let stand the formal syntax for WITH.
Change the description of FOR/AS clauses to specify that when
two or more such clauses are joined with AND, clauses after the
first do not have FOR or AS before them.
The complete formal syntax for FOR/AS may be described as follows:
for-as ::= {FOR | AS} for-as-subclause {AND for-as-subclause}*
for-as-subclause ::= for-as-arithmetic | for-as-in-list
| for-as-on-list | for-as-equals-then
| for-as-across | for-as-hash | for-as-package
for-as-arithmetic ::= var [type-spec] ...
and so on.
Examples:
> (loop for x from 1 to 10 ;Corrected from X3J13/89-004, page 2-5
and y = nil then x
collect (list x y))
((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))
> (loop with (a b) float = '(1.0 2.0) ;Corrected from X3J13/89-004, page 2-41
and (c d) integer = '(3 4)
and (e f)
return (list a b c d e f))
(1.0 2.0 3 4 nil nil)
Rationale:
The treatment of AND should be internally consistent. There is no reason
to repeat the FOR/AS keyword. Not repeating the keyword emphasizes that
the subclauses are functionally linked under the heading of WITH or FOR.
(Compare to the third use of AND in LOOP, to link clauses controlled
by WHEN/IF/UNLESS. One does not repeat the WHEN; rather, the clauses
grouped by AND are controlled by a single WHEN.)
Current practice:
Symbolics LOOP allows FOR to be included or omitted after AND,
with identical meanings. WITH may not be repeated after AND.
Cost to Implementors: Small?
Cost to Users: Possible incompatibility with existing implementors' extensions.
Cost of non-adoption: Utter confusion.
Performance impact: None.
Benefits: Consistent treatment of AND within LOOP.
Esthetics:
Absolutely none. We're talking about LOOP here.
Discussion:
Steele supports this proposal. It is a reversal of his previous
suggestion on the topic, thanks to feedback from Moon.
----- End Forwarded Messages -----
∂16-Mar-89 2330 X3J13-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 23:30:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 23:27:37 PST
Date: 16 Mar 89 23:26 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LOAD-OBJECTS (Version 3)
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-232737-6946@Xerox>
Version 1 was distributed in hardcopy form and discussed
at the January 1989 meeting.
Discussion so far has been considering alternatives of
load functions rather than load forms, or having two
generic functions.
!
Issue: LOAD-OBJECTS
References: none
Related issues: LOAD-TIME-EVAL,
CONSTANT-COMPILABLE-TYPES,
CONSTANT-CIRCULAR-COMPILATION
Category: ADDITION
Forum: Cleanup
Edit history: Version 1, 2-Jan-89, by Moon (for discussion)
Version 2, 13-Jan-89, by Moon (draft updated from discussion)
Version 3, 9-Mar-89, by Moon (changes suggested by discussion)
Problem description:
Common Lisp doesn't provide any way to use an object of a user-defined
type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
compiled with COMPILE-FILE. The problem is that LOAD has to be able
to "reconstruct" an equivalent object when the compiled-code file is
loaded, but the programmer has no way to tell LOAD how to do that.
Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
Define a new generic function named MAKE-LOAD-FORM, which takes one
argument and returns two values. The argument is an object that is
referenced as a constant or as a self-evaluating form in a file being
compiled by COMPILE-FILE. The objective is to enable LOAD to
construct an equivalent object.
The first value, called the "creation form," is a form that, when
evaluated at load time, should return an object that is equivalent to
the argument. The exact meaning of "equivalent" depends on the type
of object and is up to the programmer who defines a method for
MAKE-LOAD-FORM. This is the same type of equivalence discussed
in issue CONSTANT-COMPILABLE-TYPES.
The second value, called the "initialization form," is a form that,
when evaluated at load time, should perform further initialization of
the object. The value returned by the initialization form is ignored.
If the MAKE-LOAD-FORM method returns only one value, the
initialization form is NIL, which has no effect. If the object used
as the argument to MAKE-LOAD-FORM appears as a constant in the
initialization form, at load time it will be replaced by the
equivalent object constructed by the creation form; this is how the
further initialization gains access to the object.
Both the creation form and the initialization form can contain
references to objects of user-defined types (defined precisely below).
However, there must not be any circular dependencies in creation forms.
An example of a circular dependency is when the creation form for the
object X contains a reference to the object Y, and the creation form
for the object Y contains a reference to the object X. A simpler
example would be when the creation form for the object X contains
a reference to X itself. Initialization forms are not subject to
any restriction against circular dependencies, which is the entire
reason that initialization forms exist. See the example of circular
data structures below.
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation and initialization forms. Each
initialization form is evaluated as soon as possible after its
creation form, as determined by data flow. If the initialization form
for an object does not reference any other objects of user-defined
types that have not been referenced earlier in the COMPILE-FILE, the
initialization form is evaluated immediately after the creation form.
If a creation or initialization form F references other objects of
user-defined types that have not been referenced earlier in the
COMPILE-FILE, the creation forms for those other objects are evaluated
before F, and the initialization forms for those other objects are
also evaluated before F whenever they do not depend on the object
created or initialized by F. Where the above rules do not uniquely
determine an order of evaluation, which of the possible orders of
evaluation is chosen is unspecified.
While these creation and initialization forms are being evaluated, the
objects are possibly in an uninitialized state, analogous to the state
of an object between the time it has been created by ALLOCATE-INSTANCE
and it has been processed fully by INITIALIZE-INSTANCE. Programmers
writing methods for MAKE-LOAD-FORM must take care in manipulating
objects not to depend on slots that have not yet been initialized.
It is unspecified whether LOAD calls EVAL on the forms or does some
other operation that has an equivalent effect. For example, the
forms might be translated into different but equivalent forms and
then evaluated, they might be compiled and the resulting functions
called by LOAD, or they might be interpreted by a special-purpose
interpreter different from EVAL. All that is required is that the
effect be equivalent to evaluating the forms.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
It is valid for user programs to call MAKE-LOAD-FORM in other
circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
or a subclass of BUILT-IN-CLASS.
Define a new function named MAKE-LOAD-FORM-USING-SLOTS, which takes
one required argument and one optional argument and returns two
values. This can be useful in user-written MAKE-LOAD-FORM methods.
The first argument is the object. The optional second argument is a
list of the names of the slots to preserve; it defaults to all of the
local slots. MAKE-LOAD-FORM-USING-SLOTS returns forms that construct
an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
slots with values, or SLOT-MAKUNBOUND for slots without values, or
using other functions of equivalent effect.
MAKE-LOAD-FORM-USING-SLOTS returns two values, thus it can deal with
circular structures. MAKE-LOAD-FORM-USING-SLOTS works for any object
of metaclass STANDARD-CLASS or STRUCTURE-CLASS. Whether the result is
useful in an application depends on whether the object's type and slot
contents fully capture the application's idea of the object's state.
MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
an error. It is valid to implement this either by defining default
methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
or by having no applicable method for those classes.
Examples:
;; Example 1
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-form ((self my-class))
`(make-instance ',(class-name (class-of self))
:a ',(my-a self) :b ',(my-b self)))
In this example, an equivalent instance of my-class is reconstructed
by using the values of two of its slots. The value of the third slot
is derived from those two values.
Another way to write the last form in the above example would have been
(defmethod make-load-form ((self my-class))
(make-load-form-using-slots self '(a b)))
;; Example 2
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-form ((self my-frob))
`(find-my-frob ',(my-name self) :if-does-not-exist :create))
In this example, instances of my-frob are "interned" in some way.
An equivalent instance is reconstructed by using the value of the
name slot as a key for searching existing objects. In this case
the programmer has chosen to create a new object if no existing
object is found; alternatively she could have chosen to signal an
error in that case.
;; Example 3
(defclass tree-with-parent () ((parent :accessor tree-parent)
(children :initarg :children)))
(defmethod make-load-form ((x tree-with-parent))
(values
;; creation form
`(make-instance ',(class-of x) :children ',(slot-value x 'children))
;; initialization form
`(setf (tree-parent ',x) ',(slot-value x 'parent))))
In this example, the data structure to be dumped is circular, because
each parent has a list of its children and each child has a reference
back to its parent. Suppose make-load-form is called on one object in
such a structure. The creation form creates an equivalent object and
fills in the children slot, which forces creation of equivalent
objects for all of its children, grandchildren, etc. At this point
none of the parent slots have been filled in. The initialization form
fills in the parent slot, which forces creation of an equivalent
object for the parent if it was not already created. Thus the entire
tree is recreated at load time. At compile time, MAKE-LOAD-FORM is
called once for each object in the true. All of the creation forms
are evaluated, in unspecified order, and then all of the
initialization forms are evaluated, also in unspecified order.
;; Example 4
(defstruct my-struct a b c)
(defmethod make-load-form ((s my-struct))
(make-load-form-using-slots s))
In this example, the data structure to be dumped has no special
properties and an equivalent structure can be reconstructed
simply by reconstructing the slots' contents.
Rationale:
Only the programmer who designed a class can know the correct
way to reconstruct objects of that class at load time, therefore
the reconstruction should be controlled by a generic function.
Using EVAL as the interface for telling LOAD what to do provides
full generality.
MAKE-LOAD-FORM returns two values so that circular structures can
be handled. If CONSTANT-CIRCULAR-COMPILATION is rejected,
MAKE-LOAD-FORM will only return one value, although implementations
that make an extension to support circular constants will probably
also make the extension to accept two values from MAKE-LOAD-FORM.
The default for class objects and structures is to signal an error,
rather than picking some particular object reconstruction technique,
because no reconstruction technique is appropriate for all objects.
It only takes two lines of code, as in example 4, to instruct the
compiler to use the technique that most often has been suggested
as the default.
MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
for the programmer to control the system's actions.
The order of evaluation rules for creation and initialization forms
eliminate the possibility of partially initialized objects in the
absence of circular structures, and reduce it to the minimum possible
in the presence of circular structures. This allows nodes in
non-circular structures to be built out of fully initialized subparts.
Current practice:
Symbolics Flavors has something like this, but under a different name.
The name Symbolics uses is not suitable for standardization.
JonL reports that Lucid is getting more and more requests for this.
Cost to Implementors:
This seems like only a few one-line changes in the compiled-code
file writer and reader. MAKE-LOAD-FORM-USING-SLOTS is a couple
dozen lines of code, assuming the presence of the CLOS metaobject
protocol or an implementation-dependent equivalent.
Cost to Users:
None.
Cost of non-adoption:
Serious impairment of the ability to use extended-type objects. Each
implementation will probably make up its own version of this as an
extension.
Performance impact:
None.
Benefits:
See Cost of non-adoption.
Esthetics:
No significant positive or negative impact.
Discussion:
It would be possible to define an additional level of protocol that
allows multiple classes to contribute to the reconstruction of an
object, combining initialization arguments contributed by each class.
Since a user can easily define that in terms of MAKE-LOAD-FORM without
modifying the Lisp system, it is not being proposed now.
Any type that has a read syntax is likely to appear as a quoted
constant or inside a quoted constant. Pathnames are one example, user
programs often define others. Also many implementations provide a way
to create a compiled-code file full of data (rather than compiled Lisp
programs), and such data probably include extended-type objects.
Moon supports this. David Gray and John Rose made major contributions
to the discussion that produced this improved version 2 proposal.
----- End Forwarded Messages -----
∂17-Mar-89 0009 X3J13-mailer Issue: REAL-NUMBER-TYPE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 00:08:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 23:50:31 PST
Date: 16 Mar 89 23:49 PST
From: masinter.pa@Xerox.COM
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: x3J13@Sail.Stanford.EDU
Message-ID: <890316-235031-6996@Xerox>
!
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
suggestions clarifying the relationship between CL
numeric type names and mathematical names
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
Make REAL be a CL data type:
p.13 "Numbers"
Add: The NUMBER data type encompasses all of these kinds of
numbers. For convenience, there are names for some
subclasses of numbers. @i[Integers] and @i[ratios] are of
type RATIONAL. @i[Rational numbers] and @[floating-point
numbers] are of type REAL. @i[Real numbers] and @i[complex
numbers] are of type NUMBER.
Although the names of these types were chosen with the
terminology of mathematics in mind, the correspondences
are not always exact. Integers and ratios model the
corresponding mathematical concepts directly. Numbers
of the FLOAT type may be used to approximate real
numbers, both rational and irrational. The REAL type
includes all Common Lisp numbers which represent
mathematical real numbers, though there are
mathematical real numbers (irrational numbers)
which do not have an exact Common Lisp representation.
Only REAL numbers may be ordered using the <, >, <=,
and >= functions.
Compatibility note: The Fortran standard defines the term
"real datum" to mean "a processor approximation to the value
of a real number." In practice the Fortran "basic real" type
is the floating-point data type Common Lisp calls
SINGLE-FLOAT. The Fortran "double precision" type is
Common Lisp's DOUBLE-FLOAT. The Pascal "real" data type is
an "implementation-defined subset of the real numbers." In
practice this is usually a floating-point type, often what
Common Lisp calls DOUBLE-FLOAT.
A translation of an algorithm written in Fortran or Pascal
which uses "real" data usually will use some appropriate
precision of Common Lisp's FLOAT type. Some algorithms may
gain accuracy and/or flexibility by using Common Lisp's
RATIONAL or REAL types instead.
p.33 "Overlap, Inclusion, and Disjointness of Types":
Remove: The types RATIONAL, FLOAT, and COMPLEX are pairwise
disjoint subtypes of NUMBER.
Rationale: It might be thought that INTEGER and RATIO ...
Rationale: It might be thought that FIXNUM and BIGNUM ...
Add: The types RATIONAL and FLOAT are pairwise disjoint subtypes
of REAL.
The types REAL and COMPLEX are pairwise disjoint subtypes
of NUMBER.
Rationale: It might be thought that FIXNUM and BIGNUM should
form an exhaustive partition of the type INTEGER, that INTEGER
and RATIO should form an exhaustive partition of RATIONAL,
that RATIONAL and FLOAT should form an exhaustive partition of
REAL, and that REAL and COMPLEX should form an exhaustive
partition of NUMBER. These are all purposely avoided in order
to permit compatible experimentation with extensions to the
Common Lisp number system, such as the idea of adding explicit
representations of infinity or of positive and negative infinity.
p.43 Table 4-1 "Standard Type Specifier Symbols"
Add: REAL
p.49 "Type Specifiers that Abbreviate"
Add: (REAL low high)
Denotes the set of real numbers between low and high. ...
[As with RATIONAL and FLOAT.]
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
This class is important because it is all the numbers which can be
ordered.
Throughout the "Numbers" chapter, the phrase "non-complex number" is
used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Ability to do CLOS method dispatch on the type.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
∂17-Mar-89 0817 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:17:09 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 10:56:55 EST
Date: Fri, 17 Mar 89 10:57 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <890316191820.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890317155747.8.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 19:18 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Date: Thu, 16 Mar 89 18:00 EST
From: Barry Margolin <barmar@Think.COM>
...
Problem with DEPRECATE: Didn't we specify that the way to convert a
lambda expression into a function object is to use (COERCE x 'FUNCTION)?
Or did we also define a new function that does this?
Re-read FUNCTION-TYPE. The thing Beckerle really wanted and finally
got (over my objection) was that COERCE did nothing `hard' ... What
it ended up being able to be do can be expressed by #'IDENTITY and
#'SYMBOL-FUNCTION.
(COERCE x 'FUNCTION) ==
(ETYPECASE X
(SYMBOL (SYMBOL-VALUE X))
(FUNCTION X))
I don't really think anything more needs to be provided, even if we
DEPRECATE coerce.
I can't find my copy of FUNCTION-TYPE, but I remember it being amended
to add coercion of lambda expressions to functions. Maybe my memory is
faulty, but I remember something like
(COERCE X 'FUNCTION) ==
(ETYPECASE X
(SYMBOL (SYMBOL-FUNCTION X))
(FUNCTION X)
((SATISFIES LAMBDA-EXP-P) (EVAL `(FUNCTION ,X))))
(DEFUN LAMBDA-EXP-P (X)
(AND (CONSP X) ; a non-null list
(EQ (CAR X) 'LAMBDA) ; beginning with LAMBDA
(NOT (NULL (CDR X))) ; with at least two elements
(LISTP (CADR X)))) ; argument list is a list
barmar
∂17-Mar-89 0834 X3J13-mailer Issue: LOCALLY-TOP-LEVEL (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:34:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559504; Fri 17-Mar-89 11:31:57 EST
Date: Fri, 17 Mar 89 11:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOCALLY-TOP-LEVEL (Version 2)
To: X3J13@sail.stanford.edu
References: <19890309233609.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890317163159.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a cleanup committee issue. It could have been in the
compiler committee, but as it happens it ended up in the
cleanup committee.
Issue: LOCALLY-TOP-LEVEL
References: None
Related issues: EVAL-WHEN-NON-TOP-LEVEL, DECLARATION-SCOPE
Category: CLARIFICATION / ADDITION
Edit history: Version 1, 9-Mar-89, by Moon
Version 2, 16-Mar-89, by Moon, fix referenced proposal name
Problem description:
It is desirable to be able to wrap LOCALLY around one or more
top-level forms and have them continue to be treated as top-level
forms. Three examples of how this is useful:
- to put an OPTIMIZE or INLINE declaration into force around
several related forms.
- to put declarations into force around DEFCLASS, or any other
top-level form that lacks a syntax for embedded declarations.
- DECLARATION-SCOPE:NO-HOISTING, which passed in January,
removed the ability to use a DECLARE at the head of the body of a
DEFUN or DEFMACRO to make a declaration that applies to the entire
form, including the lambda-list. We are supposed to use LOCALLY
instead, but forms in the body of LOCALLY are not top-level,
and that changes the semantics of DEFMACRO.
Issue EVAL-WHEN-NON-TOP-LEVEL could not define LOCALLY to treat
its body as top-level forms, because only a special form can do
that and LOCALLY is a macro.
Proposal (LOCALLY-TOP-LEVEL:SPECIAL-FORM):
Change LOCALLY from a macro to a special form, and change the
definition of compiler processing (in EVAL-WHEN-NON-TOP-LEVEL)
so that when a LOCALLY form appears at top level the forms in
its body are processed at top level.
Examples:
(locally (declare (optimize (safety 3) (space 3) (speed 0)))
(defmacro frob (&environment e x y &optional (z (foo x y)))
(mumble x y z e)))
Without this proposal, this would have to be written
(defmacro frob (&environment e x y &optional (z (locally
(declare
(optimize
(safety 3)
(space 3)
(speed 0)))
(foo x y))))
(locally (declare (optimize (safety 3) (space 3) (speed 0)))
(mumble x y z e)))
Rationale:
Wrapping LOCALLY around a form should not change its semantics except
as specified by the declarations, hence the body of a top-level
LOCALLY should be top-level.
A macro cannot have a top-level body unless it expands into a special
form that has a top-level body; otherwise the macro invocation and
the macro expansion would not have identical semantics as top-level
forms. There is no available special form for LOCALLY to macroexpand
into (CLtL doesn't say, but presumably the intent was to expand into
a LET with an empty binding list).
Current practice:
The Zetalisp equivalent of LOCALLY worked to surround top-level forms,
because it was a macro that expanded into COMPILER-LET (stashing the
declarations in a special variable the compiler would look at). This
is of course the wrong way to do declarations, but it shows that the
idea was that you could wrap declarations around a bunch of top-level
forms.
Symbolics Genera 7.4.0 does not implement the proposal (but it does
not implement DECLARATION-SCOPE:NO-HOISTING either). I did
not survey any other implementations.
Cost to Implementors:
A half dozen lines of code in the compiler and a smaller amount
in the interpreter and any program-analyzing programs.
Cost to Users:
None.
Cost of non-adoption:
See the horrible example above.
Performance impact:
None.
Benefits:
More consistent language.
Esthetics:
Improved.
Discussion:
None.
∂17-Mar-89 0857 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:57:27 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA01151; Fri, 17 Mar 89 09:54:54 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06800; Fri, 17 Mar 89 09:54:37 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903171654.AA06800@defun.utah.edu>
Date: Fri, 17 Mar 89 09:54:35 MST
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
To: Barry Margolin <barmar@Think.COM>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, masinter.pa@xerox.com,
x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin <barmar@Think.COM>, Fri, 17 Mar 89 10:57 EST
BarMar is right. I have a hardcopy of the FUNCTION-TYPE writeup that
was mailed on 4 Sep 88, with a note from Larry indicating that it's
the final version as passed at the June meeting. It includes
COERCE'ing of lambda expressions to functions as item 6b.
Personally, I don't think this is a valid argument for not getting rid
of COERCE, since it is easy to coerce a lambda expression to a function
using (EVAL `(FUNCTION ,x)).
-Sandra
-------
∂17-Mar-89 0854 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:53:52 PST
Received: from Salvador.ms by ArpaGateway.ms ; 17 MAR 89 08:48:52 PST
Date: 17 Mar 89 08:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Fri, 17 Mar 89
10:57 EST
To: Barry Margolin <barmar@Think.COM>
cc: x3j13@sail.stanford.edu
Message-ID: <890317-084852-8321@Xerox>
I sent you a copy of FUNCTION-TYPE, as amended and passed. There was
discussion of an amendment to allow coercion of lambda expressions to
functions, but the decision at the June 88 X3J13 meeting was to not require
such coercions.
Most of the issues passed so far are available from arisia.xerox.com
clcleanup/passed. Some of the issues that were amended at the last meeting
haven't yet been stored 'as amended'. I hope to have them there in the next
few days, as well as copies of all of the 'pending' issues.
∂17-Mar-89 1041 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:40:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 10:28:12 PST
Date: 17 Mar 89 10:25 PST
From: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
To: x3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890317-102812-1247@Xerox>
The notes from the January meeting said Accepted MORE-PERMISSIVE (v2),
as amended. Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE to the list of functions and removed the paragraph beginning
with the words "If IN-PACKAGE...".
I can't figure out where a package name *isn't* allowed in DEFPACKAGE
or where a package object would make sense. Are the notes incorrect,
or were we just to hasty?
Anyway, here's my guess at what we really meant to pass; I suppose
we can just vote this one in instead.
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
amended & adopted at Jan 89 X3j13
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
or DELETE-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
accessors to package data structures and permit only package objects
as arguments.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
In addition, require that PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST to accept names,
too.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
It also adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permits strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
Since the pathname accessors all take namestrings or streams, one might
easily argue that it would be more consistent for PACKAGE-NAME,
PACKAGE-NICKNAMES, etc. to also take arguments of package names. After
all,
(PACKAGE-NAME "FOO") => "FOO"
is no stranger than
(NAMESTRING "JOE:fred.lisp") => "JOE:fred.lisp".
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occassions, but mostly seemed too far out in left
field to bother suggesting it.
∂17-Mar-89 1223 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:23:14 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00913g; Wed, 15 Mar 89 12:36:51 PST
Received: by blacksox id AA00297g; Wed, 15 Mar 89 12:40:06 PST
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903152040.AA00297@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 18:41 EST <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This looks good so far. A few comments that might help you
along with the draft:
...
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function). That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET. Your rationale argues against this but I strongly believe
that the rationale is wrong. I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:37 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01413g; Wed, 15 Mar 89 23:32:00 PST
Received: by bhopal id AA11607g; Wed, 15 Mar 89 23:32:47 PST
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160732.AA11607@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: X3J13@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 15 Mar 89 05:13 PST <890315-051405-3472@Xerox>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY. Compare CLtL, p28, with the
sentence in the Rationale Section:
"Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
..."
and with an item in the Clarification section:
"a. Whether an array can be both simple and adjustable is unspecified."
[CLtL definition *does* specify it].
I suggested that a simple statement be added to the proposal as follows:
"This proposal does not attempt to alter the meaning of the type
SIMPLE-ARRAY in any way"
Moon expressed approval of adding that statement.
Altered semantics would mean that it is no longer a portable type. I
have sent out several trivially small examples that show this. Some
people have interpreted those examples as simply showing what happens
with "broken" code; but quite to the contrary, they show how code can be
"correct" on one implementation and "broken" on another ****** when the
definition of SIMPLE-ARRAY is allowed to vary between one implementation
and the other ******. Very carefully, CLtL spells out that implementations
may vary on the efficiency with which they implement SIMPLE-ARRAYS; but
nowhere does it provide for optional exclusion of some parts of the
definition thereof.
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
-- JonL --
∂17-Mar-89 1223 X3J13-mailer Issue ERROR TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:23:02 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01029g; Wed, 15 Mar 89 14:13:57 PST
Received: by challenger id AA12685g; Wed, 15 Mar 89 14:07:47 PST
Date: Wed, 15 Mar 89 14:07:47 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903152207.AA12685@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue ERROR TERMINOLOGY
Is it the case that ``fatal'' is well-defined? If so, ``harmless'' is
simply something that is not fatal. According to my mathematics
education, that renders the term well-defined.
``Indeed, there is no way to invoke GC in Common Lisp and with a few
exceptions such as messages, GC must have NO side effects.''
Unsolicited messages can happen, and there is a proposal on the
cl-editorial table to render them harmless. If GC can have no side
effects, then why not state that and not wonder about unsolicited
messages? If we did that, then any Common Lisp that does print a
progress note is *out* of conformance.
Also, as I've said several times, rehashing, termination of processes,
progress messages, flushing IO buffers, closing streams, and a list of
possibly hundreds of things are side effects of GC that should be
guaranteed harmless (that is, not fatal).
``> Some things are not immediately harmful but may cause
> trouble later on.
Yes, lots of things are that way.''
The definition of fatal puts no time constraints on the fatality. Therefore,
neither does its negation.
``> By ``unpredictable but harmless'', I think we are in effect saying
> ``not completely unpredictable''. That is, we promise something but
> don't quite say what it is. For example, Lisp will presumably not
> break off and start playing chess. But maybe it's harmless to start
> playing chess.''
The beauty of a specification is knowing what not to say in order to
allow rational interpreters the freedom to interpret rationality now
and in the unpredictable future. There is considerable genius in the
fine line that Steele tread in CLtL on this. Does anyone rationally
think that a Common Lisp would be taken seriously that while GCing
broke out in a game of chess or an Irish gig? I refuse to seriously
debate with anyone who would use that as an example of something that
we must utter one word in the specification to prevent.
``As far as I can see, the only reasonable option is to specify
some range of possible consequences. The constraints, whatever
they may be, make it possible to reason about what the program
will do.''
The reason this won't easily work is that it presumes that we are able
to accurately predict future implementation techniques and even to
fully comprehend current ones. I'm sure that KMP or I could supply an
endless stream of new and bizarre cases that have to be explicitly
dealt with. (I single out KMP because he has uncanny creativity.)
But, I'll change the debate a little. I've claimed that ``harmless''
is well-defined if and only if ``fatal'' is well-defined or at least
defined well enough. So, to convince me that ``harmless'' should be
pitched, you must convince me that ``fatal'' must be pitched.
-rpg-
∂17-Mar-89 1223 X3J13-mailer issue SAFE-CODE, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:22:54 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01090g; Wed, 15 Mar 89 14:31:11 PST
Received: by challenger id AA12754g; Wed, 15 Mar 89 14:25:03 PST
Date: Wed, 15 Mar 89 14:25:03 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903152225.AA12754@challenger>
To: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
Subject: issue SAFE-CODE, version 1
According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.'' This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.
-rpg-
∂17-Mar-89 1246 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:45:23 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 14:55:05 EST
Date: Fri, 17 Mar 89 14:46 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
To: masinter.pa@xerox.com
Cc: x3J13@sail.stanford.edu
In-Reply-To: <890317-102812-1247@Xerox>
Message-Id: <19890317194641.7.BARMAR@OCCAM.THINK.COM>
Date: 17 Mar 89 10:25 PST
From: masinter.pa@xerox.com
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
accessors to package data structures and permit only package objects
as arguments.
...
In addition, require that PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST to accept names,
too.
You can't have it both ways! Also, the grammar of the second one could
use improving.
barmar
∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:57:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:52:50 EST
Date: Fri, 17 Mar 89 15:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-Id: <19890317205329.0.BARMAR@OCCAM.THINK.COM>
What happens in implementations that allow all arrays to be adjusted?
If you require that (typep x 'simple-array) implies (not
(adjustable-array-p x)), I see two possible resolutions: 1) such
implementations are not conforming; 2) the type SIMPLE-ARRAY is empty.
I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them. I think (2)
makes the SIMPLE-ARRAY type pretty useless, since a portable program
can't expect anything to be of this type (FIXNUM had this problem until
we fixed it in Hawaii).
barmar
∂17-Mar-89 1251 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:51:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559802; Fri 17-Mar-89 15:48:20 EST
Date: Fri, 17 Mar 89 15:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903152040.AA00297@blacksox>
Message-ID: <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function).
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
Oh, I keep forgetting that some people have to worry about the efficiency
of conses versus lists. I don't care which it is.
∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:54:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559814; Fri 17-Mar-89 15:51:33 EST
Date: Fri, 17 Mar 89 15:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY.
Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
There is !!NO!! change to the semantics, as I thought you had agreed in
the last message you sent on the topic. If now you're taking that back
and saying that you still think what this proposal says is a change to
the semantics, okay, but I have yet to figure out why you think that or
what you think is changed.
∂17-Mar-89 1316 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:15:31 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 14:55:24 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 14:54:21 EST
Received: by verdi.think.com; Fri, 17 Mar 89 14:51:09 EST
Date: Fri, 17 Mar 89 14:51:09 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903171951.AA09006@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 17:15 EST <19890316221519.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue DYNAMIC-EXTENT: a remark
Date: Thu, 16 Mar 89 17:15 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Line-Fold: No
Date: Thu, 16 Mar 89 15:34:53 EST
From: Guy Steele <gls@Think.COM>
A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
I believe that the words indicated above should be replaced by
"the extent of the binding for which the delaration was made".
That would change the meaning, since the declaration might not be attached
to a binding.
I am not certain that I understand the meaningful uses of this declaration
in cases where it is not attached to a binding.
The reference appears to be to a point in time. Scopes are in space;
the beginning of a scope is a character position in the text (or
something like that). Extents are in time. Is this what you meant?
You're right that there is something wrong with this wording. How about
if it said "at the beginning of execution of the forms in the scope of
the declaration"? Do declarations have extents? If so, could it say
"at the beginning of the extent of the declaration"?
I think you have to speak in terms of run-time instantiations
of executable code. Not sure.
--Guy
∂17-Mar-89 1356 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:54:27 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:48:54 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:50:04 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:46:51 EST
Date: Fri, 17 Mar 89 16:46:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172146.AA09535@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: eb@lucid.com, cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:48 EST <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Date: Fri, 17 Mar 89 15:48 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function).
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
Oh, I keep forgetting that some people have to worry about the efficiency
of conses versus lists. I don't care which it is.
Well, don't forget PAIRLIS and ACONS, which make the CONS format
a little easier to use than the LIST format.
[Voice 1: AAAAHHHHH!!! No!!! Not FORMAT!!!]
Calm down; I meant it generically. Make that "organization".
[Voice 2: AUUGUGGHH! Not generics!]
--Guy
∂17-Mar-89 1426 X3J13-mailer CLTL II
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 14:24:50 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 17:20:09 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 17:21:19 EST
Received: by verdi.think.com; Fri, 17 Mar 89 17:18:06 EST
Date: Fri, 17 Mar 89 17:18:06 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172218.AA09852@verdi.think.com>
To: x3j13@sail.stanford.edu
Cc: gls@Think.COM
Subject: CLTL II
I have mailed copies of my current working draft of "CLTL II" to
nearly everyone on the X3J13 mailing list (defined to be the set of
mailing labels Bob Mathis sent me). Those of you in the US can expect
to receive them on Monday or Tuesday via UPS, except for the three of
you whose address is a P.O. Box, in which case you are at the mercy of
Priority SnailMail. I don't know how long it will take for
international delivery.
To keep the costs down, where two persons were at the same address or
organization, I sent only one copy; for three or more I generally sent
two copies. (In all I sent out 70 copies, at about 30 bucks each
including shipping.)
KMP points out that it would be a serious mistake for everyone to drop
everything and start reading this draft, and I agree. It is more
important to prepare for the upcoming meeting. Furthermore, I would
hate to see anyone burn out reading this less-than-authoritative draft
of a less-than-authoritative book and then not have the energy to give
the draft standard a careful reading as well.
You don't *have* to read it at all. If you don't have the time, then
use it as a doorstop, keep it as a souvenir, or give it to someone
like a graduate student.
I will be grateful for any feedback I can get, of course. I recommend
that you pay the most attention to my paraphrasing of and commentary
on issues with which you have been particularly involved, to make sure
I didn't goof it up. There is an index to the issues in the back that
may be helpful.
Some of the new material has nothing whatsoever to do with X3J13.
You may wish to check out the I/O and Numbers chapters, for example.
Digital Press will have a copy editor reading it for grammar and
punctuation, and I will be reading it carefully, so if your time
is limited you probably should concentrate on the conceptual level.
I am especially interested in feedback of the form "You're going about
this all wrong. Here's what you should do..."
Don't worry at all about fonts, spacing, or number of pages. What I
shipped to you today is merely 300-dots-per-inch draft quality with
the wrong fonts. I am meeting next week with the book designer at
Digital Press and we are going to work out what to do. I also have a
list of changes to make to my TeX macros that will systematically
improve the spacing and page break decisions.
--Guy
∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:40:34 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:23:16 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:24:05 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:20:53 EST
Date: Fri, 17 Mar 89 16:20:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172120.AA09400@verdi.think.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:32:47 PST <8903160732.AA11607@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
...
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
I am very concerned about the stock hardware, but also very confused.
I understand that the stock-hardware implementors adamantly oppose
the proposed change, but I still have not seen a single convincing
example of why the proposed change would prevent them from accomplishing
the desired optimizations or why the proposed change would defeat
portability. I acknowledge that JonL has provided an example or two,
but I have not found them convincing. So either these examples are
wrong, or I am badly wedged; in either case I need further explanation.
--Guy
∂17-Mar-89 1555 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:55:11 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 18:48:21 EST
Date: Fri, 17 Mar 89 18:48 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, masinter.pa@xerox.com,
x3j13@sail.stanford.edu
In-Reply-To: <8903171654.AA06800@defun.utah.edu>
Message-Id: <19890317234839.3.BARMAR@OCCAM.THINK.COM>
Date: Fri, 17 Mar 89 09:54:35 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Personally, I don't think this is a valid argument for not getting rid
of COERCE, since it is easy to coerce a lambda expression to a function
using (EVAL `(FUNCTION ,x)).
I disagree. Many of us would not have voted in favor of FUNCTION-TYPE
without the coercion. We wanted either a specific function or the
extension to COERCE. We specifically did not feel that the above idiom
should be used in any actual code; it merely serves as a good way of
describing the value that the coercion returns.
I'll go along with COERCE-INCOMPLETE:DEPRECATE if it is amended to
include a new function that coerces a lambda expression, symbol, or
function to a function. I'll even suggest a name: MAKE-FUNCTION
(unfortunately, FUNCTION is taken, so it can't follow the precedent of
naming a function that coerces to type T just T).
barmar
∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:00:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02088g; Fri, 17 Mar 89 15:53:13 PST
Received: by bhopal id AA19366g; Fri, 17 Mar 89 15:55:29 PST
Date: Fri, 17 Mar 89 15:55:29 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172355.AA19366@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:51 EST <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
Sorry, Dave, I only ever made a request to add precisely the one statement
that you have already now added -- that the proposal *does not* alter
the CLtL semantics of SIMPLE-ARRAY. What I critiqued were statements
of the proposal that under reasonable interpretation could be taken to
mean that the CLtL p.28 definition of SIMPLE-ARRAY is being abrogated.
At any rate, thanks for the one-line addition.
-- JonL --
∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:13:52 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02119g; Fri, 17 Mar 89 16:06:33 PST
Received: by bhopal id AA19436g; Fri, 17 Mar 89 16:08:50 PST
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903180008.AA19436@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Fri, 17 Mar 89 15:53 EST <19890317205329.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
∂17-Mar-89 1612 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:12:34 PST
Received: from Salvador.ms by ArpaGateway.ms ; 17 MAR 89 16:02:36 PST
Date: 17 Mar 89 15:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
In-reply-to: masinter.pa's message of 17 Mar 89 08:47 PST
To: masinter.pa@Xerox.COM
cc: Barry Margolin <barmar@Think.COM>, x3j13@sail.stanford.edu
Message-ID: <890317-160236-2538@Xerox>
Sorry, I was confused when I sent that message. Yes, COERCE coerces lambda
expressions to functions. No, APPLY and FUNCALL do not (are not required
to)
do such coercions.
∂17-Mar-89 1623 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:23:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 439582; Fri 17-Mar-89 19:22:26 EST
Date: Fri, 17 Mar 89 19:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
To: masinter.pa@Xerox.COM
cc: x3J13@sail.stanford.edu
In-Reply-To: <890317-102812-1247@Xerox>
Message-ID: <19890318002018.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 17 Mar 89 10:25 PST
From: masinter.pa@Xerox.COM
The notes from the January meeting said Accepted MORE-PERMISSIVE (v2),
as amended. Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE to the list of functions and removed the paragraph beginning
with the words "If IN-PACKAGE...".
I can't figure out where a package name *isn't* allowed in DEFPACKAGE
or where a package object would make sense. Are the notes incorrect,
or were we just to hasty?
It wasn't my amendment, but I don't see why a package object should be
disallowed in any position in DEFPACKAGE other than the name or nickname
of the package being defined. I'll send a version that I think is correct
to CL-Cleanup and if no one disagrees it can be mailed to X3J13 to
supersede this one.
∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:56:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 19:52:28 EST
Date: Fri, 17 Mar 89 19:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903180008.AA19436@bhopal>
Message-Id: <19890318005322.4.BARMAR@OCCAM.THINK.COM>
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
The general rule has been that implementations that don't need (or don't
provide) these types of optimizations can safely ignore the language
features that support them. Some implementations can optimize array
access by knowing that the array can't be adjusted; other
implementations should not be required to remember this information if
they don't need it. Quoting from CLtL: "features that are useful only
on certain 'ordinary' or 'commercial' processors are avoided or made
optional."
Any feature of the language that provides access to facets of the
implementation allows somewhat non-portable code, meaning that it is
possible to write conforming code that produces different results in
different implementations. The simple program (PROGN
MOST-POSITIVE-FIXNUM) is conforming but produces many different results,
although the program (TYPEP MOST-POSITIVE-FIXNUM 'FIXNUM) is guaranteed
to return T in all conforming implementations. To paraphrase Moon, it
would be wonderful if all conforming programs were portable, but that's
unrealistic (it would be like expecting the grammar of a language to
only permit sensible sentences to be formed -- I suspect Godel's
Incompleteness Theorem comes into play here, pointing out that if the
grammar allows you to say everything you'd want to say, it must also
include some nonsense). The best I think we can do is provide enough
tools in the language to allow programs to detect implementation
differences and deal with them.
One thing that would help me is if you would post an example of code
that you feel is affected by this issue. I think you described such
things to me in words at the last meeting, but I (like GLS) am having a
hard time figuring out precisely what the problem is (I had the same
difficulty with the FIXNUM stuff that started the moby flame session in
the car on the way to the Japanese restaurant).
barmar
∂17-Mar-89 1758 X3J13-mailer too much mail!
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 17:58:23 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21950; Fri, 17 Mar 89 18:56:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07465; Fri, 17 Mar 89 18:56:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903180156.AA07465@defun.utah.edu>
Date: Fri, 17 Mar 89 18:56:07 MST
Subject: too much mail!
To: x3j13@sail.stanford.edu
Hey folks, I have a request. If you want to discuss an issue from one
of the subcommittees that was mailed to X3J13, please try to confine
the discussion to the appropriate subcommittee mailing list (or even
private mail to the person you're arguing with) instead of CC'ing all
of X3J13. Some of us have been getting hundreds of mail messages a
day and I (at least) don't have the time to follow all of the detailed
arguments on issues from other subcommittees anyway. I'd like to know
what the resolution of the problems is, but I don't really need to get
a blow-by-blow account in the meantime.
You will be getting such a summary (and some revised proposals) from
cl-compiler around the end of next week, by the way.
-Sandra
-------
∂17-Mar-89 2051 X3J13-mailer March meeting issues and sections
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 20:51:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16495; Fri, 17 Mar 89 10:21:57 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16495; Fri, 17 Mar 89 10:21:57 PST
Message-Id: <8903171821.AA16495@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA16495; Fri, 17 Mar 89 10:21:57 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 17 Mar 89 13:00
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: March meeting issues and sections
Dear Members:
The issues and sections of the standard named below have been
mailed to the X3J13 mailing list electronically and by hardcopy.
Also, the sections are available in files named march-1.dvi (chapter 1),
march-2.dvi (sections 2.1 and 2.2), march-5.dvi (chapter5), and
march-27-ballot.dvi (all the above-listed sections). Those files are
on hudson.dec.com, as usual, and the sources are there.
These issues and sections will come to vote on March 30
during the X3J13 meeting.
An affirmative vote on a section of the standard means that you
agree with the contents of the section except possibly the following:
Indentation of examples.
Spelling and other typos.
Figure placement and design.
The physical presence of issue markers (these will be removed in
the final draft); the issue markers sometimes change the indentation.
In addition, sections of the standard that could be modified by issues
passed by X3J13 that haven't been included up to this point, or have
been incorrectly included or under-included, will change even after
an affirmative vote on the section.
You are seeing two items again that appeared on the letter ballot:
ERROR-TERMINOLOGY, and Section 1.8. These were significantly changed
as a result of comments and will therefore require reviewing and
revoting.
On the front cover of each chapter that is part of this mailing (chapters 1, 2,
and 5) is a list headed by Reviewed by:. The people on this list
have simply READ and COMMENTED ON the attached sections. The appearance
of their names on the list is not an indication
of their endorsement, although they may in fact endorse the section they
reviewed.
Following is a summary of each issue and section's review history:
ERROR-TERMINOLOGY -- This issue was last revised by RPG, Moon, and
Pitman, and now they seem to be satisfied with the wording. This proposal is
directly reflected in Section 5.1.
CONFORMANCE-POSITION -- See the discussion section of this issue.
The issue is directly reflected in Section 1.5.
SUBSETTING-POSITION -- This issue has received general approval.
EXTENSIONS-POSITION -- Some would prefer we remain mute on this
issue, but the fact is that we have to provide some sort of definition
of an extension since we use the term in the ERROR-TERMINOLOGY proposal
and in the standard.
EXTRA-SYNTAX -- This issue has not received much comment until
recently. A new revised version may be distributed at the meeting.
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS -- Mixed reviews on this proposal.
EXTRA-RETURN-VALUES -- Not much discussion on this proposal although
it appears to be generally accepted. (Version 3, that is)
UNSPECIFIED-DATATYPES -- This proposal seems to be generally opposed.
UNSOLICITED-MESSAGES -- This issue has not received much comment
until recently. A revised version may be necessary.
MACRO-AS-FUNCTION -- Moon suggests that we just change the two
macros in question to functions (and skip the proposal?).
Sections 1.1-1.7 -- Some of these sections depend on the passage
of the previously-listed proposals. These sections have been reviewed
by numerous people and their comments have been included.
In addition, some suggestions for moving some of these sections
to an appendix are being entertained. That is covered in the TOC
issue which may undergo slight amendment at the meeting.
Sections 2.1-2.2 -- These sections have also been reviewed by
numerous people, and comments were included. The main unresolved
issues with section 2.2 seem to be as follows:
Lack of integration with CLOS and the Condition System.
Lack of a good definition of the type function.
These issues will most likely be resolved via clean-up proposals.
Sections 5.1-5.4 -- Section 5.1 is a rewrite of the concepts
part of the Condition System document approved by X3J13. It was reviewed in
detail by KMP, and also by Sandra Loosemore. The other sections were
reviewed by numerous people.
Section 1.8 -- This section was sent out with the letter ballot.
Although the section was intended to be non-detailed, it was apparently
much too vague to make it useful. It has been made slightly more detailed,
and whether or not it is at a suitable level will be decided by you.
A suggestion was made to move this section to an appendix.
If you need electronic copies of any of the issues, please let me know
(although they will be coming to you in hardcopy soon). If you have
any trouble accessing the standard sections, there are other ways
besides FTP and hardcopy for you to get the standard. If I don't know
you're having trouble, though, I can't help you resolve the problem.
Thanks in advance for all your review time so far. Your comments and
suggestions are immensely useful.
kathy chapman
∂17-Mar-89 2110 X3J13-mailer Issue: EXTRA-RETURN-VALUES (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:10:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560236; Sat 18-Mar-89 00:07:10 EST
Date: Sat, 18 Mar 89 00:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES (version 3)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903160834.AA18011@decwrl.dec.com>
Message-ID: <19890318050654.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would support this if it were amended with a list of functions
that are explicitly allowed to have additional return values.
As a suggested rough cut at such a list, how about all the functions
described in chapters 16, 21, 22, 23, 24, and 25 of CLtL? These are
the functions that I would call "environment" rather than "language".
∂17-Mar-89 2304 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:03:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560302; Sat 18-Mar-89 02:00:54 EST
Date: Sat, 18 Mar 89 02:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
To: X3J13@sail.stanford.edu
Message-ID: <19890318070046.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a correction to some wording problems and inconsistencies
in version 3 that was mailed out yesterday.
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
amended & adopted at Jan 89 X3j13
17-Mar-89, Version 4, by Moon, correct amended wording
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
or DELETE-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- all package-name arguments in DEFPACKAGE except for the name and
nicknames of the package being defined.
- the first argument to PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, or PACKAGE-USED-BY-LIST
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
In the list above, IN-PACKAGE may be changed to SELECT-PACKAGE
if IN-PACKAGE-FUNCTIONALITY:NEW-MACRO passes.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
It also adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permit strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occasions, but mostly seemed too far out in left
field to bother suggesting it.
∂18-Mar-89 0137 X3J13-mailer The Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 01:37:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 18 MAR 89 01:34:10 PST
Date: 18 Mar 89 01:33 PST
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: The Cleanup Issue Status List
Message-ID: <890318-013410-3635@Xerox>
This is the complete list of Cleanup issues that are either:
passed: passed at *any* previous meeting, including Jan 89
pending: have been distributed for the March meeting
in progress: might possibly be distributed for the March meeting,
or that I think are worth pursuing.
Of course, some more might come up or be revived.
I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
clcleanup/pending
clcleanup/passed
directories respectively.
I'm pretty much unavailable (travelling, etc.) until the meeting.
I'll try to read my mail while on the road, but
it will be difficult to handle the quantity we've
seen in the last week.
Codes:
! released for Jan 89 meeting
+ passed
* need new version
!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider
!
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ready for release?
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 2, 16-Mar-89
Status: ready for release?
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13
!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
!* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 5, 15-Mar-89
Comment: needs a little work
Status: *** NEARLY READY -- NEED NEW VERSION ****
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: *** NEED NEW VERSION ****
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***
! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal.
No version arrived.
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
∂20-Mar-89 0002 X3J13-mailer X3J13 mailer
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Mar 89 00:02:29 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa07578; 20 Mar 89 2:47 EST
Received: from utokyo-relay by RELAY.CS.NET id ai28052; 20 Mar 89 2:38 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA05005; Mon, 20 Mar 89 14:16:29 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.4J.BETA2-agu2)
id AA08005; Mon, 20 Mar 89 13:59:10 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
id AA00673; Mon, 20 Mar 89 13:59:37 JST
Date: Mon, 20 Mar 89 13:59:37 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8903200459.AA00673@kepa.cc.aoyama.junet>
To: x3j13@SAIL.STANFORD.EDU
Cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET
Subject: X3J13 mailer
I finally found that I did NOT receive ANY X3J13 mails
since March 6 or 7 until today.
I believe something was wrong with the mailer at stanford or
at the japanese gate way.
Editorial mailer, and other mailers are OK.
Anyway, I will attend the Fairfax meeting as a member,
though I have not get any fresh information for two weeks.
Looking forward to seeing you all at Fairfax.
Masayuki Ida
∂20-Mar-89 1229 X3J13-mailer Re: Fatal vesus Harmless
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:29:29 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA03785; Mon, 20 Mar 89 12:01:45 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA18569; Mon, 20 Mar 89 11:57:53 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA02722; Mon, 20 Mar 89 12:01:32 PST
Date: Mon, 20 Mar 89 12:01:32 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903202001.AA02722@clam.sun.com>
To: RPG@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re: Fatal vesus Harmless
Cc: cl-editorial@SAIL.Stanford.EDU
Dick Gabriel's discussion of fatal versus harmless made sense
to me. I'm going to propose here that within that framework
it can make sense to PERMIT certain SPECIFIED side effects.
I still say that "unspecified by harmless" loses.
To paraphrase, a program P "has fatal consequences"
exactly if it can be preceded and followed by conforming code
so that the entire sequence including P may "crash or abnormally
terminate".
The key question remaining in my mind is what side effects
can be considered harmless. Dick mentioned a property-list-like
data structure. Let's talk about hash tables and MAPHASH.
Specifically let's talk about the result of
(let ((result (list)))
(maphash #'(lambda (key value) (push (list key value) result))
table)
result)
The order of the result of this expression is unspecified for a
given hash table at a given time, but the set of key-value pairs
is specified.
Is it OK for CONS to cause the order of this list to change? Is it
OK for CAR to cause it to change?
Since we are trying to discuss harmless side effects, suppose we wish
to allow GC to rehash, possibly changing the order. The answer must
be that CONS can change the list, because it may invoke the GC.
Since we don't specify what operations can allocate storage, it
appears that we will prefer to say that any operation at all
is permitted to change the value of the example expression above.
In either case, we have no "unspecified but harmless" side
effect of some particular Common Lisp operation. We have a
particular class of side effects that are PERMITTED
in certain circumstances. We may choose to specify that
certain classes of side effects are ALWAYS permitted.
We may say that certain side effects are permitted -- to certain
operations. Suppose we wish to permit certain Common Lisp operations
to issue progress messages, but *not* to consider progress messages as
side effects permitted for all Common Lisp operations. In
that case it appears to me that we specify that certain operations may
issue progress messages.
While agreeing with Dick Gabriel's recent note, nowhere do I see
the concept "unspecified by harmless" as useful to the definition
of Common Lisp. Some side effects may be PERMITTED. Some may even
be permitted to ALL COMMON LISP OPERATIONS. These are specified
effects, not unspecified effects, and "permitted" I think conveys
the concept much more clearly than "harmless".
∂20-Mar-89 1315 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:15:01 PST
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07991; 20 Mar 89 18:58 GMT
Received: from xenakis by mordell.maths.bath.AC.UK id aa19210;
20 Mar 89 18:59 GMT
To: masinter.pa@xerox.com
CC: cl-compiler@sail.stanford.edu, x3J13@sail.stanford.edu
In-reply-to: masinter.pa@com.xerox's message of 16 Mar 89 05:47 PST <890316-054837-3596@Xerox>
Subject: issue COMPILER-VERBOSITY, version 6
Date: Mon, 20 Mar 89 19:02:07 GMT
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
b
∂21-Mar-89 1455 X3J13-mailer Issue: COMMON-TYPE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 14:55:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562312; Tue 21-Mar-89 17:55:26 EST
Date: Tue, 21 Mar 89 17:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321225520.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: COMMON-TYPE
References: CLtL p.35, p.76
Category: CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
The type COMMON is defined in a very peculiar way and does not seem to
be useful for anything. It can be extended by users using DEFSTRUCT,
but not DEFTYPE nor DEFCLASS, but it cannot be extended by implementations.
Whether certain types such as NUMBER and ARRAY are subtypes of COMMON
is implementation-dependent. The goal of having the COMMON type was
probably to improve portability, but it is unclear how it could actually
be used in that way.
Proposal (COMMON-TYPE:REMOVE):
Remove COMMON and COMMONP from the language.
Rationale:
Keeping the definition of COMMON accurate in the new specification, in
the face of changes elsewhere in the language such as the introduction
of CLOS and the possible introduction of character registries, is
difficult when no one is sure what COMMON is for. If no one uses COMMON,
it would be less work to just get rid of it.
Current practice:
Every implementation probably implements COMMON. Moon has never seen it
used except in a program to test whether its implementation matched CLtL.
Cost to Implementors:
None.
Cost to Users:
None unless they are actually using COMMON.
Cost of non-adoption:
Implementors would have to maintain COMMON. Users would have to try to
understand it, or figure out that they didn't care about it.
Performance impact:
None.
Benefits:
Simpler language.
Esthetics:
Simpler language.
Discussion:
None.
∂21-Mar-89 1500 X3J13-mailer Issue: HASH-TABLE-SIZE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 15:00:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562317; Tue 21-Mar-89 18:00:29 EST
Date: Tue, 21 Mar 89 18:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321230023.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: HASH-TABLE-SIZE
References: CLtL p.283
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL contradicts itself on the meaning of the :SIZE argument to
MAKE-HASH-TABLE. At the top of p.283, it says that the size is "the
maximum number of entries it can hold. Usually the actual capacity of
the table is somewhat less." At the bottom of the page it says "this
argument serves as a hint to the implementation of approximately how
many entries you intend to store." So does the :SIZE intended to be the
actual capacity of the table, or the amount of storage allocated to hold
the table. For example, if the implementation of hash tables is
designed for a loading of 65%, and the user specifies :SIZE 100, does
the table returned have space allocated for 100 entries, so that it
overflows and becomes bigger when 65 entries are inserted, or does the
table have space allocated for 154 entries, so that it overflows and
becomes bigger when 100 entries are inserted?
Proposal (HASH-TABLE-SIZE:INTENDED-ENTRIES):
Believe the bottom of p.283 rather than the top. The :SIZE argument
is approximately the number of entries that can be inserted without
the table having to grow.
Rationale:
The bottom of p.283 is user-oriented, the top is implementation-oriented.
User-oriented seems more appropriate.
Current practice:
Symbolics Genera 7.4 adheres to HASH-TABLE-SIZE:INTENDED-ENTRIES.
Other implementations were not surveyed.
Cost to Implementors:
At worst adding a multiplication to MAKE-HASH-TABLE.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Implementations will probably vary in which of the two interpretations
they believe. The language standard will not be self-consistent.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂21-Mar-89 1458 X3J13-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 14:58:19 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562314; Tue 21-Mar-89 17:58:03 EST
Date: Tue, 21 Mar 89 17:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321225757.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above to cover the components of complex
numbers. For (complex rational) arguments, a mathematically rational
result can be rational, (complex rational), or (complex float) at the
discretion of the implementation. For EXPT of a (complex rational) to
an integer power, the calculation must be exact and the result will
be rational or (complex rational).
Examples:
(log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
(expt #c(2 2) 3) => #c(-16 16)
(expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
Symbolics Genera 7.4 returns a (complex float) for the first example
and returns the specified answers for the second and third examples.
Other implementations were not surveyed.
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂21-Mar-89 1453 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 14:53:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562306; Tue 21-Mar-89 17:52:49 EST
Date: Tue, 21 Mar 89 17:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321225242.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: PATHNAME-COMPONENT-VALUE
Related Issues:PATHNAME-CANONICAL-TYPE,
PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-UNSPECIFIC-COMPONENT,
PATHNAME-WILD
References: CLtL pp.410-3
Category: CLARIFICATION and CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL is overly restrictive on the possible values for pathname components.
These restrictions are described in a funny way that makes it unclear
whether they are requirements, guidelines, or just an example.
The restrictions are not all written down in one place, but they appear
to be as follows:
Host nil, :wild, string, or list of strings
Device nil, :wild, string, or something else ("structured")
Directory nil, :wild, string, or something else ("structured")
Name nil, :wild, string, or something else ("structured")
Type nil, :wild, or string
Version nil, :wild, :newest, positive integer, implementation
dependent symbol, or implementation-dependent integer
less than or equal to zero. Suggestions include :oldest,
:previous, :installed, 0, and -1.
PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
allow any component to be :UNSPECIFIC. This has been voted in.
PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
symbols for the directory component.
PATHNAME-CANONICAL-TYPE proposes some new operations but does not
change the possible values of the type component.
PATHNAME-WILD proposes a portable way to test for implementation
dependent component values that indicate wildcard matching. It
does not change the possible values of any component.
Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):
The points of the proposal have been numbered to facilitate
amendments to remove or modify individual points.
When examining pathname components, conforming programs must be
prepared to encounter any of the following values:
1. Any component can be NIL, which means the component has not
been specified.
2. Any component can be :UNSPECIFIC, which means the component has
no meaning in this particular pathname.
3. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
4. The host, device, directory, name, and type can be strings.
5. The host and device can be a list, a structure, or a
standard-object at the discretion of the implementation.
6. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
7. The version can be any symbol or any integer. The symbol :NEWEST
refers to the largest version number that already exists in the file
system when reading, overwriting, appending, superseding, or directory
listing an existing file, and refers to the smallest version number
greater than any existing version number when creating a new file.
When constructing a pathname from components, conforming programs
must follow these rules:
11. Any component can be NIL. NIL in the host may mean a default host
rather than an actual NIL in some implementations.
12. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
13. The host, device, directory, name, and type can be strings.
14. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
15. The version can be :NEWEST.
16. Any component can be taken from the corresponding component
of another pathname on the same host and device.
17. An implementation might support other values for some
components, but a portable program cannot use those values.
An implementation might allow values to be transferred between
pathnames on different hosts or different devices, but a portable
program cannot rely on that.
A conforming program can use implementation-dependent values
but this can make it non-portable, for example, it might work
only with Unix file systems.
18. It is suggested, but not required, that implementations use
positive integers starting at 1 as version numbers, recognize
the symbol :oldest to designate the smallest existing version
number, and use keyword symbols for other special versions.
Consequences:
The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
are as follows:
The definition of "structured" component is restricted to lists,
structures, and standard-objects, rather than allowing any object
whatsoever.
"Structured" hosts are allowed, a generalization of CLtL's list
of strings.
"Structured" directories are replaced by PATHNAME-SUBDIRECTORY-LIST.
"Structured" names are forbidden.
The difference between what component values a program can depend
on being able to use, versus what component values a program must
be prepared to encounter, is clarified.
Rationale:
This should make it easier to write portable programs that deal with
pathnames and make it easier for implementors by clarifying the
framework into which they must fit. Also it should make it easier
to write the Common Lisp language specification by resolving some
things that were unclear about the status quo.
Adding "structured" hosts conforms to current practice.
Substituting a default host for NIL conforms to current practice
in implementations that require all pathnames to have a specific host.
Removing "structured" names should improve portability without causing
any harm, assuming no implementation uses structured names. This will
improve portability by allowing programs to do string manipulation on
names, although such programs still have to be careful since the valid
characters and maximum length of a name are implementation-dependent.
Disallowing transferral of nonstandard component values between
different hosts or different devices allows implementations to support
multiple incompatible file systems.
Current practice:
All versions of Symbolics Genera violate CLtL in the matter of hosts,
since it uses standard-objects as the host component. Genera deviates
slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
PATHNAME-COMPONENT-VALUE:SPECIFY.
Other implementations were not surveyed.
This proposal assumes that no current or planned implementation
uses structured names, not even for wildcards.
Cost to Implementors:
Most implementations already conform, except for the changes required
by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
the cost of this proposal itself should be minimal. It is conceivable
that an implementation may exist that has to change its pathname
representation, for example one that uses numbers as structured devices.
Cost to Users:
None.
Cost of non-adoption:
Pathnames will continue to be a poorly specified part of the language.
Performance impact:
None of any significance.
Benefits/Esthetics:
The boundary between the specified behavior of pathnames and the
implementation-dependent behavior of pathnames will be more clear.
Discussion:
A possible alternative to item 16 that's worth considering is:
16. Any component can be taken from the corresponding component
of another pathname. When the two pathnames are for incompatible
file systems (in implementations that support multiple file
systems), an appropriate translation occurs. If no meaningful
translation is possible, an error is signalled. The definition
of "appropriate" and "meaningful" is implementation-dependent.
This provides more useful behavior that conforming programs can
depend upon, but the behavior cannot be as precisely specified.
A significant amount of the Symbolics Genera pathname facility is
related to this capability, and it's used a lot in heterogeneous
networks, so maybe this is a useful capability that ought to be
called for in the language. The cost to implementors is small since
they could define "appropriate" and "meaningful" to be whatever is
easiest for them, if their users don't complain.
∂21-Mar-89 1629 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 16:29:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562415; Tue 21-Mar-89 19:29:06 EST
Date: Tue, 21 Mar 89 19:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: X3J13@SAIL.STANFORD.EDU
References: <19890317213333.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890322002858.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
This version is edited to clarify that the semantics of simple-array
are not being changed, and supersedes version 8 which you already saw.
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
f. There is no change to the meaning of the type SIMPLE-ARRAY, only
a clarification that a conforming program cannot assume that any
array is not simple.
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
A proposed alternative was to specify a way to create an array that is
guaranteed not to be simple. This would have required large changes
to some implementations and would be of little benefit to users.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
3. The following program is non-conforming. The consequences of this
program are undefined because the type declaration is violated in some
valid implementations.
(let ((a (make-array 100 :adjustable t)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
Pitman, Moon, Gabriel, and Steele support this amended proposal.
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂21-Mar-89 1732 CL-Compiler-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 17:32:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562475; Tue 21-Mar-89 20:32:29 EST
Date: Tue, 21 Mar 89 20:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
To: cl-compiler@SAIL.STANFORD.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903132248.AA02496@defun.utah.edu>
Message-ID: <19890322013216.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would go with MINIMAL for now. It leaves a lot of behavior
unspecified, and we can fill in that behavior later when we
add metaobjects to the standard.
Relatively small comments:
The compiler should be allowed to warn, but not error, about
failures of lambda-list congruence between methods or generic
functions in the file being compiled and methods or generic
functions in the Lisp doing the compilation. When you say
the compiler may not "perform tests" between these, it's not
clear whether you mean to rule out only errors or both errors
and warnings.
The only thing here that might be overspecification is allowing a
DEFINE-METHOD-COMBINATION to be used later in the same compilation.
However, I see no real harm in that, and it would often be
convenient for programmers, so leave it. But if someone else
moves to remove it, I will not object.
Evaluation of the form in EQL parameter specializer names in DEFMETHOD
needs to be covered. I think this is tied up with the pending compiler
committee issue DEFCONSTANT-VALUE (whose version 2 writeup I don't like,
it's too messy). The choices seem to be to require the form in an EQL
parameter specializer name to be evaluable at compile time, to require
it to depend only on constants defined in the file being compiled, or to
permit its evaluation to be deferred until load time. I don't like the
first choice. I think for both DEFCONSTANT and EQL the semantics should
be as if it were never evaluated until load time, with the compiler
allowed to evaluate it sooner only if it can prove that that does not
change the semantics. I'd be happier if the mechanism the compiler
uses to do this tentative evaluation were made available to the user,
but that can be deferred until metaobjects.
∂21-Mar-89 2048 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Mar 89 20:48:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01278g; Tue, 21 Mar 89 20:43:21 PST
Received: by challenger id AA22664g; Tue, 21 Mar 89 20:38:38 PST
Date: Tue, 21 Mar 89 20:38:38 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903220438.AA22664@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
People have continued to debate this issue. Part of the confusion is
what CLtL really says about simple arrays and adjustability. The
cause of the confusion is that various people have advanced difficult
to understand arguments and proposals (myself included).
As mentioned in the statement of ADJUST-ARRAY-NOT-ADJUSTABLE (Version
9), I agreed to support it, and I also agreed that it was a
clarification and not a change,
Because I had become confused by the issue, I decided to go back to
CLtL to find the consistent readings of the passages on simple arrays
and adjustability. As part of this exercise I tried to write up an
analysis of the possible interpretations of the the statements in
question. I often use this hermeneutical act to understand difficult
issues.
The result is that I think there are exactly two plausible consistent
readings, with one much more plausible than the other. Both readings
are inconsistent with ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9).
Therefore, I conclude that ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9) is
a change, not a clarification, and I must withdraw my agreement that
it is a clarification.
Whether we wish to adopt it is another question, to which I offer no
specific comment or suggestion. I am convinced that if some people
have read CLtL as meaning what ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
states and implemented simple arrays that way, we are in quite a bind.
The only minor comment I have is a general one: We should be wary of
changes (rather than clarifications) at this stage of standardization.
This message is very long and contains lots of close reasoning and
boring details. By its length and detail some might read it as a
strong criticism of the authors of ADJUST-ARRAY-NOT-ADJUSTABLE
(Version 9) - it really isn't (in fact, before I this exercise I
believed that the contents of ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
would be one of the plausible interpretations). It is simply what I
found and how I found it.
If you want to get to the heart of the matter, ask your text editor to
search for <<yoo-hoo>> and start reading there.
*************************
* Start of the Analysis *
*************************
In this message I will use the notation (S-i) to name statements;
(S-8) is to be read as ``statement 8.'' I will use (I-i-j) to name
interpretations of statments; (I-8-2) is to be read as ``the second
interpretation of statement 8.'' (I-7;8-4) is to be read as ``the
fourth interpretation of the statements 7 and 8 taken together.'' I
will use (*I-i-j) to name incorrect interpretations of statements;
(*I-8-2) is to be read as ``the (incorrect) second interpretation of
statement 8.'' I will use (C-i[J1,...,Jn) to name conclusions derived
from statements; (C-2[S-1,I-8-2]) is to be read as ``conclusion 2
derived from statement 1 and the second interpretation of statement
8.''
There are several relevant statements in CLtL.
(S-1) [from Page 28] An array that is not displaced to another array,
has no fill pointer, and is not to have its size adjusted dynamically
after creation is called a simple array.
(S-2) [from Page 288] :ADJUSTABLE: This argument, if specified and not
NIL, indicates that it must be possible to alter the array's size
dynamically after it is created.
(S-3) [immediately follows (S-2)] This argument defaults to NIL.
(S-4) [from Page 289] If MAKE-ARRAY is called with the :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO arguments each either unspecified or
false, the resulting array is a simple array.
(S-5) [from Page 293] This predicate [ADJUSTABLE-ARRAY-P] is true if
the argument (which must be an array) is adjustable, and otherwise
false.
(S-6) [from Page 297] It is not permitted to call ADJUST-ARRAY on an
array that was not created with the :ADJUSTABLE option.
(S-7) [immediately follows (S-6)] The predicate ADJUSTABLE-ARRAY-P may
be used to determine whether or not an array is adjustable.
First, let's look at the various interpretations of these statements.
***************************
* Interpretation of (S-1) *
***************************
The statement (S-1) appears to be in the form of a definition.
However, the phrase ``is called'' could be taken as a non-standard way
to introduce a definition and might instead be taken as a conditional
statement: Schematically, ``X's are called Y's'' could be taken to
mean ``If something is an X, then it is a Y.''
I don't think this is a plausible reading in a programming language
specification. Consider this sentence:
``A number that is divisible by 9 is called a well-tempered number.''
I think this is a fair definition. Certainly we would say that, by
this definition, the number 11 is not a well-tempered number.
Nevertheless, a possible interpretation of (S-1) could be:
(*I-1-1) If an array is not displaced to another array, has no fill
pointer, and is not to have its size adjusted dynamically after
creation, it is a simple array (and there may be simple arrays that do
not satisfy these properties).
However, if we look at the other statements in Chapters 2 and 17 we
see the use of ``is called'' throughout in what appears to be a
definitional sense. If (S-1) lacks definitional force, then so do
these statements:
Page 29: One-dimensional arrays are called vectors in Common Lisp
and constitute the type VECTOR (which is therefore a subtype
of ARRAY).
Page 29: All implementations provide specialized arrays for the cases
when the components are characters (or rather, a special subset of the
characters); the one-dimensional instances of this specialization are
called strings.
Page 29: All implementations are also required to provide specialized
arrays of bits, that is, arrays of type (ARRAY BIT); the
one-dimensional instances of this specialization are called bit
vectors.
Page 286: One-dimensional arrays are called vectors.
Page 286: Vectors whose elements are restricted to type STRING-CHAR
are called strings.
Page 286: Vectors whose elements are restricted to type BIT are called
bit-vectors.
Nothing but one-dimensional arrays are called or considered vectors,
and so I think ``is called'' can reasonably be interpreted only as
definitional.
I believe (*I-1-1) is not reasonable by the two arguments of incorrect
form for a conditional and the use of the ``is called'' form in
definitional senses elsewhere in Chapter 2.
I believe the definitional interpretation of (S-1) is this:
(I-1-1.5) Definition: An array is called a simple array if and only if
the array is not displaced to another array, has no fill pointer, and
is not to have its size adjusted dynamically after creation.
Further, I think the obvious meaning of (S-1) is this:
(I-1-2) Definition: An array is called a simple array if and only if
the array is not displaced to another array, has no fill pointer, and
cannot have its size adjusted dynamically after creation.
Another interpretation of (S-1) is possible. Note that the that the
phrase ``is not to have its size adjusted dynamically after creation''
is used rather than the less equivocal ``cannot have its size adjusted
dynamically after creation.'' One way to understand this phrasing is
as a stylistic device to produce the relatively uniform pattern ``an
array that is, ..., has, ... and is...'' rather than the relatively
non-uniform pattern ``an array that is, ..., has, ... and can....'' I
believe that this stylistic nuance is what Steele had in mind, but an
alternative is possible.
The alternative is derived as follows: If something ``is not to be''
acted upon in some particular way, then it is not the *intention* of
the actor to act upon that thing in that way. Therefore, we have the
alternative interpretation:
(I-1-3) Definition: An array is called a simple array if and only if
the array is not displaced to another array, has no fill pointer, and
is not intended to have its size adjusted dynamically after creation.
This results in a curious meaning for ``simple array.'' A simple array
is a legitimate type (SIMPLE-ARRAY appears on Page 34 in the sentence,
``SIMPLE-ARRAY is a subtype of ARRAY.'' It also appears on page 43 as
one the Common Lisp Standard Type Specifiers, and on Page 42 it
states, ``in Common Lisp, types are named by Lisp objects,
specifically symbols and lists, called type specifiers.''), and so it
must be possible to make such an array and to test objects for this
type. If (typep A 'simple-array) is true, then A is an array that,
among other things, was *intended* to not have its size altered
dynamically after creation.
There is another interpretation of (S-1), which interprets ``is not
to have'' as ``doesn't happen to have.''
(*I-1-4) An array that is not displaced to another array, has no fill
pointer, and doesn't happen to have its size adjusted dynamically
after creation is called a simple array.
I think this is an unlikely interpretation because it is clear that a
simple array can be created, and at the point of creation MAKE-ARRAY
would not know whether the size will happen to be adjusted later.
There is yet another interpretation of (S-1), but it cannot be presented
easily until after some other arguments have been made.
***************************
* Interpretation of (S-2) *
***************************
The statement (S-2) states that the argument :ADJUSTABLE can be used
to create an array whose size can be altered dynamically after
creation.
If (I-1-2) is the correct interpretation, then supplying a non-NIL
:ADJUSTABLE argument results in an array whose size *can* be altered
dynamically after creation, and so an array made this way is not a
simple array.
If (I-1-3) is the correct interpretation, then supplying a non-NIL
:ADJUSTABLE argument results in an array that is *intended* to have
its size altered dynamically after creation, and so an array made this
way is not a simple array.
(C-1[I-1-2,I-1-3,S-2]) Supplying a non-NIL :ADJUSTABLE argument to
MAKE-ARRAY results in a non-simple array. The basis for this
conclusion is the definitional nature of (S-1) regardless of the two
variants of the definition.
In fact, if we look at the statements regarding :FILL-POINTER and
:DISPLACED-TO, we see that if either of them is supplied and true, the
resulting array is also not simple (using the same argument used for
:ADJUSTABLE).
Therefore,
(C-2[I-1-2,I-1-3]) An array created with any one of :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO specified and non-NIL is not simple.
***************************
* Interpretation of (S-3) *
***************************
The statement (S-3) has a single interpretation.
***************************
* Interpretation of (S-4) *
***************************
The statement (S-4) states that if all three of the :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO arguments are unspecified or false, a
simple array is produced.
Combining this with (C-2) we get:
(C-3[S-4,C-2]) An array created with any one of :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO specified and non-NIL is not simple.
The force of (S-2) and (S-4) is that only a part of the type structure
of arrays is specified. There is definitely a way to create a simple
array, and definitely ways to create non-simple arrays, but whether
non-simple arrays are further distinguished based on the arguments
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO is not specified.
***************************
* Interpretation of (S-5) *
***************************
We will return to statement (S-5) later. Its interpretation is clear,
but which arrays are adjustable is not.
***************************
* Interpretation of (S-6) *
***************************
Statement (S-6) is quite tricky.
The problem is with the phrase ``is not permitted''; the question is
whether it is synonymous with ``is an error'' or whether it is
stronger.
The case for ``is not permitted"" being stronger than ``is an error''
is very compelling, I feel. First, taken as an English phrase, it is
strong: If you are not permitted to call ADJUST-ARRAY, then you do not
have permission to call it; in other words, you are not allowed to
call it, calling it is not tolerated, consent was not given to call
it, you do not have license to call it, you are not authorized to call
it, you do not have the opportunity to call it, it is not possible to
call it.
Second, ``is not permitted'' is not listed on Page 6 as one of the
phrases synonymous with ``is an error.'' If Steele wanted to actually
prohibit something, he would not be able to use the relatively
intuitive ``must not'' since that means ``is an error,'' which can be
taken to mean ``is allowed.'' That is, within the linguistic bounds of
CLtL it is possible to interpret the statement ``you must not do X''
as ``you are allowed to do X.''
The phrase ``is not permitted'' is used elsewhere in CLtL. The most
directly informative usage is on Page 72:
``The names NIL and T are constants in Common Lisp. Although they are
symbols like any other symbols, and appear to be treated as variables
when evaluated, it is not permitted to modify their values. See
DEFCONSTANT.''
Changing the values of NIL and T is a pretty serious offense. Steele
could have directly used the wording ``is an error,'' but he chose a
phrase not formally defined. He also could have said that NIL and T
are constants exactly like those defined by DEFCONSTANT, but he chose
informal wording that is stronger than ``is an error.'' Finally, the
advice to see DEFCONSTANT is given, almost as an afterthought.
Here is the main interpretation of (S-6):
(I-6-1) Calling ADJUST-ARRAY on an array that was not created with the
:ADJUSTABLE option is prohibited.
An array is ``adjustable'' if it is capable of being adjusted.
ADJUST-ARRAY is the only function in Common Lisp that can adjust an
array. Therefore, if ``calling ADJUST-ARRAY...is prohibited'' in some
situation, then that array is not adjustable in that situation. The
situation pointed out by (I-6-1) is that the ``array ... was not
created with the :ADJUSTABLE option.''
Combining this with (S-2) we get:
(C-4[I-6-1,S-2]) An array is adjustable if and only if the array was
created with the :ADJUSTABLE option.
Now let's look at the case for (S-6) being permissive.
The remark ``see DEFCONSTANT'' could be taken to mean that NIL and T
are simply constants and are to be treated that way, no more, no less.
Under DEFCONSTANT it states that altering the value of a constant ``is
an error.''
So here is the alternative:
(I-6-2) Calling ADJUST-ARRAY on an array that was not created with the
:ADJUSTABLE option is an error (that is, it is allowed).
***************************
* Interpretation of (S-7) *
***************************
On the face of it, (S-7) is a restatement of (S-5). The two
alternative readings result from either taking its presence as
relevant or irrelevant. That is, one can either believe that (S-7)
conveys some new information by its location relative to other
statements or that the reading of CLtL is as if (S-7) were deleted
I believe that essentially deleting (S-7) is not reasonable, mostly
because Steele is a better writer than that interpretation would
imply.
The fact that (S-7) immediately follows (S-6) implies that there is
some relation between them. In a two-sentence paragraph it is odd to
have the second sentence add no information to the first. The obvious
relation is that ADJUSTABLE-ARRAY-P is the predicate that can be used
to determine whether it is permitted to call ADJUST-ARRAY.
(I-7-1) ADJUSTABLE-ARRAY-P can be used to determine whether or not
ADJUST-ARRAY is permitted.
Consider (I-6-1). Using (C-4), since ADJUST-ARRAY can be called on
exactly those arrays that were created with the :ADJUSTABLE option,
and since ADJUSTABLE-ARRAY-P can be used to determine whether
ADJUST-ARRAY can be used, we get:
(C-5[C-4,S-5]) ADJUSTABLE-ARRAY-P can be used to determine whether or
not an array was created with the :ADJUSTABLE option.
Given this, following (S-6) with (S-7) is natural, because it serves
to reinforce the interpretation (I-6-1) because ADJUSTABLE-ARRAY-P
talks about adjustability.
Let's put (I-6-1), (I-7-1), and (C-5) together:
(I-6;7-1) ADJUST-ARRAY can be called only on adjustable arrays, that
is, only on arrays created with the :ADJUSTABLE option.
ADJUSTABLE-ARRAY-P can be used to determine whether an array was
created with the :ADJUSTABLE option.
Consider (I-6-2). The effect of (I-7-1) is to reinforce the
interpretation (I-6-2), because (S-7) states that ADJUSTABLE-ARRAY-P
must be used to determine adjustability, not the use of the
:ADJUSTABLE argument in MAKE-ARRAY.
We can rephrase (I-6-2) and (I-7-1) as follows:
(I-6;7-2) Calling ADJUST-ARRAY on an array that was not created with
the :ADJUSTABLE option is an error (that is, it is allowed); and
ADJUSTABLE-ARRAY-P can be used to determine whether or not it is
allowed.
**************************
* Interpretation of CLtL *
**************************
Now let's look at (I-1-2) and (I-1-3).
(I-1-2) can be taken either under (I-6;7-1) or under (I-6;7-2).
Under (I-6;7-1) and recalling (C-2), (C-3), and (C-4) we get:
Position 1: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. All simple arrays are not adjustable. An array
is adjustable if and only if it was created with the :ADJUSTABLE
option. ADJUSTABLE-ARRAY-P is false of all simple arrays.
There is an affinity between (I-1-2) and (I-6;7-1) because the
:ADJUSTABLE argument states whether it is possible to adjust the
array.
Under (I-6;7-2) and recalling (C-2) and (S-5), we get:
Position 2: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. A simple array may or may not be adjustable. An
array created with the :ADJUSTABLE option unspecified or NIL might be
adjustable. ADJUSTABLE-ARRAY-P can be used to determine whether an
array is adjustable.
This is weak because (I-1-2), (S-2), and (S-4) taken together implies
that the :ADJUSTABLE argument controls adjustability. (I-6-2) implies
that :ADJUSTABLE unspecified or NIL might result in an adjustable
array.
(I-1-3) must be considered under both (I-6;7-1) and (I-6;7-2).
Looking at (I-1-3) with (I-6;7-1), we get Position 1 again, because the
:ADJUSTABLE arguments signals intent to adjust an array. Here,
(I-6;7-1) implies that one cannot call ADJUST-ARRAY on an array that
was not intended to be adjusted. I feel this is a weak pair of
interpretations.
Looking at (I-1-3) with (I-6;7-2), we get Position 2 again. Here it is
allowed to call ADJUST-ARRAY on an array that wasn't intended to be
adjusted. There is some affinity between (I-1-3) and (I-6;7-2) because
the :ADJUSTABLE argument signals intention only. The only intention
that is required to be acted upon is specifying a non-NIL :ADJUSTABLE
argument, which must result in an adjustable array. If your intention
is to not adjust the array, you should not care whether it is actually
adjustable. Therefore, (I-6-2) is a sensibly paired with (I-1-3).
The variations of ``can not be adjusted'' and ``not intended to be
adjusted'' have little differential effect on the final
interpretations except insofar as Position 1 is stronger when paired
with (I-1-2) and Position 2 is stronger with (I-1-3). I believe that
the strength of the argument regarding ``is not permitted'' coupled
with the weakness the plausibility of a type being defined with
respect to intention combine to make Position 1 the stronger
interpretation.
*************************************
* Interpretation of (S-1) Revisited *
*************************************
Given the clearly definitional nature of (S-1), let's look at the
question of whether there is any basis in CLtL for an array created
with one of :ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO specified
and non-NIL to be simple.
The reasoning for such a situation is as follows: Under Position 2 it
is possible for a simple array to be adjustable. The expression
(MAKE-ARRAY n :ADJUSTABLE NIL) creates a simple array under Position
2, and so why shouldn't (MAKE-ARRAY n :ADJUSTABLE T), since MAKE-ARRAY
probably ignores the :ADJUSTABLE argument.
For this to be allowed, (S-1) must be a partial or conditional
definition. That is, (S-1) might be definitional, but only for
certain implementations, or part of the definition might apply only
for certain implementations. The remainder of the paragraph that
starts with (S-1) continues as follows:
(S-8) The user may provide declarations that certain arrays will be
simple.
(S-9) Some implementations can handle simple arrays in an especially
efficient manner; for example, simple arrays may have a more compact
representation than non-simple arrays.
(S-8) and (S-9) clearly imply that the reason for simple arrays is
efficiency. (S-8) talks about declarations provided by the user. When
a Common Lisp programmer provides a declaration that does not have
semantic import, this can signal only intention. Therefore, the
interpretation (I-1-3) would seem to make sense.
I believe that nothing in (S-8) and (S-9) alters the definitional
nature of (S-2). The most (S-8) and (S-9) could do is limit its
applicability of the definition. That is, neither (S-8) nor (S-9)
imply that (S-1) is not a definition, but they could modify the
conditions that the definition predicates.
The paragraph starting with (S-1) could be taken as a description of a
type that is useful only in implementations that act differently
according to the user's intentions as signaled by declarations. Since
(S-4) requires that some arrays be simple, implementations that have
no use for simple arrays are forced to have them.
Another interpretation of (S-1) is then:
(*I-1-5) An array that is not displaced, has no fill pointer, and has
been created with the intention not to have its size altered
dynamically after creation in an implementation that honors
declarations is a simple array.
I think this is a far-fetched reading, particularly since Steele
is capable of stating something like this much more precisely than
with the series (S-1), (S-8), and (S-9).
***********************
* End of the Analysis *
***********************
<<yoo-hoo>>
For those of you who could not stand to read the hermeneutic
arguments, here are the only two consistent readings of CLtL regarding
simple arrays and adjustability. I believe that Position 1 has the
stronger set of arguments behind it and is, I believe, the preferred
reading:
Position 1: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. All simple arrays are not adjustable. An array
is adjustable if and only if it was created with the :ADJUSTABLE
option. ADJUSTABLE-ARRAY-P is false of all simple arrays.
Position 2: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. A simple array may or may not be adjustable. An
array created with the :ADJUSTABLE option unspecified or NIL might be
adjustable. ADJUSTABLE-ARRAY-P can be used to determine whether an
array is adjustable.
Here are the points of ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9). I will
note whether each point is consistent with each of the two Positions
so that Version 9 can be seen to be a change rather than a
clarification:
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
This weakly contradicts Position 1, since Position 1 states which
arrays are adjustable and which aren't. It is consistent with
Position 2.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
This is simply (S-4).
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
This contradicts both Position 1 and Position 2.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
This is consistent with both Position 1 and Position 2.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
This contradicts Position 1 and is consistent with Position 2.
Let's also look at the ``Clarifications and Logical Consequences''
presented in the proposal:
a. Whether an array can be both simple and adjustable is unspecified.
This contradicts Position 1 and is consistent with Position 2.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
This contradicts Position 1 and is consistent with Position 2.
c. There is no specified way to create an array that is non-simple.
This contradicts both Position 1 and Position 2. In fact, this
contradicts (S-1) under any reasonable interpretation of it.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
This is consistent with both Position 1 and Position 2.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signaled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
This is consistent with both Position 1 and Position 2.
Therefore, ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9) is a change to
CLtL, and in fact, Point 3 (and Consequence C) is a major change.
-rpg-
∂22-Mar-89 0845 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 08:45:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562901; Wed 22-Mar-89 11:44:59 EST
Date: Wed, 22 Mar 89 11:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: Richard P. Gabriel <rpg@lucid.com>
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903220438.AA22664@challenger>
Message-ID: <19890322164453.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 21 Mar 89 20:38:38 PST
From: Richard P. Gabriel <rpg@lucid.com>
[603 lines deleted]
Therefore, ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9) is a change to
CLtL, and in fact, Point 3 (and Consequence C) is a major change.
Show us any conforming program that would be harmed by this change (if
it is a change, and I don't believe your arguments that it is a change)
"c. There is no specified way to create an array that is non-simple."
∂22-Mar-89 0931 X3J13-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 09:31:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562950; Wed 22-Mar-89 12:30:11 EST
Date: Wed, 22 Mar 89 12:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 2)
To: X3J13@SAIL.STANFORD.EDU
cc: Pavel.pa@XEROX.COM, GSB@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890322172956.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This proposal didn't quite make it to the January meeting, due to
unclear responsibilities for who was supposed to update it from the
discussion. I have filled the gap and made the changes implied by the
discussion back in December of last year. We can't vote on this if
someone invokes the two-week rule, but perhaps no one will.
Issue: SETF-MULTIPLE-STORE-VARIABLES
References: CLtL, pp.93-107
Lisp Pointers, v2n2, pp.27-41
Category: ADDITION
Edit history: Version 1, 5-Dec-88, Pavel
Version 2, 22-Mar-89, Moon, simplify, update from discussion
Problem description:
The description of GET-SETF-METHOD-MULTIPLE-VALUE on page 107 of CLtL
states that there are no cases in Common Lisp that allow multiple values
to be stored into a generalized variable. This is seen by some as an
arbitrary decision in light of the fact that a very reasonable semantics
exists for multiple values being assigned by several Common Lisp macros,
including SETF. The rationale on page 103 of CLtL suggests that this
decision might be changed in the future.
Proposal (SETF-MULTIPLE-STORE-VARIABLES:ALLOW):
Extend the semantics of the macros SETF, PSETF, SHIFTF, ROTATEF, and
ASSERT to allow "places" whose SETF methods have more than one "store
variable". In such cases, the macros accept as many values from the
newvalue form as there are store variables. As usual, extra values
are ignored and missing values default to NIL.
Extend the long form of DEFSETF to allow the specification of more
than one "store variable", with the obvious semantics.
Clarify that GET-SETF-METHOD signals an error if there would be more
than one store-variable.
Test Cases/Examples:
(defstruct region width height)
(defun region-size (region)
(values
(region-width region)
(region-height region)))
(defsetf region-size (region) (width height)
`(values
(setf (region-width ,region) ,width)
(setf (region-height ,region) ,height)))
(setf my-reg (make-region :width 10 :height 20))
=> #S(REGION :WIDTH 10 :HEIGHT 20)
(region-size my-reg)
=> 10
20
(setf (region-size my-reg) (values 30 40))
=> 30
40
(region-size my-reg)
=> 30
40
Rationale:
This change removes an artificial restriction on the semantics of
several Common Lisp macros, allowing a broader set of contexts in
which generalized variables can be used. For example, it is not
difficult to write a reasonable SETF method for the VALUES function,
yielding a powerful MULTIPLE-VALUE-SETF form:
(setf (values (car a) (gethash b 'c) (aref d 13))
(some-hairy-computation))
In the language as currently defined, this example would have to be
written:
(multiple-value-bind (x y z)
(some-hairy-computation)
(setf (car a) x
(gethash b 'c) y
(aref d 13) z))
Many other (perhaps more compelling) examples of generalized variables
holding more than one value can easily be imagined. Their use,
however, is severely discouraged by Common Lisp as defined in CLtL,
since none of the built-in macros will accept them.
The clarification of GET-SETF-METHOD makes explicit what is implied
by CLtL (CLtL uses the word "guarantee", whose relationship to
signalling of errors is unclear).
Current practice:
I do not know of any implementations that allow all of this extension.
Xerox Lisp does not signal an error, but this is probably due to a bug
in GET-SETF-METHOD. Lucid signals an error in GET-SETF-METHOD.
Symbolics Genera supports the proposal in SETF and PSETF, but not in
SHIFTF, ROTATEF, and ASSERT.
Cost to Implementors:
A relatively minor fix to each of the affected macros suffices. For
example, to fix SETF itself, one need only call
GET-SETF-METHOD-MULTIPLE-VALUE instead of GET-SETF-METHOD and emit a
MULTIPLE-VALUE-BIND instead of a LET for binding the store variables.
Cost to Users:
This is an upward-compatible change; no user code must change.
Cost of non-adoption:
Yet another non-uniformity in the language, yet another piece of
mechanism without a clear use (GET-SETF-METHOD-MULTIPLE-VALUE).
Benefits:
Wider applicability of a reasonably nice abstraction, the removal of
an artificial prohibition.
Aesthetics:
People may disagree about whether this is a simplification or not. I
am firmly on the side that believes that such removal of
non-uniformities is a simplifying force in the language.
Discussion:
Pavel supports this proposal.
Moon supports this proposal except he is not sure about the
inclusion of ASSERT.
GSB suggests that this is a clarification rather than an addition,
because the lack of any predefined setf-methods that use multiple
store variables should not mean that SETF, etc. should not work with
such a setf-method if the user defined one. The problem is that CLtL
examples such as the ones for SHIFTF on p.98 and the simplified
definition for SETF on p.107 contradict this proposal, and might have
been taken as specifications, rather than simplified examples, by
some readers.
Predefined SETF methods for such functions as VALUES, CONS, and VECTOR
could have been proposed, but we refrained. This proposal is necessary
to allow the user to write such methods for himself, but if this
proposal is adopted those setf-methods are very easy to write in
a portable fashion.
∂22-Mar-89 1401 X3J13-mailer **DRAFT** issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 14:01:14 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563174; Wed 22-Mar-89 17:00:57 EST
Date: Wed, 22 Mar 89 17:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue: PATHNAME-COMPONENT-CASE (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890322170040.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE NOW <<<
At this point, probably no one will read what you would write
anyway. Instead, think about the issue and organize your thoughts
for in-person discussion at the meeting.
There was a lot of discussion on this issue. The Cleanup committee is
not in agreement on its disposition. However, the issue is a real one
that we cannot afford to overlook. See additional comments at the end
for a survey of points of contention.
-kmp
-----
Issue: PATHNAME-COMPONENT-CASE
References: Pathnames (pp410-413),
MAKE-PATHNAME (p416),
PATHNAME-HOST (p417),
PATHNAME-DEVICE (p417),
PATHNAME-DIRECTORY (p417),
PATHNAME-NAME (p417),
PATHNAME-TYPE (p417)
Category: CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Issues of case in pathnames are a major source of problems.
In some file systems, the canonical case is lowercase, in some
uppercase, in some mixed.
In some file systems, case matters, in others it does not.
(NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
will produce an `ugly' file name like "FOO.LISP" in many (but not all)
Common Lisp implementations talking to Unix, for example.
(NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
might produce an `ugly' file name like "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"
in a Common Lisp implementation talking to a Tops-20.
Problems like this make it difficult to use MAKE-PATHNAME for much of
anything without corrective (non-portable) code.
Other problems occur in merging because doing
(NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
(PARSE-NAMESTRING "MY-UNIX:x.lisp")))
should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
"MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.
Problems like this make it difficult to use any merging primitives for
much of anything without corrective (non-portable code).
Proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE):
Designate a treatment for case in pathname components which is
distinct from the treatment of case in the namestrings. The treatment
should be invariant across operating systems.
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all uppercase, it is said to
designate a name in the system's "canonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all lowercase, it is said to
designate a name in the system's "anticanonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is mixed case, it is said
designate a name in exactly the indicated case.
Functions such as PARSE-NAMESTRING and NAMESTRING which convert
from or to native host syntax will perform any necessary conversions
from internal syntax.
Note: In fact, this proposal does not require an implementation to
change its internal representation. It only requires the CL-defined
accessors to behave as if the internal representation had been changed.
Whether the actual internal representation is changed is still up to an
implementation. A consequence of this is that if pathnames print
in a way that shows the components individually (such as #S), they
are not constrained to print the components in any particular case;
they are constrained only to have definite syntax conventions and to
be able to invert those conventions at the appropriate time. Any change
to the way pathnames print is beyond the scope of this proposal.
Test Case:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Rationale:
This does not solve the whole pathname problem, but it does improve
the situation for a clearly defined set of very common problems.
Current Practice:
Symbolics Genera implements this behavior.
Cost to Implementors:
While this proposal is compatible with CLtL, it may not be compatible with
the implementations of CLtL which some implementations have chosen.
It is possible to isolate the forced changes to the referenced functions
(MAKE-PATHNAME and the PATHNAME-xxx accessors). Existing functions can be
renamed, and new functions with the same name can be introduced which simply
encapsulate case conversion. No further change is forced.
It may, however, be desirable for an implementation to make a more complete
overhaul of their representation. In implementations where the implementors
feel a need to do this, the amount of work may be considerably greater.
Cost to Users:
Technically, this change is upward compatible.
In fact, since the existing CLtL spec is so poor, nearly everyone relies
heavily on implementation-specific behavior since there is little other
choice. As such, any change is almost certain to break lots of programs,
in usually superficial but nevertheless important ways. However, if we
really make the pathname facility more portable, the user community may be
willing to bear the consequences of these changes.
Cost of Non-Adoption:
We would be contributing to the perpetuation of the existing fiasco of a
pathname system.
Benefits:
The major costs of non-adoption would be avoided.
Aesthetics:
More code is required, but the code supports a simpler user model.
Anything that simplifies the user model of pathnames is going to be an
improvement.
Discussion:
Pitman suports PATHNAME-COMPONENT-CASE:CANONICALIZE.
-------------------------------------------------------------------
There was a lot of debate internally on CL-Cleanup about this one
which reached no resolution. Rather than include that discussion, I
will sum up what I think are the main discussion points:
- Uppercase was proposed as the canonical case because it seemed
most consistent with other parts of the language which are forced
to use a canonical case (such as symbol names and arguments to
macro character handlers).
Some people wish we would use lowercase because they think more
file systems are lowercase.
Note well that the choice of a case as the `canonical case'
internal to Lisp has no technical effect on your ability to
create filenames in upper, lower, or mixed case under this
proposal. This argument is purely an aesthetic one.
The Symbolics file system (upon which this proposal is based)
uses lowercase as the preferred case, and yet the use of uppercase
canonical case has caused no serious technical problems in the
five or so years that we've field tested this appraoch in
an environment that depends critically on heavy use of a variety
of file systems from the same lisp image. This is not a
pie-in-the-sky idea -- it is implemented and has stood the test of time.
- This proposal suggests that functions like PATHNAME-NAME return
and that make-pathname accept strings which are in the interchange
(canonical) case rather than in the native file system case so that
pathname components can be retrieved from one pathname and stored
in a second without regard to whether those two pathnames agreed on
native case.
Some people suggested that PATHNAME-NAME and MAKE-PATHNAME should
work non-portably, using native case information, and that you should
have to do more work (e.g., supply a keyword argument) to get portable
code. This strikes me as incompatible with our goals but is technically
a possible position to take.
Others suggested that two sets of functions should be available --
one set for native case (e.g., MAKE-FILENAME, FILENAME-NAME, ...)
and one for portable case (e.g., MAKE-PATHNAME, PATHNAME-NAME, ...).
These would make the same kind of object -- they would just support
different views on the set of operations that you might want on the
object. If you follow this approach, the issues become ``who gets
which names'' and ``does this make the language gratuitously bloated''?
Some people who wanted parallel paradigms (one for native case, one
for an interchange/canonical case) seemed to be willing to give up
that desire if the canonical case was coincidentally chosen to be the
same as the native case for the file system they worked with.
``I'll compromise as long as I don't have to change.''
- Some people don't use multiple file systems in the same core image
and don't realize how critical an issue this is to those of use who do.
THE BOTTOM LINE:
Users deal with this problem day in and day out as they move back and
forth between different systems. The solution is within our grasp
technically -- the key issues to be resolved are aesthetic and political,
not technical. In the end, users won't want to hear about the political
roadblocks. They are trusting us to come up with a solution and we should
come through. Please be prepared to come at this issue constructively. I
thank you, and our users will ultimately thank you.
∂22-Mar-89 1900 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 19:00:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 325245; Wed 22-Mar-89 21:59:33 EST
Date: Wed, 22 Mar 89 21:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
To: X3J13@SAIL.STANFORD.EDU
Message-ID: <19890323025928.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a last minute update of this issue to fix the problems found
during discussion of the previous version. I have fixed typos,
including some critical ones that made the proposal impossible to
understand, standardized terminology, and added specifications for
merging of relative directories and for the subset used in
non-hierarchical file systems.
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
22-Mar-89, Version 4 by Moon (fix based on discussion)
Status: Trying to be Released
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable value for the directory
component of a pathname, thus in order to denote a subdirectory, the
use of separators (such as dots, slashes, or backslashes) would be
necessary. The very fact that such syntax varies from host to host
means that although the representation might be "portable", the code
using that representation is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO", while in other implementations it would denote a top-level
directory, because "." is not the separator. To be safe, portable
programs must avoid all potential separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether
the directory delimiter characters are part of the string. eg, is
"foo" or "/foo" the directory component for a unix pathname
"/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the directory
component for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Remove the "structured" directory feature mentioned on CLtL p.412.
Allow the value of a pathname's directory component to be a list. The
car of the list may be either of the symbols :ABSOLUTE or :RELATIVE.
Each remaining element of the list is a string or one of the keyword
symbols listed below. Each string names a single level of directory
structure. The strings should contain only the directory names
themselves -- no separator characters.
A list whose car is the symbol :ABSOLUTE represents a directory path
starting from the root directory. The list (:ABSOLUTE) represents
the root directory. The list (:ABSOLUTE "foo" "bar" "baz") represents
the directory called "/foo/bar/baz" in Unix [except possibly for
alphabetic case -- that is the subject of a separate issue].
A list whose car is the symbol :RELATIVE represents a directory path
starting from a default directory. The list (:RELATIVE) has the same
meaning as NIL. The list (:RELATIVE "foo" "bar") represents the
directory named "bar" in the directory named "foo" in the default
directory [except possibly for alphabetic case -- that is the subject
of a separate issue].
In place of a string, at any point in the list, keyword symbols may occur
to indicate special file notations. The following symbols have standard
meanings; they may not be meaningful for all operating systems, and are
intended for use only on those operating systems where they have meaning.
Implementations are permitted to add additional keyword symbols if
necessary to represent features of their file systems.
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
"Syntactic" means that the action of :BACK depends only on the pathname
and not on the contents of the file system. "Semantic" means that the
action of :UP depends on the contents of the file system; to resolve
a pathname containing :UP to a pathname whose directory component
contains only :ABSOLUTE and strings requires probing the file system.
:UP differs from :BACK only in file systems that support multiple
names for directories, perhaps via symbolic links. For example,
suppose that there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :BACK "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
If a string is used as the value of the :DIRECTORY argument to
MAKE-PATHNAME, it should be the name of a toplevel directory and
should not contain any directory delimiter characters. Specifying a
string, str, is equivalent to specifying the list (:ABSOLUTE str).
Specifying the symbol :WILD is equivalent to specifying the list
(:ABSOLUTE :WILD-INFERIORS), or (:ABSOLUTE :WILD) in a
non-hierarchical file system.
The PATHNAME-DIRECTORY function never returns a string nor :WILD; it
always returns NIL, :UNSPECIFIC, or a list.
In non-hierarchical file systems, the only valid list values for the
directory component of a pathname are (:ABSOLUTE string) and
(:ABSOLUTE :WILD). :RELATIVE directories and the keywords
:WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file
systems.
Pathname merging treats a relative directory specially. Let
<pathname> and <defaults> be the first two arguments to
MERGE-PATHNAMES. If (PATHNAME-DIRECTORY <pathname>) is a list whose
car is :RELATIVE, and (PATHNAME-DIRECTORY <defaults>) is a list, then
the merged directory is the value of
(APPEND (PATHNAME-DIRECTORY <defaults>)
(CDR (PATHNAME-DIRECTORY <pathname>)))
except that if the resulting list contains an element other than :BACK
or :WILD-INFERIORS, immediately followed by :BACK, both of them are
removed. This removal of redundant :BACKs is repeated as many times
as possible. If (PATHNAME-DIRECTORY <defaults>) is not a list, the
merged directory is
(OR (PATHNAME-DIRECTORY <pathname>) (PATHNAME-DIRECTORY <defaults>))
A relative directory in the pathname argument to a function such as
OPEN is merged with *DEFAULT-PATHNAME-DEFAULTS* before accessing the
file system.
Test Cases/Examples:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:CANONICALIZE passes, only the 2nd return value.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "../baz.lisp")) ;on Unix
=> (:RELATIVE :UP)
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/../mum/baz")) ;on Unix
=> (:ABSOLUTE "foo" "bar" :UP "mum")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file
systems, which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory component by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
Implementations such as Genera that already have hierarchical directory
handling will have to make an incompatible change to switch to what
is proposed here.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES component to a
pathname, was discarded because it imposed an unnatural distinction
between a toplevel directory and its subdirectories. Pitman's guess is
the the idea was to try to make it a compatible change, but since most
programmers will probably want to change from implementation-specific
primitives to portable ones anyway, that's probably not such a big
deal. Also, there might have been some programs which thought the
change was compatible and ended up ignoring important information (the
:SUBDIRECTORIES component). Pitman thought it would be better if
people just accepted the cost of an incompatible change in order to
get something really pretty as a result.
Moon doesn't like having both :UP and :BACK, but admits that some
file systems do it one way and some do it the other.
To keep it simple, we chose not to add to this issue the functions
DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert
the name of a directory from or to the directory component of a file
inferior to that directory. This conversion is system-dependent, for
example TOPS-20 appends a type field and Unix does not. Also in some
systems the root directory has a name and in others it doesn't. Of
course these functions signal an error in non-hierarchical file
systems.
∂22-Mar-89 2031 X3J13-mailer Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 20:30:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563397; Wed 22-Mar-89 23:30:16 EST
Date: Wed, 22 Mar 89 23:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: X3J13@SAIL.STANFORD.EDU
Message-ID: <19890323043004.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I updated and rewrote this issue based on the discussion last Summer and
Autumn that followed the publication of version 1 within the cleanup
committee. Perhaps we can use this as the basis for a constructive
discussion and get this issue out of the way.
This issue contains four alternative proposals.
Issue: PATHNAME-COMPONENT-CASE
References: Pathnames (pp410-413),
MAKE-PATHNAME (p416),
PATHNAME-HOST (p417),
PATHNAME-DEVICE (p417),
PATHNAME-DIRECTORY (p417),
PATHNAME-NAME (p417),
PATHNAME-TYPE (p417)
Category: CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
22-Mar-89, Version 2 by Moon, update and rewrite
Status: Trying to be ready for release
Problem Description:
Issues of alphabetic case in pathnames are a major source of problems.
In some file systems, the customary case is lowercase, in some
uppercase, in some mixed. In some file systems, case matters, in
others it does not.
There are two kinds of portability problems connected with case in
pathnames: moving programs from one Common Lisp to another, and moving
pathname component values from one file system to another. To solve
the first problem, all Common Lisp implementations that support a
particular file system must use compatible representations for
pathname component values. To solve the second problem, there must be
a canonical representation for pathname component values that means
the same thing on all file systems.
The desire for a canonical representation for pathname component
values directly conflicts with the desire among programmers who only
use one file system to work with the local conventions and not to
have to think about issues of porting to other file systems. The
canonical representation cannot be the same as every local
convention, since they vary.
In the current anarchy of pathname component case conventions:
(NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
will produce foo.lisp in some Unix Common Lisp implementations
and will produce FOO.LISP in other Unix Common Lisp implementations.
(NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
will produce FOO.LISP in some Tops-20 Common Lisp implementations
and will produce "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"in other Tops-20 Common
Lisp implementations.
Problems like this make it difficult to use MAKE-PATHNAME for much of
anything without corrective (non-portable) code.
Other problems occur in merging because doing
(NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
(PARSE-NAMESTRING "MY-UNIX:x.lisp")))
should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
"MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.
Problems like this make it difficult to use any merging primitives for
much of anything without corrective (non-portable) code.
Proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE):
Designate a treatment for case in pathname components which is
distinct from the treatment of case in the namestrings. The treatment
should be invariant across operating systems. Namestrings use local
file system case conventions, pathname components use common case
conventions.
Arbitrarily choose uppercase as the common (or universal) case.
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all uppercase, it is said to
designate a name in the system's "canonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all lowercase, it is said to
designate a name in the system's "anticanonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is mixed case, it is said to
designate a name in exactly the indicated case.
Functions such as PARSE-NAMESTRING and NAMESTRING which convert from
or to local file system syntax will perform any necessary conversions
between "canonical case" and the host's customary case, and between
"anticanonical case" and the opposite of the host's customary case.
Proposal (PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS):
Add new pathname component accessor functions that return values
translated to the common case defined above. Use the local file
system case conventions in the existing pathname component accessor
functions. The new accessors are named PATHNAME-COMMON-DEVICE,
PATHNAME-COMMON-DIRECTORY, PATHNAME-COMMON-NAME, and
PATHNAME-COMMON-TYPE.
Add new keyword arguments to MAKE-PATHNAME that accept values in the
the common case defined above and translate to the host's customary
case. Use the local file system case conventions in the existing
keyword arguments to MAKE-PATHNAME. The new keyword arguments are
named :COMMON-DEVICE, :COMMON-DIRECTORY, :COMMON-NAME, and
:COMMON-TYPE.
Proposal (PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS):
Do everything proposed for PATHNAME-COMPONENT-CASE:CANONICALIZE,
and in addition:
Add new pathname component accessor functions that return values in
the local file system case conventions. The new accessors are named
PATHNAME-LOCAL-DEVICE, PATHNAME-LOCAL-DIRECTORY, PATHNAME-LOCAL-NAME,
and PATHNAME-LOCAL-TYPE.
Add new keyword arguments to MAKE-PATHNAME that accept values in the
local file system case conventions. The new keyword arguments are
named :LOCAL-DEVICE, :LOCAL-DIRECTORY, :LOCAL-NAME, and :LOCAL-TYPE.
Proposal (PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT):
Add a keyword argument :CASE to MAKE-PATHNAME and the PATHNAME-xxx
accessors, indicating whether common or local conventions should be
followed. The possible values for the argument are :COMMON and
:LOCAL. The default is :COMMON.
Test Case:
Under PATHNAME-COMPONENT-CASE:CANONICALIZE:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Under PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "foo"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
(PATHNAME-COMMON-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-COMMON-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Under PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
(PATHNAME-LOCAL-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "foo"
(PATHNAME-LOCAL-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Under PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :LOCAL) => "foo"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :LOCAL) => "FOO"
Rationale:
This does not solve the whole pathname problem, but it does improve
the situation for a clearly defined set of very common problems.
Together with the other pathname proposals, the behavior of pathnames
should be sufficiently consistent across Common Lisp implementations
and across file systems to allow portability of pathname-manipulating
programs.
Upper case is chosen as the canonical case for no better reason than
consistency with the canonical case for Lisp symbols.
PATHNAME-COMPONENT-CASE:CANONICALIZE minimizes the size of the
language by not adding any new functions. It assumes that pathname
operations using local file system conventions can be performed on
namestrings and that anything that calls MAKE-PATHNAME or the
PATHNAME-xxx accessors is portable code that is independent of the
local file system conventions.
PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS assumes that the existing
MAKE-PATHNAME and PATHNAME-xxx accessor features are for programs that
only work on one file system and that more generally portable programs
should use new features.
PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS assumes that the existing
MAKE-PATHNAME and PATHNAME-xxx accessor features are for fully
portable programs but that PATHNAME-COMPONENT-CASE:CANONICALIZE is
insufficient and direct access to the local conventions is required.
PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT assumes that access to both
conventions is necessary but introducing more functions is bad.
The default convention is the common one, assuming that most
programs are fully portable.
Note:
None of these proposals requires an implementation to change its
internal representation. They only require the canonical accessors to
behave as if the internal representation had been changed. Whether
the actual internal representation is changed is still up to an
implementation. A consequence of this is that if pathnames print in a
way that shows the components individually (such as #S), they are not
constrained to print the components in any particular case; they are
constrained only to have definite syntax conventions and to be able to
invert those conventions at the appropriate time. Any change to the
way pathnames print is beyond the scope of this proposal.
There should probably be a remark somewhere that says that portable
programs shouldn't expect to be able to create and/or access distinct
files whose pathname components differ only in case.
Current Practice:
Symbolics Genera implements something resembling
PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS except that the names use
"raw" rather than "local". The "raw" accessors are almost never used.
Symbolics Genera's own file system uses lower case as the customary
case, but transparent network access is available to file systems
using all known case conventions.
Many Common Lisp implementations that only deal with a single file
system implement something resembling
PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS except without the
new accessors and keyword arguments.
Cost to Implementors:
While all of these proposals are compatible with CLtL, since CLtL is
so vague, they are not likely to be compatible with the
implementations of CLtL which some implementations have chosen.
It is possible to isolate the forced changes to the referenced functions
(MAKE-PATHNAME and the PATHNAME-xxx accessors). Existing functions can be
renamed, and new functions with the same name can be introduced which simply
encapsulate case conversion. No further change is forced.
It may, however, be desirable for an implementation to make a more complete
overhaul of their representation. In implementations where the implementors
feel a need to do this, the amount of work may be considerably greater.
Cost to Users:
Technically, this change is upward compatible.
In fact, since the existing CLtL spec is so poor, nearly everyone relies
heavily on implementation-specific behavior since there is little other
choice. As such, any change is almost certain to break lots of programs,
in usually superficial but nevertheless important ways. However, if we
really make the pathname facility more portable, the user community may be
willing to bear the consequences of these changes.
Cost of Non-Adoption:
We would be contributing to the perpetuation of the existing fiasco of a
pathname system.
Benefits:
The major costs of non-adoption would be avoided.
Aesthetics:
More code is required, but the code supports a simpler user model.
Anything that simplifies the user model of pathnames is going to be an
improvement.
Discussion:
Some people would rather use lowercase as the canonical case. The
decision is essentially arbitrary. Everywhere else in Common Lisp
where there is a canonical case, uppercase was chosen.
It has been proposed that the Common Lisp specification should include
specifications of the exact behavior of pathnames for several popular
operating systems, so that multiple implementations for those
operating systems would be compatible with each other. This proposal
does not attempt to do that, only to establish the coherent framework
within which it would be done.
In PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT, some people want the
default for :CASE to be :LOCAL instead of :COMMON. I would have
written that up too, but I thought five proposals were too many.
∂23-Mar-89 0028 X3J13-mailer 20 March cs proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 00:27:44 PST
Date: Wed, 22 Mar 89 15:01:01 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890322.150101.baggins@almvma>
Subject: 20 March cs proposal
I've sent out the latest cs proposal again in LaTex format.
(Sorry, I have no public login and was unable to login to one
which Gregor offered.
Sandra, if possible please put a DVI file out on cs.utah.edu again)
I've again tried to incorporate many of the comments received. The
main features are:
-- The entire format was revamped! Appendix A no longer
exists; everything is in Chapter 2. The items which are
'voting' items are denoted by italized sections titled
PROPOSAL. All the proposals are numbered, some are
alternatives to prior proposals (and are marked ALTERNATIVE).
Anything not within a PROPOSAL section is simply discussion.
A fringe benefit is the document is only 22 pages.
-- I've tried to break up proposals which comments indicated
should be voted upon individually.
-- Some of the new/revised proposals suggested by comments:
-- Removing char-code-limit, char-code and code-char
-- Base-character is now based on
(upgraded-array-element-type 'standard-char)
-- A new function, find-external-char which returns
a character object given a coded character set
name and index.
-- Specifing the behavior of with-output-to-string
if no string is specified and
make-string-output-stream to produce a stream
that accepts all characters and returns
the most specialized string type that accommodates
the characters actually output.
-- Various 'too long' names were changed per comments.
For example, the new keyword argument to open is
now (simply) :external-code.
Regards,
Thom
∂23-Mar-89 0127 X3J13-mailer 20 March cs proposal part 1 of 1
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 01:25:02 PST
Date: Wed, 22 Mar 89 14:24:58 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890322.142458.baggins@almvma>
Subject: 20 March cs proposal part 1 of 1
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
Larry Masinter\thanks{Xerox Research} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{March 20, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newtheorem{prop}{Proposal}[section]
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
native languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
native languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many native
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
To universally identify each character, we define a unique
collection of repertoires called {\em character
registries} as a partitioning of all characters.
That is, each character is included
in one and only one character registry.
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character registry and a character label.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
Character data objects which are not graphic are classified
as {\em control}.
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities. For example, while Common LISP is free to
define unique manipulation facilities for characters, registries
and coded character sets, it should
not define standard coded character sets nor standard character
registries.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
A final purpose is to serve as a basis for terminology within the
standard language specification.
\begin{prop}
The terminology introduced in this proposal will be included
in the language specification at the discretion of the editor.
\end{prop}
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices.
The notion of attributes of character
objects within Common LISP has proven to be either not used or
not portable. The essential aspect of the following proposals is
to what extent attributes continue to be supported by the
language specifications.
\begin{prop}[Alternative A]
Remove all discussion of attributes from
the language specification. Add the following discussion:
\begin{quote}
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects. These and other
supported attributes are considered implementation-defined
attributes and if supported by an implementation effect the
action of selected functions.
\end{quote}
All types, constants and functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified as follows:
\begin{itemize}
\item Modify {\clkwd char-=}: If two characters differ in any
implementation-defined attributes, then they are not {\clkwd char-=}.
\item Modify {\clkwd char-<}: If two characters have identical
implementation-defined attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item Modify {\clkwd char-equal}:
The effect, if any, on {\clkwd char-equal} of each
implementation-defined attribute has to be specified as part of
the definition of that attribute (and similarly for
{\clkwd char-not-equal, char-lessp, char-greaterp,
char-not-greaterp, char-not-lessp}).
\item Modify {\clkwd char-upcase} and {\clkwd char-downcase}:
The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve implementation-defined attributes.
\item Modify {\clkwd read}: It is implementation dependent which
attributes are removed from symbol names.
It is implementation dependent which attributes are removed
from characters within double quotes.
\item Modify {\clkwd intern}: It is implementation dependent,
but consistent with the {\clkwd read} function,
which implementation-defined attributes are removed.
\item Modify {\clkwd digit-char}: remove the optional {\em font}
argument.
\item Modify {\clkwd code-char}: remove the optional {\em font}
and {\em bits} arguments.
\item Remove {\clkwd char-font-limit}
\item Remove {\clkwd char-bits-limit}
\item Remove {\clkwd int-char}
\item Remove {\clkwd char-int}
\item Remove {\clkwd char-bits}
\item Remove {\clkwd char-font}
\item Remove {\clkwd make-char}
\item Remove {\clkwd char-control-bit}
\item Remove {\clkwd char-meta-bit}
\item Remove {\clkwd char-super-bit}
\item Remove {\clkwd char-hyper-bit}
\item Remove {\clkwd char-bit}
\item Remove {\clkwd set-char-bit}
\item Redefine {\clkwd string-char} as implementation defined
as either {\clkwd base-character} or {\clkwd character}.
\item Modify readtable: If implementation-defined attributes
are supported, an implementation need not (but may) allow
for such characters to have syntax descriptions in the readtable.
Otherwise, all characters are representable in the readtable.
\end{itemize}
\end{prop}
\begin{prop}[Alternative B]
This is identical to all of Alternative A (above) except that
the function {\clkwd char-int} is retained for hashing purposes.
{\clkwd char-int} returns a non-negative integer encoding the
character object. The manner in which the integer is computed
is implementation dependent. In contrast to {\clkwd sxhash},
the result is not guaranteed independent of the particular
"incarnation" or "core image".
\end{prop}
With the elimination of {\em font} and {\em bits} from the
specification the usefulness of {\clkwd char-code} and {\clkwd
code-char} is diminished. They are no longer needed for constructing
characters.
The portable mechanisms for hashing are provided by
{\clkwd char-int} and {\clkwd sxhash}.
In addition, using {\clkwd char-code-limit} to iterate over
characters is extremely inefficient in implementations that
support large or user-defined repertoires.
\begin{prop}[Alternative C]
This an amendment to Alternative B (above).
\begin{itemize}
\item Remove {\clkwd char-code-limit}
\item Remove {\clkwd char-code}
\item Remove {\clkwd code-char}
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Standard and Semi-Standard Characters}
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional mechanisms,
such as in \cite{kurokawa88}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\begin{prop}
The discussion of standard characters is
replaced by the following:
Common LISP requires all implementations to support a {\em standard}
character subrepertoire.
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic Id categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
Id & Glyph & Name or description
& Id & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\end{prop}
The definition of semi-standard characters has been of minimum
practical use since implementations may or may not support any
of these characters. The essential feature is that, when
supported, they have a predictable treatment by the reader.
\begin{prop}
Remove all discussion of semi-standard characters.
Add that in implementations supporting control characters other than
\#$\backslash${\clkwd Newline}, the {\clkwd read} function
is required to treat those as
whitespace characters.
\end{prop}
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements need to
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to allow specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarly for the {\clkwd simple-string}
type specifier). This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
\begin{prop}
Define {\clkwd base-character} as {\clkwd
(upgraded-array-element-type 'standard-char)}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
(and character (not base-character))}
are referred to as {\em extended characters}.
\end{prop}
This establishes the relationship between the string encoding and
array upgrading strategies of the implementation and
the important character types.
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
\item
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}
\end{itemize}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, may
be privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However,
the proposal emphasizes that whether a character is "base" to
Common LISP depends on the way that an implementation represents
strings, and not any other properties of the implementation or the
host operating system. Imagine two implementations, one of which
encodes all strings as 16-bit characters, and another which has
two kinds of strings: 8-bit strings and 16-bit strings. In the
first implementation, the {\clkwd base-character} is
{\clkwd character}: there's only one kind of string. In the
second implementation, the {\clkwd base-character} would be those
that could be stored in an 8-bit string, and it would be a proper
sub-type of {\clkwd character}.
\subsection{String Type}
\begin{prop}
The {\clkwd string} type
is defined as
a union type. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of {\clkwd character}.
{\clkwd string} used as a type specifier for object creation
means {\clkwd (vector character)}.
\end{prop}
\begin{prop}
The following string
subtypes are
distinguished with standardized names.
\begin{itemize}
\item {\clkwd base-string} is equivalent to {\clkwd (vector
base-character)}.
Strings of type {\clkwd base-string} are referred to as {\em base
strings}. Strings which are not base strings are referred to
as {\em extended strings}.
\item {\clkwd general-string} is equivalent to {\clkwd (vector
character)}.
\item Both are valid as type specifiers that abbreviate.
\end{itemize}
During reader
construction of symbols, if all the characters
in the symbol's name are of type {\clkwd base-character},
then the name of the symbol may be stored as a base string.
Otherwise it will be stored as an extended string.
\end{prop}
\begin{prop}
Define {\clkwd simple-string} as a union type.
A simple
string is a specialized simple vector whose elements are of type
{\clkwd character} or a subtype of character.
{\clkwd simple-string} used as a type specifier for object creation
means {\clkwd (simple-array character ({\em size}))}.
\end{prop}
\begin{prop}
The following simple string
subtypes are
distinguished with standardized names:
\begin{itemize}
\item {\clkwd simple-base-string} is equivalent to {\clkwd
(simple-array base-character (*)). simple-base-string} is a subtype
of {\clkwd base-string}.
\item {\clkwd simple-general-string} is equivalent to {\clkwd
(simple-array character (*)). simple-general-string} is a subtype
of {\clkwd general-string}.
\item Both are valid as type specifiers that abbreviate.
\end{itemize}
\end{prop}
A base string is the most efficient string which can hold
the standard characters.
A {\clkwd general-string}
can contain any implementation supported base or extended characters,
in any mixture.
All Common LISP functions defined to operate on strings treat
base and extended strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coercion to an extended string.}
An implementation may support string subtypes in addition
to {\clkwd base-string} and
{\clkwd general-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic characters
might provide as extended characters:
\begin{itemize}
\item {\clkwd general-string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd general-string}s.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
\begin{prop}
Extend the {\clkwd make-string} function to allow an
{\clkwd element-type} keyword argument:
\begin{itemize}
\item {\clkwd make-string} {\em size}
{\clkwd \&key :initial-element :element-type} [Function]
This returns a simple string of length {\em size}, each
of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be
initialized in an implementation-dependent way. The
{\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type. If
{\clkwd :element-type} is omitted, the type {\clkwd character}
is the default.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Character Naming}
A Common LISP program should be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of character registry is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character registry name, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
\begin{prop}
Common LISP character codes are composed from a character registry and
a character label. The convention by which a character label and
character registry compose a character code is implementation
dependent.
\end{prop}
The naming and content of the standard character registries
is left unspecified by this proposal.
\footnote{The only constraint is that character registries and
labels be named using only the Latin capital letters A-Z and
digits 0-9.}
Below are some candidate character registry names:
\begin{itemize}
\item Arabic
\item Armenian
\item Bopomofo
\item Control (meaning the collection of standard text communication
control codes)
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item JapanesePunctuation
\item Kanji
\item Katakana
\item Latin
\item LatinPunctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive. The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?). It is application
programs which require a reliable definition of the
registry names and their constituents. The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.
\begin{prop}
Standardized Character Registries are fixed;
an implementation may not extend a standard registry's
constituent set of characters beyond the
standard definition.
An implementation may provide support for all or part of any
character registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any standard
character registry).
Implementation registries must be uniquely
named using only Latin capital letters A-Z and digits 0-9.
An implementation must document the registries it supports.
For each registry supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions. Character labels must be uniquely
named using only Latin capital letters A-Z and digits 0-9.
\item Reader Canonicalization.
\footnote{Any mechanisms by which the {\clkwd read} function treats
distinct characters as equivalent.}
\item Effect of character predicates. In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
supported are documented.
\end{itemize}
\end{prop}
We introduce new functions to
compose and decompose character objects. We also extend the
{\clkwd characterp} predicate to
support testing
membership of a character in a given character repertoire.
\footnote{
For example,
testing membership in the Japanese Katakana character repertoire.
}
A global variable {\clkwd *all-character-registry-names*}
is added to
allow application determination of
implementation supported character registries.
\begin{prop}
Add the type specifier and (modified) type predicate:
\begin{itemize}
\item {\clkwd (character {\em repertoire})}
This denotes a character type specialized to members of the
specified repertoire. {\em Repertoire} may be {\clkwd :base}
or {\clkwd :standard} or any supported character repertoire
name (a keyword symbol), or a list of names.
{\clkwd (character :base)} is equivalent to {\clkwd base-character}
and
{\clkwd (character :standard)} is equivalent to {\clkwd standard-char}
\item {\clkwd (characterp {\em object} \&optional
{\em repertoire})}
If {\em repertoire} is omitted, {\clkwd characterp} is true if
{\em object} is a character object, and otherwise is false. If
a {\em repertoire} argument is specified, {\clkwd characterp}
is true if {\em object} is a character object and a member
of the specified repertoire, and otherwise is false. {\em Repertoire}
may be any supported character repertoire name (a keyword symbol)
or the names {\clkwd :base} or {\clkwd :standard}.
{\clkwd (characterp x :standard)} is equivalent to
{\clkwd (standard-char-p x)}.
{\clkwd (characterp x :base)} is true if x is a member of the
base character repertoire.
\end{itemize}
\end{prop}
\begin{prop}
Add the following variable and functions:
\begin{itemize}
\item {\clkwd *all-character-registry-names*} {\em [Variable]}
The value of {\clkwd *all-character-registry-names*} is a list
of all character repertoire names (keyword symbols) supported by
the implementation.
\item {\clkwd char-label} {\em char [Function]}
{\clkwd char-label} returns a string representing the character
label of {\em char}. It is an error if the argument is
not a character object.
\item {\clkwd char-registry-name} {\em char [Function]}
{\clkwd char-registry-name} returns a string representing the character
registry to which {\em char} belongs. It is an error if the
argument is not a character object.
\item {\clkwd find-char} {\em registry label [Function]}
{\clkwd find-char} returns a character object. The arguments
{\em registry} and {\em label} are names (keyword symbols) of
a character registry and label. {\em label} uniquely
identifies a character within the character registry named
{\em registry}. If the implementation does not support the
specified character, {\clkwd nil} is returned.
\end{itemize}
\end{prop}
\begin{prop}
Character
names accepted and constructed by {\clkwd char-name, name-char,
and read} are extended to include character registry names of
the form {\em registry:label}.
\end{prop}
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
There are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
Given that multiple coded character sets exist, it is useful
to provide portable mechanisms based on their definitions.
\begin{prop}
Add the following functions:
\begin{itemize}
\item {\clkwd char-external-code} {\em char name [Function]}
{\clkwd char-external-code} returns the non-negative integer
representing the encoding of the character {\em char} in the
coded character set named by {\em name}, a keyword symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain the character,
{\clkwd nil} is returned.
\item {\clkwd find-external-char} {\em name index [Function]}
{\clkwd find-external-char} returns a character object.
The argument {\em index} is a non-negative integer
representing the encoding of a character in the
coded character set named by {\em name}, a keyword symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain the character,
{\clkwd nil} is returned.
\end{itemize}
\end{prop}
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
Which coded character sets and encoding schemes
are supported by the overall computing system and the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.
\begin{prop}
Add the additional keyword argument to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-code}
which
specifies a name, or list of names (keyword symbols)
indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
The default value is {\clkwd :default} and is
implementation defined but must include the
base characters.
As many coded character set names must be provided as the
implementation requires for that external coding convention.
Coded character set names must
include the full reference number and approval year. For example,
:ISO8859P1V1987 and :ISO6937P2V1983.
All implementation recognized schemes are formed from
the Latin uppercase A-Z and digit 0-9 characters.
\end{itemize}
This argument is provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream. (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)
\end{prop}
The existing default for the {\clkwd :element-type} argument of
{\clkwd open} is {\clkwd string-char}. This is no longer appropriate
given the diminished use of {\clkwd string-char} within the
standard specification.
\begin{prop}
Modify the {\clkwd :element-type} argument to {\clkwd open} as follows:
\begin{itemize}
\item Add {\clkwd base-character} as a valid type.
\item Remove {\clkwd string-char} as a valid type.
\end{itemize}
\end{prop}
The following alternative is consistent with the general
premise that portability is emphasized over efficiency.
\begin{prop} (Alternative A)
The default for the {\clkwd :element-type} argument of {\clkwd open}
is {\clkwd character}.
\end{prop}
The following alternative (B), allows implementations to match
the behavior of {\clkwd open} to the expected behavior of
their file systems.
\begin{prop} (Alternative B)
The default for the {\clkwd :element-type} argument of {\clkwd open}
is implementation defined as either {\clkwd base-character}
or {\clkwd character}.
\end{prop}
\begin{prop}
Modify the following functions:
\begin{itemize}
\item {\clkwd with-output-to-string} if no string argument is
provided, produces a stream that accepts all characters and returns
a string of the most specialized type
that accommodates the characters that were actually output.
\item {\clkwd make-string-output-stream}
produces a stream that accepts all characters and returns
(via {\clkwd get-output-stream-string})
a string of the most specialized type
that accommodates the characters that were actually output.
\end{itemize}
\end{prop}
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
This function is necessary
to determine if strings can be written to fixed length
fields in databases. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
\begin{prop}
Add the following function:
\begin{itemize}
\item {\clkwd string-encoded-length} {\em object}
{\clkwd \&optional} {\em output-stream} [Function]
{\clkwd string-encoded-length} returns the number of
implementation defined units required for the object on the
output stream. If not applicable to the output stream, the
function returns {\clkwd nil}. This number
corresponds to the current state of the stream and may change if
there has been intervening output. If the
output stream is not specified {\clkwd *standard-output*} is
the default.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Miscellaneous}
In the process of creating this document, some comments were found
within CLtL which seem appropriate to modify independently of
the other proposals mentioned previously. For each, we identify
the existing statement of CLtL and the recommended change.
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
\multicolumn{2}{l} }
\newcommand{\csdag}{\bf$\Rightarrow$\ddag}
\newcommand{\editstart}{}
\newcommand{\editend}{\\ & \end{tabular}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{prop}
\edithead {\csdag (p12) Chapter 2 Data Types}
\editstart
\\ \bf replace &
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\\ \bf with &
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\editend
\end{prop}
\begin{prop}
\edithead {\csdag (p25) Chapter 2 Symbols}
\editstart
\\ \bf replace &
\cltxt
A symbol may have uppercase letters, lowercase letters, or
both in its print name.
\\ \bf with &
\cltxt
A symbol may have characters from any supported character
repertoire (except control characters) in its print name.
\editend
\end{prop}
\begin{prop}
\edithead {\csdag (p163) Chapter 10 Symbols}
\editstart
\\ \bf replace &
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
It is an error to alter a symbol's print name.
\editend
\end{prop}
\begin{prop}
\edithead {\csdag (p168) Chapter 10 The Print Name}
\editstart
\\ \bf replace &
\cltxt
It is an extremely bad idea to modify a string being used
as the print name of a symbol.
\\ \bf with &
\cltxt
It is an error to modify a string being used
as the print name of a symbol.
\editend
\end{prop}
\begin{prop}
\edithead {\csdag (p249,make-sequence) Chapter 14 Simple Sequence
Functions}
\editstart
\\ \bf append &
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\editend
\end{prop}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂23-Mar-89 0702 X3J13-mailer Re: 20 March cs proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 07:02:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA01052; Thu, 23 Mar 89 08:02:48 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12413; Thu, 23 Mar 89 08:02:45 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231502.AA12413@defun.utah.edu>
Date: Thu, 23 Mar 89 08:02:44 MST
Subject: Re: 20 March cs proposal
To: Thom Linden <baggins@IBM.com>
Cc: Common Lisp mailing <x3j13@sail.stanford.edu>
In-Reply-To: Thom Linden <baggins@IBM.com>, Wed, 22 Mar 89 15:01:01 PST
> Sandra, if possible please put a DVI file out on cs.utah.edu again)
Done. It's in the same place as before, ~ftp/pub/cl-cs-proposal.dvi.
-Sandra
-------
∂23-Mar-89 0903 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:03:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563608; Thu 23-Mar-89 12:03:12 EST
Date: Thu, 23 Mar 89 12:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903220438.AA22664@challenger>
Message-ID: <19890323170307.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
It's not very important to me whether we call it a clarification
or a change. What's more important is that we agree on a definition
of simple-array and that we get this issue behind us so we can move
on and finish this standard, so we can all go home.
The fundamental question, I think, is whether simple-array is a
conceptual type or a representation type. I had assumed based on the
discussions that lead to the writing of CLtL, and on the lack of any
contradiction, that everyone agreed that it is a representation type and
all we had to do was state the details more clearly. Apparently I was
mistaken.
Let me explain what I mean by those terms. A conceptual type is one
that the programmer of a portable program thinks of as conceptually
distinct data. For example, RATIO is a conceptual type. No one thinks
a RATIO is another kind of CONS, and probably no one thinks a RATIO
is another kind of FLOAT. All implementations agree on which objects
are of type RATIO and which are not.
A representation type is one that is not a conceptually distinct form of
data. We have such types in the language in order to expose enough of
the implementation-dependent representation to permit user programs to
be specialized for one representation, so we can compile better code.
Representation types are a compromise between portability and
efficiency, and as such their definition is generally
implementation-dependent. We define just enough about a representation
type so a programmer can figure out whether to use it, but we do not
constrain all implementations to use the same representation. A
representation type is always a subtype of a conceptual type and
includes some, but not necessarily all, members of that conceptual type
that are implemented in some particularly efficient way. A good example
of a representation type is FIXNUM. Not all implementations agree on
which objects are of type FIXNUM. However, we have defined FIXNUM
closely enough (it includes a certain range of the integers, as well as
possibly some other integers) to allow a programmer to decide whether a
given variable in a given program can or cannot be declared FIXNUM. We
specify some integers that are guaranteed to be FIXNUM, but we do not
specify any integers that are guaranteed never to be FIXNUM in any
implementation.
Back to SIMPLE-ARRAY. If SIMPLE-ARRAY is a conceptual type, then an
array is a SIMPLE-ARRAY if-and-only-if it meets certain criteria, and
all implementations must agree on exactly which objects are of type
SIMPLE-ARRAY. Programmers would think of SIMPLE-ARRAYs as distinctly
different from ordinary arrays, and when programming would frequently
ask themselves "should I use a SIMPLE-ARRAY here or a regular ARRAY"
even when not thinking at all about efficiency or optimization. They
would write their program differently depending on whether they used
a SIMPLE-ARRAY or a regular ARRAY, just as they would write their
program differently depending on whether they used a LIST or a VECTOR.
On the other hand, if SIMPLE-ARRAY is a representation type, then an
array is a SIMPLE-ARRAY if-and-only-if it is implemented with a
simpler, more efficient representation than regular arrays. An array is
a SIMPLE-ARRAY if, but not only-if, it meets certain criteria. In other
words we define a common intersection of the SIMPLE-ARRAY types of
all implementations, but we allow implementations to expand their
SIMPLE-ARRAY types to include other arrays, as appropriate to their
machine, just like FIXNUM, BASE-CHARACTER, and (ARRAY (UNSIGNED-BYTE 4)).
Programmers would only ask themselves "should this be a SIMPLE-ARRAY"
when thinking about efficiency and optimization.
I believe SIMPLE-ARRAY is a representation type because, as a
programmer, I don't think of it as conceptually different from an
ordinary array, and because, as a historian, I know that SIMPLE-ARRAY
was added to Common Lisp in 1982, and attained its current form in 1983,
in order to address the concern of many implementors that using the
fully general representation for all arrays would be too slow, as a
result of the large number of array features in Common Lisp. The idea
was to permit use of a simpler, streamlined representation for some
arrays, and to make that representation available in TYPE declarations
so the compiler could optimize AREF on it.
To proceed, I think we should first reach a concensus on whether
SIMPLE-ARRAY is a conceptual or a representation type. Once we have
done that, we will have a framework within which to decide the specific
details of its behavior.
∂23-Mar-89 1504 X3J13-mailer **DRAFT** Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:07:40 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 563815; 23 Mar 89 15:06:56 EST
Date: Thu, 23 Mar 89 15:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890323150638.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE <<<
Bring your comments to the meeting.
See summary of CL-Cleanup discussion at end of message.
-kmp
-----
Issue: PATHNAME-CANONICAL-TYPE
References: MAKE-PATHNAME (p416)
Category: ADDITION
Edit history: 07-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
The pathame-type of ``Lisp'' and ``Compiled Lisp'' files vary widely from
implementation to implementation.
"LSP" is common on Vax VMS. "lisp" is generally used for the Symbolics
file system. "l" and "lisp" are common on Unix. Some Lisp implementations
use customized extensions such as "cl" or even "jcl" (eg, for "Joe's CL").
It would be useful to probe the existence of either a source or a binary
file, but that cannot currently be done portably. Furthermore, it would be
useful to create certain standard kinds of files in a system-independent
fashion.
A common desire, for example, is to do
(DEFUN FILE-NEEDS-TO-BE-COMPILED (FILE)
(LET ((SOURCE (PROBE-FILE
(MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???))))
(BINARY (PROBE-FILE
(MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???)))))
... (FILE-WRITE-DATE SOURCE) ... (FILE-WRITE-DATE BINARY) ...))
The problem is that there's nothing portable to put in the ??? positions.
Indeed, depending on the host (ie, file system) of the pathname, the
type might need to differ even in the same Lisp implementation. For example,
Symbolics Genera stores its source files in names like "foo.l" on Unix,
"FOO.LSP" on VMS, etc.
Proposal (PATHNAME-CANONICAL-TYPE:NEW-CONCEPT):
In addition to the normal strings and keywords currently allowed as fillers
of the TYPE field of a pathname, allow other keywords which designate
``canonical types''.
A canonical type is translated to a real type by MAKE-PATHNAME so that the
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE canonical-type)) is a string.
Introduce a new function PATHNAME-CANONICAL-TYPE which returns the canonical
type of an argument pathname, or the type if there is no canonical type.
For example,
(PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
[This information may be explicitly represented as an additional slot, or
computed on demand using a lookup table, as the implementor prefers.]
Define the following standard types:
:LISP ``Lisp'' (source) file
:BIN ``Compiled Lisp'' (object) file
Permit implementations to extend the set of canonical type names.
Test Case:
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :LISP))
=> "LSP" ;Typically, on VMS
=> "l" or "lisp" ;Typically, on Unix
=> "L" or "LISP" ;Typically, on Unix
; (assuming PATHNAME-COMPONENT-CASE:CANONICALIZE adopted)
..etc.
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :BIN))
=> "FAS" ;eg, VAXLISP
=> "BIN" ;eg, Symbolics file system
...etc.
(PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
(PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE "LSP"))
=> :LISP ;eg, VAXLISP
=> "LSP" ;eg, Unix
Rationale:
This is a useful subset of the functionality already available in
at least one implementation.
Current Practice:
Symbolics Genera implements this proposal.
Cost to Implementors:
The cost of implementing these proposed features is very slightly.
MAKE-PATHNAME would have to change to coerce its :TYPE argument in implementations
where it does not do so already. PATHNAME-CANONICAL-TYPE can be implemented as a
fairly straightforward lookup.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
It would continue to be hard to portably name files when their types
differed from file system to file system.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Some programs would be able to abstract away from the particulars of the host
file system entirely. Some people believe this would be a definite improvement
in aesthetics.
Discussion:
Note that different Lisp implementations which share the same file system,
need not and perhaps should not agree on the same type string for the
canonical type :BIN. That is, if I store source files on VAX VMS and compile
them both for use under Symbolics Genera and VAXLISP, then it is both
appropriate and useful that VAXLISP :BIN files be named "something.FAS"
and Genera :BIN files be named "something.BIN" since then they wouldn't
clobber each other.
Pitman supports PATHNAME-CANONICAL-TYPE:NEW-CONCEPT.
-------
Summary of discussion on CL-Cleanup:
GZ suggested :COMPILED-LISP was suggested as a better name than :BIN.
Masinter thought :SOURCE-LISP might be better than :LISP. Either of these
would be gratuitously incompatible with Symbolics Genera, which already
implements canonical types, but otherwise not technically unreasonable
and probably something we should discuss.
Sandra Loosemore offered the following revealing piece of code from her
work and asked why we couldn't just do this.
(defvar *binary-file-type*
#+Symbolics (make-pathname :type "bin")
#+(and dec common vax (not ultrix)) (make-pathname :type "FAS")
#+(and dec common vax ultrix) (make-pathname :type "fas")
#+pcls (make-pathname :type "b")
#+KCL (make-pathname :type "o")
#+Xerox (make-pathname :type "dfasl")
#+(and Lucid MC68000) (make-pathname :type "lbin")
#+(and Lucid VAX VMS) (make-pathname :type "vbin")
#+excl (make-pathname :type "fasl")
#+system::cmu (make-pathname :type "sfasl")
#+PRIME (make-pathname :type "pbin")
#+HP (make-pathname :type "b")
#+TI (make-pathname :type "xfasl")
"The default file type for compiled files.")
The reason is that some implementations (e.g., Symbolics) deal with more
than one file system type -- and properly the information varies with the
file system type, not with the implementations. [Since most implementations
have only one associated file system type, this may not be obvious, but it's
quite obvious on a Symbolics machine that you vary the extension name based
on the host file system requirements.]
Moon suggested a compromise where *compile-file-output-type* (his name
for Sandra's *binary-file-type*) existed but could be either a canonical
type or a physical type.
Masinter worries about the PATHNAME-CANONICAL-TYPE part of the proposal
being forced to be heuristic in some cases. [Will any alternative be any
less heuristic? -kmp]
Moon wanted the following example to be guaranteed to work:
(PATHNAME-CANONICAL-TYPE (PATHNAME "foo.lisp")) => :LISP
where of course the string is implementation-dependent. That is,
PATHNAME-CANONICAL-TYPE must produce a canonical type even when the
pathname was not constructed from a canonical type, but instead came
from user typein, the TRUENAME function, the DIRECTORY function,
or some similar source, when the pathname's type is one that a
canonical type maps into.
Moon also thought it would be nice to have a facility for users
(in addition to implementations) to extend the set of canonical type
names, since users may well have their own types of files. However,
he admitted that the difficulty is that in any system that supports
multiple file systems, it has to be complex enough to allow
specification of separate mappings for each file system, which in
turn requires a way to name file system types. [At this point, we
probably don't have time left in our schedule to produce such a
facility. -kmp]
∂23-Mar-89 1503 X3J13-mailer **DRAFT** Issue: PATHNAME-EXTENSIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:47:13 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563798; Thu 23-Mar-89 14:47:01 EST
Date: Thu, 23 Mar 89 14:46 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: PATHNAME-EXTENSIONS (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890323144641.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS MESSAGE <<<
It's probably so late that no one will read what you have to say
anyway. Ponder it and bring your comments to the meeting.
Summary of debate on CL-Cleanup follows at end.
-kmp
-----
Issue: PATHNAME-EXTENSIONS
Forum: Cleanup
References: Pathnames (pp410-413)
Category: ADDITION
Edit history: 28-Dec-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is quite strict about what may and may not be in any kind of
pathname, leaving implementors up against a brick wall when an
idiosyncratic extension is necessary to uniquely and usefully
represent all files in a particular file system which may not have
been completely anticipated by the Common Lisp designers.
Proposal (PATHNAME-EXTENSIONS:NEW-PREDICATE):
Introduce a function COMMON-PATHNAME-P, described as follows:
COMMON-PATHNAME-P pathname [Function]
Returns true if its argument satisfies the Common Lisp
pathname model, and false otherwise. If the argument is
not a pathname, an error of type TYPE-ERROR is signalled.
Clarify that COMMON-PATHNAME-P considers a pathname's host field
to fit the Common Lisp pathname model if the filler of the host
field is a string (naming a host), and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's device to fit
the Common Lisp pathname model if it is a string naming a device,
or NIL, or :WILD[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC
passes, is :UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's directory
field to fit the Common Lisp pathname model if the filler of the
directory field is NIL, or :WILD, or a string[, or, if issue
PATHNAME-SUBDIRECTORY-LIST passes, is a list described as valid
by that proposal][, or, if issue PATHNAME-COMPONENT-UNSPECIFIC
passes, is :UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's name to
fit the Common Lisp pathname model if it is a string, or NIL,
or :WILD, and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's type to
fit the Common Lisp pathname model if it is a string, or :WILD,
or NIL[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC passes, is
:UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname's version to
fit the Common Lisp pathname model if it is a positive integer,
:WILD, or NIL, or :NEWEST[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC
passes, is :UNSPECIFIC], and not otherwise.
Clarify that COMMON-PATHNAME-P considers a pathname to be outside
the Common Lisp model if it contains special syntax or purpose
which is not readily apparent to Common Lisp programs. For example,
if a character like "*" or "~" has special meaning to the file
system, then strings like "F*X" or "~FOO" which exploit that syntax
are not considered to "fit the model". [Note that if issue
PATHNAME-WILD passes, WILD-PATHNAME-P might still be true of
some pathnames that were not COMMON-PATHNAME-P.]
Test Case:
;; On Unix...
(common-pathname-p (make-pathname :name "f*x"))
=> nil
;; On Tops-20...
(common-pathname-p (make-pathname :name "FOO" :version -1))
;; On VMS...
(common-pathname-p (parse-namestring "x::y::z::w::[joe]a.b"))
=> nil
;; Normally
(common-pathname-p (make-pathname :name "FOO" :version :wild))
=> t
(common-pathname-p (make-pathname :name "FOO" :version 17))
=> t
Rationale:
The purpose of COMMON-PATHNAME-P is not to detect pathnames which
are not valid. Indeed, no Common Lisp function requires that its
argument satisfy this test; it is assumed that functions such as
OPEN and MERGE-PATHNAMES will recognize and deal appropriately with
whatever special pathname syntax is appropriate to the host operating
system. Rather, the purpose of COMMON-PATHNAME-P is to help Common
Lisp programs which try to pick apart a pathname and perform some
sort of simulated merging on the basis of the simple pathname model
put forth by Common Lisp, so that such programs can detect situations
which are beyond their capabilities.
Current Practice:
Probably nobody implements this.
Cost to Implementors:
Small. The program is fairly straightforward. It could almost be
written as a portable library if it weren't for detecting special
characters that have some special syntax.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Some idiosyncratic system syntax would be hard to detect.
Making extensions to the pathname system in a way that Common Lisp
users would not be forced to trip over would be more difficult.
Benefits:
Some ad-hoc user code which tries to do the same thing could be
eliminated. Portable programs which must prompt for native pathname
syntax, and deal with the result of having parsed it could be more
robust.
Making idiosyncratic extensions to the pathname system would be much
less prone to cause problem for portable programs which used this
facility.
The presence of this operator could someday ease the transition
into a future, incompatible pathname system.
Aesthetics:
Probably improves aesthetics slightly by giving people who want to
reject extended pathnames a more reliable way of weeding them out.
Discussion:
The COMMON data type was probably intended to have this same purpose.
Unfortunately, since no one ever really said specifically enough what
was in COMMON or not, and why, it never really caught on. Hopefully
this proposal is definite enough on such issues to not be useless.
Pitman thinks this is probably a good idea.
------- Summary of debate -------
Discussion on CL-Cleanup centered around two issues:
- Is this really needed? What could it be used for?
I suggested following program as an illustration:
(DEFUN TRANSLATE-LOGICAL-PATHNAME (LPATHNAME)
(MULTIPLE-VALUE-BIND (LHOST LDEVICE LDIR LNAME LTYPE LVERSION)
(PARSE-LOGICAL-PATHNAME LPATHNAME)
(MULTIPLE-VALUE-BIND (PHOST PDEVICE PDIR PNAME PTYPE PVERSION)
(TRANSLATE-PATHNAME-COMPONENTS LHOST LDEVICE LDIR LNAME LTYPE LVERSION)
(LET ((PHYSICAL-PATHNAME (MAKE-PATHNAME :HOST PHOST ...)))
(UNLESS (COMMON-PATHNAME-P PHYSICAL-PATHNAME)
(CERROR "Use ~*~A anyway."
"The result of translating pathname ~A to a physical pathname~
~%resulted in a valid physical pathname, ~A,~
~%but that pathname has special meaning to host ~A which may~
~%not have been what was intended."
LPATHNAME PHYSICAL-PATHNAME PHOST))))))
Also, recently there has been concern (e.g., in issue
PATHNAME-SUBDIRECTORY-LIST) about requirements for conformance
precluding interesting extensions that particular implementations
might want to experiment with. This would provide a way for portable
programs to guard against such `creative' extensions.
- Isn't this something users could write?
The answer is no. What is a non-portable pathname cannot be portably
detected. e.g., the fact that "*" or "~" or "{" or whatever is magic
in some filename syntax and not in another is (almost by definition) not
something that is portably detectable. Portable programs can just decide
to limit themselves to the least common denominator (e.g., refusing to let
you type in any pathname to a prompt for pathname if it has an `scary
looking' character in it), but this provides a way of being both a little
more robust and a little more tolerant.
For those who are curious, I'm not adamant about this proposal. I just
want it to be available as an option in case it eases the discussion on
other issues.
-kmp
∂23-Mar-89 1503 X3J13-mailer issue CLOS-MACRO-COMPILATION, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:35:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10107; Thu, 23 Mar 89 12:35:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12651; Thu, 23 Mar 89 12:35:31 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231935.AA12651@defun.utah.edu>
Date: Thu, 23 Mar 89 12:35:30 MST
Subject: issue CLOS-MACRO-COMPILATION, version 3
To: x3j13@sail.stanford.edu
This is a revised version of the writeup that was sent out last week.
The major change is to the language about error situations under
DEFMETHOD.
Forum: Compiler
Issue: CLOS-MACRO-COMPILATION
References: CLOS chapters 1 & 2 (88-002R)
CLOS chapter 3 (89-003)
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION
Edit History: V1, 10 Mar 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore
V3, 21 Mar 1989, Sandra Loosemore (fix error language)
Status: Ready for release
Problem Description:
Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?
A part of the problem is that we do not currently have a full
understanding of all the issues involved. In particular, work on
defining the CLOS meta-object protocol is still in progress. The goal
of this proposal is to say enough about the behavior of these macros
in the standard so that users can use them portably in compiled code,
but to leave as much of the behavior as possible unspecified to avoid
placing undue restrictions on the meta-object protocol.
There are two proposals, MINIMAL and NOT-SO-MINIMAL.
Proposal CLOS-MACRO-COMPILATION:MINIMAL:
State that top-level calls to the CLOS defining macros have the
following compile-time side-effects. Any other compile-time behavior
is explicitly left unspecified.
DEFCLASS:
* The class name becomes a type specifier which may appear in
subsequent type declarations.
* The class name can be used to name a superclass in a subsequent
DEFCLASS.
* The class name can be used as a specializer in a subsequent
DEFMETHOD.
DEFGENERIC:
* The generic function can be referenced in a subsequent DEFMETHOD.
* The generic function is not callable at compile-time.
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function.
The error-signalling behavior described in the specification of
DEFMETHOD in CLOS chapter 2 (if the function isn't a generic function
or if the lambda-list is not congruent) happens only at run time,
not at compile time.
DEFINE-METHOD-COMBINATION:
* The method combination can be used in a subsequent DEFGENERIC. If it
is referenced, the body of a long form of method combination must be
evaluable at compile-time.
Rationale:
The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
DEFTYPE.
DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
function definition to the compile-time environment. Since generic
functions may be freely redefined between compile and run time (just
like any other function), a method may end up "belonging" to a
different generic function at load time than at compile time. This
is why it is inappropriate to signal errors about congruency problems
(etc) until the method is actually added to the generic function at
run time.
Some implementations compose effective methods at compile time, which
requires evaluating the body of the DEFINE-METHOD-COMBINATION at
compile time.
Proposal CLOS-MACRO-COMPILATION:NOT-SO-MINIMAL:
This is the same as proposal MINIMAL, except under DEFCLASS add:
* The class may be instantiated at compile-time. Provided the
appropriate methods are also defined at compile-time, this implies:
- The class can be used as the :METACLASS option of a later DEFCLASS.
- It can be used as the :GENERIC-FUNCTION-CLASS or :METHOD-CLASS option
of a DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS.
Rationale:
Being able to instantiate a class at compile-time is somewhat more
convenient for users.
Current Practice:
The items listed under DEFCLASS in proposal MINIMAL are fairly standard
programming style.
Flavors does not support compile-time instantiation of classes. It
does not make method combinations available at compile-time either, but
Moon considers that to be a bad design choice.
Cost to implementors:
Unknown.
Cost to users:
Unknown, but probably fairly small.
Note that for proposal NOT-SO-MINIMAL, users still have to ensure that
any methods on the class which may be invoked at compile-time are
fully defined. This includes the INITIALIZE-INSTANCE and
SHARED-INITIALIZE methods that are invoked by MAKE-INSTANCE.
Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
definitions will make sure they are fully defined at compile-time.
Alternatively, the definitions could be placed in a separate file,
which is loaded before compiling the file that depends on those
definitions.
Benefits:
Programmers can rely on programs that use the CLOS defining macros
being able to compile correctly in all implementations, without having
to wrap explicit EVAL-WHENs around every macro call.
Discussion:
This writeup is based on discussions between Moon, Gray, and
Loosemore, who are mostly in agreement on the things presented in
proposal MINIMAL. We have purposely avoided saying anything about
whether meta-objects representing the classes, methods, etc. get
created at compile-time, or whether such meta-objects are fully or
partially defined. The basic questions addressed by this issue are
what kinds of things can be defined and then used during compilation
of the same file that defines them, and what restrictions might apply.
These proposals are not completely compatible with the meta-object
protocol document (89-003). Gregor Kiczales says:
No one believes that what is written in draft 10 of the MOP is valid.
Sandra Loosemore says:
Although I admit I don't understand all of the issues involved with
the meta-object protocol, I prefer proposal MINIMAL over
NOT-SO-MINIMAL. I don't think leaving the issue of whether or not
classes can be instantiated at compile-time unspecified places an
undue burden on users, and it does leave more freedom for the
meta-object protocol to decide what the right behavior really is.
Dick Gabriel notes:
The question I have about the process going on with respect to the
CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
CLOS under various compilation/evaluation situations is being
over-specified.
At this stage of the game I worry that we might go a little too far in
one direction in specification when we are actually engaged in design
work. This isn't intended to be a criticism of any committees, but I
would feel a lot more comfortable with a conservative specification
that defined well-formed programs being loaded or compiled in fresh
Common Lisps with a pretty simple eval-when model that is easier to
specify and which makes it easy for all but the hairiest
compilation-environment-frobbing programs to be written.
-------
∂23-Mar-89 1504 X3J13-mailer Issue: PATHNAME-WILD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:11:23 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563820; Thu 23-Mar-89 15:11:10 EST
Date: Thu, 23 Mar 89 15:10 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 2)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890323151049.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE <<<
Please just ponder it and bring your comments to the meeting.
My notes say that at the Fairfax meeting, we (the Cleanup committee)
thought this was ready for vote. This was held up in hopes of a unified
pathname proposal which did not materialize, and then got lost in the
shuffle.
-kmp
-----
Issue: PATHNAME-WILD
References: Pathnames (pp410-413)
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards. For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
The CL pathname model does not provide a way to represent such wildcards,
which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
recognized by portable code as containing a wildcard.
CL code needs to at least be able to detect and possibly to manipulate
such wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTION):
Introduce the following function:
WILD-PATHNAME-P pathname &optional field-key [Function]
Tests a pathname for the presence of wildcard components.
If the first argument is not a pathname an error is signalled.
If no field-key is provided, or the field-key is NIL, this function
returns true if the argument pathname has any wildcard components.
Otherwise, it returns false.
If a non-null field-key is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, it returns true
if the argument pathname is wild in the indicated component. Otherwise,
it returns false.
Test Case:
#1: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
#2: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
#3: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
#4: (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
#4: (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
Rationale:
If the programmer can at least detect wild pathnames reliably,
he can know to do something useful (give up, merge out the bothersome
components, call DIRECTORY for a list of matching pathnames, etc.)
Current Practice:
Presumably no implemenation supports the proposal exactly as stated.
Symbolics Genera provides the ability to do
(SEND pathname :WILD-P)
which returns a value such as NIL, :NAME, :TYPE, etc. In the case
that more than one field is wild, however, some information is lost.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcarded code to write it (often more heuristically).
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
situations which CL pathnames cannot represent.
Benefits:
Portable user interfaces that prompt users for pathnames could more
reliably detect wildcard pathnames and more easily guard against
embarrassing behavior in such situations.
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
Pitman supports PATHNAME-WILD:NEW-FUNCTION.
It would have been possible for this function to have accepted
a string as an argument (coercing it to a pathnames), but that
would have entailed adding an optional host argument. We opted
not to do this.
There was some question about the name. The name PATHNAME-WILD-P
suggests a ``slot'' of a pathname (like PATHNAME-HOST),
while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
The committee was split on what to call it. Since it is more
like a type than a slot, the name WILD-PATHNAME-P was chosen.
∂23-Mar-89 1503 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:40:15 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10248; Thu, 23 Mar 89 12:40:04 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12657; Thu, 23 Mar 89 12:39:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231939.AA12657@defun.utah.edu>
Date: Thu, 23 Mar 89 12:39:58 MST
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 5
To: x3j13@sail.stanford.edu
This version of the writeup has had a few changes made to the error
language in items 2 and 3.
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
V4, 08 Mar 1989, Sandra Loosemore (wording changes)
V5, 22 Mar 1989, Sandra Loosemore (fix error language)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled. At what time (compiletime or runtime) are certain
kinds of definitions "captured"? What happens if these definitions
are not consistent at both compile and run times?
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
The process of compilation causes certain kinds of information present
in the compiletime environment to be captured and incorporated into
the resulting compiled code. Other kinds of information may not be
captured until the compiled code is actually run.
Specifically:
(1) The following information *must* be present in the compiletime
environment for the program to be compiled correctly. This
information need not also be present in the runtime environment.
(a) In conforming code, macros referenced in the code being compiled
must have been previously defined in the compiletime environment.
The compiler must treat any form that is a list beginning with
a symbol that does not name a macro or special form as a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) In conforming code, proclamations for SPECIAL variables must
be made in the compiletime environment before any bindings of
those variables are processed by the compiler. The compiler
must treat any binding of an undeclared variable as a lexical
binding.
(2) The compiler *may* incorporate the following kinds of information
into the code it produces, if the information is present in the
compiletime environment and is referenced within the code being
compiled. Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code. It is also
permissible for implementations to signal an error at runtime to
complain about the discrepancy. In all cases, the absence of the
information at compiletime is not an error, but its presence may
enable the compiler to generate more efficient code.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) The compiler can assume that type definitions made with DEFTYPE
or DEFSTRUCT in the compiletime environment will retain the same
definition in the runtime environment. It may also assume that
a class defined by DEFCLASS in the compiletime environment will
be defined in the runtime environment in such a way as to have
the same superclasses and metaclass. This implies that
subtype/supertype relationships of type specifiers will not
change between compiletime and runtime. (Note that it is not
an error for an unknown type to appear in a declaration at
compiletime, although it is reasonable for the compiler to
emit a warning in such a case.)
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the runtime behavior of the program is
undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime.
Rationale:
This proposal generally reflects current practice.
Current Practice:
There don't seem to be any compilers around that do not implement the
provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
Several people have expressed reservations about items 2b and 2c, saying
that self-tail-recursion optimization and block compilation should not
be the default behavior of the compiler. Gail Zacharias responds:
This item [2c] has nothing to do with whether anybody does it by
default. The question is whether an end user can take a Common Lisp
program whose internals he's not familiar with, block-compile it, and
be guaranteed that it will continue to function correctly. This item
says that yes, a correct CL program must explicitly indicate what
functions in the source it will redefine at runtime. I don't think
this places such a great burden on the programmer. Without this
provision, only somebody intimately familiar with a program could know
whether it can be safely block-compiled, making block-compilation
useless in the context of portable CL programs.
This thing about "block compilation shouldn't be the default" seems to
come up every time this item is discussed. That's an environment
question and is not addressed by the proposal. The proposal simply
says that block compilation should be legal.
-------
∂23-Mar-89 1503 X3J13-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED, v.6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:25:28 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 89 12:07:04 PST
Date: 23 Mar 89 12:06 PST
From: masinter.pa@Xerox.COM
to: x3J13@sail.stanford.edu
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED, v.6
Message-ID: <890323-120704-5187@Xerox>
This issue was tabled from the Jan. 89 meeting, and amended
by Barry Margolin as discussed there.
!
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256);
NCONC, NRECONC (p269); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
15-Mar-89, Version 5 by Margolin (amendments discussed in
Hawaii, removed -NOT functions)
17-Mar-89, Version 6 by Margolin (make NSUBSTITUTE* less vague)
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE-EXCEPT-NCONC-AND-NSUBSTITUTE):
[This proposal name is getting way out of hand!]
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is defined using the following recursive relationship:
(NCONC) => NIL
(NCONC NIL . args) == (NCONC . args)
(NCONC arg) => arg
(NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
and returns arg1
(NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)
[If a previous cleanup issue prohibited NIL as a non-last argument
then ignore the (NCONC NIL . args) case.]
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
is required to SETF any CAR (if SEQUENCE is a list) or VREF (if it's
a vector) of SEQUENCE which is required to be replaced with
NEW-OBJECT. If SEQUENCE is a list, it none of the CDRs of the
top-level list may be modified. These functions, therefore, may be
used in for-effect-only positions in code (some may find this
stylistically distasteful, though).
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
For NCONC...
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
In the case of NCONC, however, the precise definition is useful because
it is what users expect, it is how NCONC has been defined for many
years, and it is how current implementations generally work. It may
not always be the most efficient way (e.g. it may result in invisible
pointers in CDR-coded implementations), but callers of NCONC probably
use it specifically for its precise side effects.
In the case of NSUBSTITUTE, this seems like the only reasonable
implementation mechanism, and there doesn't seem to be a reason not to
guarantee it.
Current Practice:
All valid implementations are believed to comply with the vague
definitions. Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
conform to the NCONC spec.
Cost to Implementors:
None. This is probably the status quo for most implementors. If there
are any implementations that don't implement NCONC and NSUBSTITUTE as
above (which I doubt) they will have to be changed.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Tightening the definition of NCONC and NSUBSTITUTE permits users to
predict their programs' behavior more precisely.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Implementors have less flexibility in implementing NCONC efficiently.
This is true of NSUBSTITUTE, but this is less likely to cause problems.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
In the case of NCONC, this implementation flexibility, and hence
potential performance improvements, is sacrificed.
If anyone ever invents CAR-coding, the required implementation of
NSUBSTITUTE could be a performance hindrance.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
NCONC is a "less abstract" function than the rest of the functions
described above. It is usually used precisely because of the way it
interacts with list implementation. Similarly for NSUBSTITUTE.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre supported version 4. [I don't know how they feel
about v6 -- Barmar].
Moon supports version 6.
∂23-Mar-89 1504 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 10
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:13:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11279; Thu, 23 Mar 89 13:13:03 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12687; Thu, 23 Mar 89 13:13:00 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232013.AA12687@defun.utah.edu>
Date: Thu, 23 Mar 89 13:12:58 MST
Subject: issue COMPILER-DIAGNOSTICS, version 10
To: x3j13@sail.stanford.edu
This writeup has also had some minor changes to error terminology
made, under the section on warnings (2b). I've also added a couple of
notes to the discussion section on issues that have come up but that
have not yet been resolved.
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Issue CONDITION-RESTARTS
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
V9, 26 Jan 1989, Sandra Loosemore (simplify)
V10, 22 Mar 1989, Sandra Loosemore (error terminology)
Status: Ready for release
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
of WARNING.
(2) Clarify that ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) The compiler is permitted to signal diagnostics about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
calls to function with wrong number of arguments
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation. State that
both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler. If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it. If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.
(4) Specify that COMPILE-FILE returns two values. The first value
is the truename of the output file, or NIL if the file could not be
created. The second value is T if the file was compiled without
errors, or NIL if errors were signalled during compilation.
Rationale:
Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.
Requiring any condition handlers established by the compiler to resignal
the condition before proceeding with any implementation-specific action
gives user error handlers a chance to override the compiler's default
behavior. For example, the user error handler could invoke a restart
such as ABORT or MUFFLE-WARNING.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire compilation if it is not feasible to abort a
smaller part.
Requiring a second success-p value to be returned from COMPILE-FILE
gives the user some indication of whether there were serious problems
encountered in compiling the file.
Test Case/Example:
Here is an example of how COMPILE-FILE might set up its condition
handlers. It establishes an ABORT restart to abort the compilation
and a handler to take implementation-specific action on ERROR
conditions. Note that INTERNAL-COMPILE-FILE may set up additional
ABORT restarts.
(defvar *output-file-truename* nil)
(defun compile-file (input-file &key output-file)
(let ((*output-file-truename* nil)
(errors-detected nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((error #'(lambda (condition)
(setq errors-detected t)
(signal condition)
...)))
(internal-compile-file input-file output-file)))
(values *output-file-truename*
errors-detected)))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
Explicit calls to ERROR don't really justify warnings to be signalled
at compile-time, but we assume implementors have some common sense
about when it's appropriate to do so.
Proposal CONDITION-RESTARTS:PERMIT-ASSOCIATION would make it illegal
for conditions to be resignalled. If that proposal is accepted, the
wording here would have to be changed to indicated that the compiler's
condition handler makes a copy of the condition and signals that.
Moon says:
I think [requiring the ABORT restart to be handled] is wrong. The only
documentation of the ABORT restart that I could find says
The purpose of the ABORT restart is generally to allow return to the
innermost ``command level.''
I agree with this, and I believe it means that it is wrong for any
function other than one that establishes a read-eval-print loop or
a command-level to establish an ABORT restart. It would be useful
to have some restart that aborts a portion of the compilation, but
it should be given some other name.
-------
∂23-Mar-89 1503 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:56:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10754; Thu, 23 Mar 89 12:56:42 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12677; Thu, 23 Mar 89 12:56:39 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231956.AA12677@defun.utah.edu>
Date: Thu, 23 Mar 89 12:56:37 MST
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 5
To: x3j13@sail.stanford.edu
Some people have spoken up in favor of restoring the proposal FLUSH
that was present in an earlier version of this proposal, so here it is
(combined with a further change to COMPILE that some people have
requested). It's my impression that proposal FLUSH has more support
now than it used to.
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue LOAD-TIME-EVAL (passed)
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Issue COMPILE-ARGUMENT-PROBLEMS
Category: CLARIFICATION
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
V3, 10 Feb 1989, Sandra Loosemore (new proposal)
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
with other pending proposals)
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
Status: Ready for release
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
The proposals presented below present a simple model of the
compilation process. A minimal compiler could be implemented to
perform a code walk to apply the indicated transformations to the
function source code. Of course, most compilers will perform other
transformations as well, such as translating the Lisp source code into
a representation that is more compact or which can be executed more
efficiently.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls appearing lexically within the function have
already been expanded and will not be expanded again when the
function is called. (See CLtL p. 143.) The process of
compilation effectively turns MACROLET and SYMBOL-MACROLET
constructs into PROGNs with all instances of the local macros
in the body fully expanded.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within
the function are to be treated as lexical or special.
- COMPILER-LETs nested lexically within the function will not bind
any variables when the function is called (CLtL p. 112). Again,
the process of compilation effectively turns COMPILER-LET
constructs into PROGNs with all macros in the body fully expanded.
- Lexically nested EVAL-WHENs have been processed as stated in
proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
an implicit PROGN or as the constant NIL.
- If the function contains lexically nested LOAD-TIME-VALUE forms,
these have already been pre-evaluated and will not be evaluated
again when the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for functions that are
not COMPILED-FUNCTIONs to satisfy the above criteria.
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It assigns some specific properties to compiled functions. Users would
be able to rely on any function which is of type COMPILED-FUNCTION having
really been (at least partially) compiled.
It also states what many people believe to be the minimum functionality
required of a compiler.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN-COMPILE:
(1) Clarify that functions produced by COMPILE, or defined in a file
produced by COMPILE-FILE which has been subsequently LOADed, must
satisfy the same requirements listed in section (1) of proposal
TIGHTEN.
(2) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It also states what many people believe to be the minimum functionality
required of a compiler.
However, it allows functions that have not been compiled also to be of
type COMPILED-FUNCTION. For implementations that do not use different
representations for interpreted and compiled functions, it would still
allow COMPILED-FUNCTION and FUNCTION to be synonymous, even if
interpreted functions do not satisfy the requirements for compilation.
Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:
(1) Remove the type specifier COMPILED-FUNCTION and the predicate
COMPILED-FUNCTION-P from the language.
(2) Clarify that functions defined in a file produced by COMPILE-FILE
which has been subsequently LOADed, must satisfy the same
requirements listed in section (1) of proposal TIGHTEN.
(3) Remove the language from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY
that says "it is an error" to try to COMPILE a function that was
defined interpretively in a non-null lexical environment.
Instead, state that if COMPILE cannot compile the function, it
should simply behave as an identity operation.
Rationale:
Distinguishing between compiled and non-compiled functions is of
little use to portable programs.
Some people believe that it should be valid to call COMPILE on any
function, and that it should be legitimate for COMPILE to do nothing.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation. It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.
Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
Cost to implementors:
Unknown, but probably small for either proposal. Proposal
TIGHTEN-COMPILE is probably most consistent with current practice.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One use of the COMPILED-FUNCTION type is in declarations. A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION. However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION. Both of the proposals presented require COMPILE
and COMPILE-FILE to construct compiled functions.
Moon says:
I much prefer the option FLUSH...
This type has no portable meaning and never should have existed.
Pierson says:
What I (and believe Kent) want is a guarantee that [COMPILE] won't
signal an error; if nothing else works COMPILE will simply apply
#'IDENTITY to the symbol's function. Specifically, it should be
legal and safe to attempt to speed up my current program(s) by
doing:
(DO-SYMBOLS (SYM <my-package>)
(WHEN (FBOUNDP SYM) (COMPILE SYM)))
-------
∂23-Mar-89 1512 X3J13-mailer issue COMPILER-LET-CONFUSION, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:07:47 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17346; Thu, 23 Mar 89 16:07:29 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12792; Thu, 23 Mar 89 16:07:25 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232307.AA12792@defun.utah.edu>
Date: Thu, 23 Mar 89 16:07:23 MST
Subject: issue COMPILER-LET-CONFUSION, version 8
To: x3j13@sail.stanford.edu
This version fixes the bug in the example code that was pointed out
earlier, and clarifies the relation between COMPILER-LET and
DEFINE-OPTIMIZER.
There has been some discussion that COMPILER-LET might be implemented
by storing its variable bindings in the lexical environment. Some of
us think that this would result in a significant change to the
semantics of COMPILER-LET that would be inappropriate to pursue at
this time, and in any case there hasn't been a proposal submitted yet
that addresses all of the issues involved.
Issue: COMPILER-LET-CONFUSION
Forum: Compiler
References: CLtL p. 112
Issue DEFINE-OPTIMIZER
Category: CHANGE
Edit History: V1, 27 Sep 1988, Sandra Loosemore (initial version)
V2, 04 Oct 1988, Sandra Loosemore (add another example)
V3, 31 Oct 1988, Sandra Loosemore (only proposal ELIMINATE)
V4, 08 Jan 1989, Kent M. Pitman (new alternative)
V5, 09 Jan 1989, Sandra Loosemore (discussion)
V6, 08 Mar 1989, Sandra Loosemore (general updating)
V7, 13 Mar 1989, Sandra Loosemore (fix bug from V6)
V8, 23 Mar 1989, Sandra Loosemore (fix another bug, add
to discussion)
Problem Description:
The description of the COMPILER-LET special form in CLtL is confusing
to many people. There are no examples provided to make it clear how it
is supposed to be used. The only description which is offered is overly
concrete, which has led to confusion about the intent of COMPILER-LET,
and about its implementability.
The intent of COMPILER-LET was to permit information to be communicated
between macros by use of dynamic variables at macroexpansion time.
It was not necessary to the intended uses of COMPILER-LET that such
variables ever be bound at execution time.
Unfortunately, probably because some implementations did not primitively
support COMPILER-LET at the time CLtL was written, an exception was
permitted to make COMPILER-LET `more or less work' in interpreters:
the COMPILER-LET variables were permitted to be bound at execution time.
The problem was further compounded by the fact that CLtL presented this
exception as part of COMPILER-LET's contract rather than as an
implementation note, and by the fact that no examples of actually using
COMPILER-LET correctly are provided.
One particular case where problems have resulted is a situation like
(compiler-let ((*v* 1))
#'(lambda () (m)))
where M is a macro that refers to *V*. In some implementations, M is
not macroexpanded until the dynamic extent of the *V* binding has
ended.
Subtle bugs can be introduced because of the different handling of the
variable bindings in the interpreter and the compiler. In compiled
code, the bindings are only lexically visible during the expansion of
macros at compile time, while in interpreted code the bindings have
dynamic scope and may also be seen during ordinary evaluation if
evaluation and macroexpansion happen "in parallel".
Further compatibility problems can result from the value forms being
evaluated in a null lexical environment in the compiler and the ordinary
lexical environment in the interpreter.
Background and Analysis:
It should be clear up front that COMPILER-LET is not computationally
essential. Most (if not all) uses of it can be rewritten using MACROLET
or SYMBOL-MACROLET.
A typical use of COMPILER-LET might be:
(defvar *local-type-declarations* '())
(defmacro local-type-declare (declarations &body forms)
`(compiler-let ((*local-type-declarations*
(append ',declarations *local-type-declarations*)))
,@forms))
(defmacro typed-var (var)
(let ((type (assoc var *local-type-declarations*)))
(if type `(the ,(cadr type) ,var) var)))
(defun f (x y)
(local-type-declare ((x fixnum) (y float))
(+ (typed-var x) (typed-var y))))
The same thing could be accomplished using MACROLET:
(defmacro local-type-declare (declarations &body forms)
(local-type-declare-aux declarations forms))
(defmacro typed-var (var) var)
(eval-when (eval compile load)
(defun local-type-declare-aux (declarations forms)
`(macrolet ((typed-var (var)
(let ((type (assoc var ',declarations)))
(if type `(the ,(cadr type) ,var) var)))
(local-type-declare (new-declarations &body new-forms)
(local-type-declare-aux
(append new-declarations ',declarations)
new-forms)))
,@forms)))
A further alternative would be to use SYMBOL-MACROLET (this particular
implementation assumes that issue DEFINING-MACROS-NON-TOP-LEVEL passes):
(let ((temp (gensym)))
(defmacro local-type-declare (declarations &body forms &environment env)
`(symbol-macrolet ((,temp ',(append declarations
(symbol-macro-value temp env))))
,@forms))
(defmacro typed-var (var &environment env)
(let ((type (assoc var (symbol-macro-value temp env))))
(if type `(the ,(cadr type) ,var) var)))
)
(defun symbol-macro-value (symbol env &optional default)
(multiple-value-bind (expansion macro-p) (macroexpand symbol env)
(if macro-p (eval expansion) default)))
Opinion is divided as to which is more understandable. Some
people find the COMPILER-LET idiom more understandable (assuming that
it can be made to work consistently in compiled and interpreted
code), while others find it just as natural to use MACROLET or
SYMBOL-MACROLET.
The issues are these:
- Is it possible to implement COMPILER-LET in a usefully consistent
way in all implementations?
- Are the benefits of providing a useful and compatible implementation
of COMPILER-LET worth any associated cost?
Two proposals are presented below:
- Option REPAIR argues that COMPILER-LET provides interesting
functionality that can be implemented in a manner that is usefully
consistent across implementations, and that the associated cost
is low enough for it to be worthwhile to do so.
- Option ELIMINATE argues that COMPILER-LET complicates the language
and that providing this construct is not worth the associated
implementation cost.
Proposal (COMPILER-LET-CONFUSION:REPAIR):
Strike the existing definition of COMPILER-LET. Redefine it as follows:
COMPILER-LET [Special form]
COMPILER-LET is similar to LET, but it always makes special
bindings and makes those bindings visible only during
macroexpansion of forms in the body, not during the runtime
execution of those forms.
If proposal DEFINE-OPTIMIZER:NEW-FACILITY is accepted, then
optimizer functions are also executed in a dynamic environment
in which COMPILER-LET bindings are visible.
The intent is that some macros might macroexpand into calls to
COMPILER-LET in which the body would the contain references to
macros which access the variables in the COMPILER-LET.
The initial value forms of the bindings, if any, are always
evaluated in a null lexical context, regardless of whether the
COMPILER-LET expression is being interpreted or compiled.
The initial value forms of the bindings, if any, are evaluated in
a dynamic context where the bindings of any lexically enclosing
COMPILER-LET are visible, and where dynamic execution-time
environment may or may not be visible.
Implementation Note: Permitting the execution-time dynamic
environment to be visible when initializing COMPILER-LET variables
is a concession to some interpreters which may have to do this in
order to keep the cost down. Where feasible, implementors should
try not to make the runtime environment visible.
Rationale:
This gives a consistent description of COMPILER-LET which separates
issues of intent from those of implementation in a way that makes it
possible for portable code to make serious use of it, and which does
not force gratuitous incompatibilities between interpreters and
compilers.
This description of COMPILER-LET can be implemented without undue
cost by all implementations. See "Cost to Implementors" for details.
Cost to Implementors:
Modest, but nontrivial in some implementations.
In compiled code, and in interpreters doing a one-time semantic
prepass, it should be fairly easy for COMPILER-LET to cause the
variables to get bound (using PROGV) during semantic analysis.
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'(LAMBDA (BINDING) (EVAL (CADR BINDING))) BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
This reduces the problem of writing a program capable of doing a
full macroexpansion. Many systems already have such a facility.
Pitman wrote such a facility in Cloe Runtime in order support
SYMBOL-MACROLET (before it was christened a special form); it was
about 750 lines of relatively straightforward, well-commented code.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
Most users will probably be happy for any interpretation which offers
them a future shot at portability.
Some users have indicated they dislike interpreters which do a semantic
prepass, because they like to be able to dynamically redefine macros
while debugging.
Proposal (COMPILER-LET-CONFUSION:ELIMINATE):
Remove COMPILER-LET from the language.
Rationale:
Some people think that having one less special form would simplify the
language. The revised COMPILER-LET semantics, which require
COMPILER-LET to make special bindings which are only visible during
expansion of macros which appear lexically within its body, are
not shared by any other feature in the language, and require a
fairly complex implementation technique. There are other
constructs which are strictly lexical that can be readily used
to solve the same kinds of problems that COMPILER-LET is intended to
be used for.
Cost to Implementors:
Minimal. Implementations could continue to support COMPILER-LET as
an extension.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
People who use COMPILER-LET would have to rewrite their programs to use
some other construct. As discussed above, most uses of COMPILER-LET
for communication between macros can be handled using MACROLET or
SYMBOL-MACROLET, though some perspicuity may be lost in the process.
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations whose interpreters include a preprocessor to
expand all macros have already implemented something similar to proposal
COMPILER-LET-CONFUSION:REPAIR. Users of such implementations
probably use COMPILER-LET somewhat more often since it has an
intelligible behavior, but their code is not portable since it relies
on behaviors which are either contrary to or not guaranteed by CLtL.
Benefits:
Either way, a potential area of incompatibility between compiled and
interpreted code would be eliminated.
Either way, a potential area of portability trouble would be very
drastically reduced (in the case of the REPAIR option) or eliminated
(in the case of the ELIMINATE option).
Discussion:
Pitman strongly favors COMPILER-LET-CONFUSION:REPAIR. He argues
against the idea of using MACROLET instead of COMPILER-LET, saying:
This is a little misleading because it's like saying you can
do without LET given that you have FLET. You can, but you lose some things
in the process:
Just as rewriting a LET using FLET might slow your computation, so too
a rewrite of COMPILER-LET using MACROLET might slow things down. However,
compilation speed is generally not weighted as heavily as execution speed
by many people, so the loss of speed here may not be as important.
Just as rewriting a LET using FLET might obscure the simplicity of your
intent, so too rewriting COMPILER-LET using MACROLET might obscure your
intent. You'd probably get used to recognizing idioms if you used it often
enough. Certainly this would be true if you didn't have LET. However,
COMPILER-LET is used less often, so not having it would mean that the
code you wrote instead would be much harder to read because people
wouldn't have the necessary familiarity with the idioms involved and so
wouldn't always understand them.
Sandra Loosemore responds:
The argument that using MACROLET is more inefficient than COMPILER-LET
is questionable. Both of the suggested implementation techniques for
COMPILER-LET involve considerable overhead.
If COMPILER-LET were not part of the language, people wouldn't think in
terms of rewriting COMPILER-LETs as MACROLETs; instead, they'd think of
how to use MACROLET in the first place to solve their problems. This
is what people who now use implementations with broken COMPILER-LETs
already do. Since MACROLET is now used much more frequently than
COMPILER-LET, that argues that people are much more familiar with
MACROLET idioms than COMPILER-LET idioms.
Also, note that the intent of the revised COMPILER-LET definition is
to make the binding only lexically visible within the body. Using
special binding for this purpose is troublesome. Both the MACROLET
and SYMBOL-MACROLET solutions are completely lexical and avoid all
the problems associated with special binding.
Glenn Burke thinks it needs to be emphasized that the code-walker
mentioned in the REPAIR proposal does not need to be portable. He
says:
The present wording makes it sound like a piece of cake to do with
portable code, when the reality is that a good fraction of CL cleanup
effort has involved the lack of capability of producing such a beast.
Without one or more of a number of proposals being accepted, a fully
correct portable code walker cannot be built, in my belief.
I object to the flippant attitude of just "presupposing" this
"trivial" function which "we know how to do".
We have considered a number of other options on this issue, including
a variety of proposals that would redefine COMPILER-LET to store
information about the variable bindings in the lexical environment, and
either having MACROEXPAND-1 make the special bindings or provide a
function which could be used to access them directly.
Kent Pitman says:
People have suggested that if it comes to making an incompatible change
on this one, it's probably better to just remove the feature and let
people continue to provide it compatibly where they think it's useful.
Even though I think the COMPILER-SYMBOL-VALUE thing is technically
doable, I find myself swayed by arguments that it's not the correct
avenue for us to pursue at this time.
David Moon says:
I think COMPILER-LET-CONFUSION:REPAIR should be split into four proposals.
First, one that gives the general framework for repairing but doesn't
say anything about how the interpreter implements COMPILER-LET, other
than to say that an additional proposal is needed to cover that. Then
three proposals for how the interpreter implements COMPILER-LET:
(1) The interpreter always does a "semantic pre-pass" like the compiler.
(2) The interpreter expands all macros inside COMPILER-LET before
evaluating any of the code inside COMPILER-LET.
(3) COMPILER-LET passes the variable bindings to MACROEXPAND-1
through the lexical environment, and the time when the interpreter
expands macros is not changed.
-------
∂23-Mar-89 1523 X3J13-mailer issue CONSTANT-COLLAPSING, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:22:35 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12319; Thu, 23 Mar 89 13:55:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12724; Thu, 23 Mar 89 13:55:52 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232055.AA12724@defun.utah.edu>
Date: Thu, 23 Mar 89 13:55:51 MST
Subject: issue CONSTANT-COLLAPSING, version 6
To: x3j13@sail.stanford.edu
This issue has had some editorial changes made to it, to clarify the
terminology that it uses.
Forum: Compiler
Issue: CONSTANT-COLLAPSING
References: CLtL p. 78, 87
Issue CONSTANT-MODIFICATION
Issue CONSTANT-COMPILABLE-TYPES
Issue EQUAL-STRUCTURE
Issue QUOTE-SEMANTICS
Category: CHANGE
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
V3, 03 Jan 1989, Sandra Loosemore
V4, 06 Jan 1989, Sandra Loosemore
V5, 11 Mar 1989, Sandra Loosemore
V6, 22 Mar 1989, Sandra Loosemore (comments from Moon)
Status: Ready for release
Problem Description:
CLtL states that an implementation is permitted to "collapse" or
coalesce constants appearing in code to be compiled if they are EQUAL.
The definition of EQUAL does not permit coalescing of more general
isomorphic data structures (such as arrays), which is often desirable.
This proposal deals only with changing the test which is used to
determine whether two constants may be coalesced. Issue
QUOTE-SEMANTICS deals with whether coalescing may be performed only by
COMPILE-FILE, or by COMPILE and EVAL as well. If proposal
QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE passes, then coalescing could be
performed on all constants.
This proposal uses the terms "source code", "compiled code", and
"similar as constants" that are defined in proposal
CONSTANT-COMPILABLE-TYPES:SPECIFY.
The term "coalesce" is defined as follows. Suppose A and B are two
objects used as quoted constants in the source code, and that A' and
B' are the corresponding objects in the compiled code. If A' and B'
are EQL but A and B were not EQL, then we say that A and B have been
coalesced by the compiler.
Proposal CONSTANT-COLLAPSING:GENERALIZE:
State that an implementation is permitted to coalesce constants
appearing in code to be compiled if and only if they are similar as
constants, unless the objects involved are of type SYMBOL, PACKAGE,
STRUCTURE, or STANDARD-OBJECT.
Rationale:
There is little reason why implementations should not be allowed to
perform more general collapsing of objects, since the arguments
against doing so also apply to collapsing of EQUAL objects, which
is already permitted. The arguments for coalescing of EQUAL data
structures (primarily space reduction) also apply to coalescing of
data structures that are equivalent under a more general coalescing
predicate.
Objects of type SYMBOL and PACKAGE cannot be coalesced because the fact
that they are named, interned objects means they are already as
coalesced as it is useful for them to be. Uninterned symbols could
perhaps be coalesced, but that was thought to be more dangerous than
useful. Objects of type STRUCTURE and STANDARD-OBJECT could be
coalesced if a "similar as a constant" predicate were defined for them;
it would be a generic function. Currently LOAD-OBJECTS only defines how
COMPILE-FILE and LOAD work together to construct an object in the
compiled code that is equivalent to the object in the source code,
and a different mechanism would have to be added to permit coalescence.
Current Practice:
Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example). Lucid Common Lisp also uses a more
general coalescing predicate than EQUAL.
Cost to implementors:
For implementations that currently coalesce based on EQUAL or that do
no coalescing, there is no associated implementation cost.
For implementations that currently coalesce things that this proposal
forbids them to coalesce (such as STRUCTUREs or uninterned symbols),
the implementation cost is probably small.
Cost to users:
Programs that depend on objects not being coalesced except when they
are EQUAL may break under this proposal. The only way one would be
able to detect that coalescing has taken place is if objects that were
not EQL in the source file become EQL after compilation; accessors on
the objects would return the same values regardless of whether or not
coalescing has taken place.
Benefits:
Collapsing of isomorphic arrays may lead to significant memory savings
in some applications.
Discussion:
This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
Some people believe that if the definition of EQUAL weren't "broken",
there wouldn't be any need for this proposal.
There is no inherent reason why the "coalescing predicate" must be the
same as the relationship used by the compiler/loader to construct
equivalent copies of objects of constants, but making the same rules
be applied in both situations simplifies the language somewhat.
-------
∂23-Mar-89 1521 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 9
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:21:20 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14332; Thu, 23 Mar 89 14:39:26 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12751; Thu, 23 Mar 89 14:39:23 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232139.AA12751@defun.utah.edu>
Date: Thu, 23 Mar 89 14:39:21 MST
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 9
To: x3j13@sail.stanford.edu
The part of this proposal that used to be item (3) has been moved to
issue EVAL-WHEN-NON-TOP-LEVEL. It now has a new item (3) dealing with
MACROLET semantics.
Please consider this issue carefully. It specifies some incompatible
changes to the treatment of macro functions, both for DEFMACRO and
MACROLET. The changes to DEFMACRO are necessary for compatibility
with issue EVAL-WHEN-NON-TOP-LEVEL. The changes to MACROLET are seen
as desirable for compatibility with the changes to DEFMACRO.
Forum: Compiler
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 114, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue COMPILER-LET-CONFUSION
Category: CLARIFICATION, ENHANCEMENT, CHANGE
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
16-Dec-88, V5 by Sandra Loosemore (major restructuring)
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
07-Jan-89, V7 by Sandra Loosemore (add example)
09-Mar-89, V8 by Sandra Loosemore (more restructuring)
22-Mar-89, V9 by Sandra Loosemore (add MACROLET stuff)
Status: Ready for release
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.
On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context. Compilers, for example, may not recognize these forms
properly in other than top-level contexts". At least one implementation
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.
A further problem is that CLtL p. 145 states that macro functions are
always defined in the null lexical environment. These semantics would
require it to be a special form, not a macro, since there is no
possible macro expansion that has equivalent semantics under the
processing model presented in issue EVAL-WHEN-NON-TOP-LEVEL. Under
that model, it ought to be possible for DEFMACRO to be implemented as
expanding into an EVAL-WHEN. Furthermore, the macro function should
appear in a for-evaluation position in the expansion, such as
(function (lambda ...)).
Proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW:
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations. However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.
(2) Remove the language from p. 145 of CLtL referenced above. Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form appears.
(3) Change the description of MACROLET to indicate that the macro
functions it creates are defined in the lexical environment in which
the MACROLET form appears, and not the null lexical environment.
State that declarations and MACROLET and SYMBOL-MACROLET definitions
affect the local macro definitions in a MACROLET, but that the
consequences are undefined if the local macro definitions reference
any local variable or function bindings that are visible in that
lexical environment.
Rationale:
Items (1) and (2) make the rules for when defining macros cause
compile-time side effects to be exactly the same as the rules for when
(EVAL-WHEN (COMPILE) ...) causes compile-time evaluation. This
provides a simple implementation technique.
Item (3) makes the handling of MACROLET macro definitions consistent
with DEFMACRO macro definitions.
Current Practice:
Most implementations do allow defining macros in non-top-level places.
However, the rules for when they cause compile-time side-effects are
not always the same as those for EVAL-WHEN. This is the case in
Lucid Common Lisp, for example.
Lucid evaluates DEFMACRO macro functions in the lexical environment
in which the DEFMACRO appears, but always evaluates MACROLET macro
functions in the null lexical environment.
Cost to implementors:
Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.
There will also be changes required to support compile-time definition
of functions in a non-null lexical environment. These changes
are required to support defining macros such as DEFINE-SETF-METHOD
that require functional objects to be created at compile-time, as well
as to support the changes to DEFMACRO and MACROLET. (Note that even
though defining macros cause compile-time evaluation only at
top-level, top-levelness does not necessarily imply a null lexical
environment under proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.)
Cost to users:
The changes to DEFMACRO and the other defining macros probably will
cause few problems for users. Since CLtL didn't require non-top-level
defining macros to be meaningful, assigning them a meaning is a
compatible extension.
The changes to MACROLET may cause problems for users who have assumed
that, within local macro definitions, global function and variable
definitions are not shadowed by local function and variable bindings.
Code-walking programs will also have to be changed to reflect the new
semantics (see issue SYNTACTIC-ENVIRONMENT-ACCESS).
Benefits:
The notion of defining macros as being somehow special when they
appear at top-level is removed, since their behavior can be explained
using EVAL-WHEN as a primitive. Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.
Discussion:
This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL. In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
The problems with compile-time definition of functions in a non-null
environment could be avoided by modifying proposal
DEFINING-MACROS-NON-TOP-LEVEL to remove the special treatment for
MACROLET, SYMBOL-MACROLET, and LOCALLY.
-------
∂23-Mar-89 1522 X3J13-mailer issue QUOTE-SEMANTICS, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:21:49 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14563; Thu, 23 Mar 89 14:49:18 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12765; Thu, 23 Mar 89 14:49:15 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232149.AA12765@defun.utah.edu>
Date: Thu, 23 Mar 89 14:49:14 MST
Subject: issue QUOTE-SEMANTICS, version 3
To: x3j13@sail.stanford.edu
I have made some clarifications to the language in this issue, and
expanded the Cost to Implementors and Discussion sections.
Forum: Compiler
Issue: QUOTE-SEMANTICS
Subsumes: Issue QUOTE-MAY-COPY
References: CLtL p. 55, 78, 86, 143
Issue CONSTANT-COLLAPSING
Issue CONSTANT-COMPILABLE-TYPES
Issue CONSTANT-CIRCULAR-COMPILATION
Category: CLARIFICATION
Edit History: V1, 22 Jan 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore (discussion)
V3, 22 Mar 1989, Sandra Loosemore (suggestions from Moon)
Status: Ready for release
Problem Description:
Is it permissible for COMPILE and EVAL to coalesce or copy constants?
Are there constraints upon what kinds of objects may appear as
constants in code processed by COMPILE or EVAL, similar to those for
COMPILE-FILE?
CLtL p86 states that (QUOTE <x>) simply returns <x>. On p55 it is
mentioned that the only self-evaluating forms that may be copied are
numbers or characters. It is also stated that an implementation is
permitted to collapse (or coalesce) EQUAL constants "appearing in code
to be compiled" (p78), which is defined to mean self-evaluating forms
or objects contained in a QUOTE form (without reference to whether the
form is processed by EVAL, COMPILE, or COMPILE-FILE).
Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded. In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced. There is also
at least one implementation where constants are copied by EVAL in some
circumstances.
In the proposals that follow, "copying" is used to mean the process of
constructing an object that is "similar as a constant" (as defined in
proposal CONSTANT-COMPILABLE-TYPES:SPECIFY), but not necessarily EQL,
to the original.
The term "coalescing" is defined in the writeup for issue
CONSTANT-COLLAPSING.
Proposal QUOTE-SEMANTICS:NO-COPYING:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is not permitted; the resulting program
must reference objects that are EQL to the corresponding objects in
the source code. The constraints on what kinds of objects may appear
as constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
Rationale:
This proposal is consistent with what many people think of as the
"traditional" semantics for QUOTE. It gives users maximum flexibility
about what kinds of objects may appear as constants.
Proposal QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
Any object may validly appear as a constant in code processed by EVAL
or COMPILE. The constraints on what kinds of objects may appear as
constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE. For data
types where proposal CONSTANT-COMPILABLE-TYPES:SPECIFY does not define
the notion of "similar as a constant", an implementation is permitted
to copy objects of that type only if it has extended "similar as a
constant" to include that type.
Rationale:
This proposal is the most consistent with the semantics stated in CLtL.
It gives users maximum flexibility about what kinds of objects may
appear as constants.
Allowing constants to be coalesced or copied has advantages for
memory management; for example, constants can be copied to read-only
memory that does not need to be garbage-collected.
Proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
The constraints on what kinds of objects may appear as constants
(described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply to EVAL and COMPILE as well as to
COMPILE-FILE.
Rationale:
This makes the rules for handling of constants consistent between
EVAL, COMPILE, and COMPILE-FILE. It gives implementors maximum
flexibility in handling constants in EVAL and COMPILE.
Allowing constants to be coalesced or copied has advantages for
memory management; for example, constants can be copied to read-only
memory that does not need to be garbage-collected.
Current Practice:
Implementations in which COMPILE attempts to copy all constants
include PSL/PCLS, Utah Common Lisp, and Kyoto Common Lisp. UCL and
KCL both implement COMPILE effectively as a combination of
COMPILE-FILE and LOAD.
In Lucid Common Lisp, constants are not normally copied by COMPILE,
but since COMPILE does coalesce constants, it may cause QUOTE to
return an object which is not EQL to the object which appeared in the
source code.
Symbolics Genera has COMPILE copy list, string, non-displaced array,
and (I-Machine only) closure constants, but Moon says he thinks this
is wrong.
There is known to be at least one implementation where expanding the
DEFUN macro causes all constants in the body of the function to be
copied.
Cost to implementors:
Proposal NO-COPYING would involve a significant cost in those
implementations where constants are now copied or coalesced by EVAL
and COMPILE. The aspect that is likely to cause the most problems is
that, in some implementations, the garbage collector assumes that
constants referenced in compiled code have been copied to read-only
storage and do not need to be scanned or relocated. Changing this
would require major changes to the internal representation of
functions, memory management strategy, and/or the implementation of
COMPILE.
Some implementations would also require substantial changes to support
proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS. Implementations that
would have garbage collection problems under proposal NO-COPYING would
have the same problems under COPYING-ALLOWED-BUT-NO-CONSTRAINTS,
unless they can define a copying behavior that will correctly handle
objects of all possible datatypes.
Proposal SAME-AS-COMPILE-FILE has no adoption cost above what is
required to support issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION.
Cost to users:
Proposals COPYING-ALLOWED-BUT-NO-CONSTRAINTS and SAME-AS-COMPILE-FILE
may break some existing programs that assume constants in code
processed by EVAL or COMPILE are always EQL to the corresponding
objects in the source code. Proposal SAME-AS-COMPILE-FILE may also
break existing programs that depend on referencing "undumpable"
constants in code processed by EVAL or COMPILE. In both cases,
however, the behavior is already nonportable. Both proposals would
permit implementations in which these programs now work to continue to
provide their existing behavior.
Benefits:
The semantics of QUOTE are clarified.
Discussion:
This issue subsumes issue QUOTE-MAY-COPY, which caused a very lengthy
debate on the cl-compiler mailing list.
This issue relates to conformance requirements. Accepting either of
proposals NO-COPYING or COPYING-ALLOWED-BUT-NO-CONSTRAINTS would mean
that not all conforming programs could be compiled with COMPILE-FILE.
Some people may find this disturbing, particularly since one of the
goals of Common Lisp has been to try to eliminate differences in
semantics between compiled and interpreted code.
Loosemore supports proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE,
since it requires essentially no conversion cost for implementors and
does not break any user programs that are not already nonportable.
JonL White says:
Since we have already passed the proposal that permits constants to
be "read-only" -- it is an error to modify them -- and have already
passed the proposal that allows access to updateable structures --
LOAD-TIME-EVAL -- then there is no excuse for being overly concerned
with the storage address of quoted data. People who have mistakenly
used structured constants as updatable data should convert over to
either LOAD-TIME-EVAL or DEFPARAMETER.
Kent Pitman says:
The problem is that a lot of copying advocates have been going around
trying to use "the need for copying" as leverage for restricting
the set of things which I may quote. My view is that it is my write [sic]
to quote whatever I want, and it's up to the person who thinks they
can do something fun with copying to not get themselves in deeper than
they can handle.
Jeff Dalton says:
I would agree [with Pitman's remarks] too. My only quibble is that
it's not just "the need for copying" that's used a lever.
"Consistency with file compilation" is also being used as a lever.
UCL implements COMPILE by dumping and loading a temporary file using
the same mechanisms as COMPILE-FILE and LOAD. Leigh Stoller (one of
the UCL compiler implementors) says that, even if this implementation
technique is disallowed by the outcome of this issue, they would
rather be nonconforming than change the implementation of COMPILE. In
addition to the change being a lot of work, he says he thinks that
making COMPILE-FILE and COMPILE different would be "really dumb", and
that having different conformance requirements for compiled and
interpreted code would just encourage people to write programs that
can't be compiled correctly.
-------
∂23-Mar-89 1523 X3J13-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:23:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12090; Thu, 23 Mar 89 13:49:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12718; Thu, 23 Mar 89 13:49:27 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232049.AA12718@defun.utah.edu>
Date: Thu, 23 Mar 89 13:49:25 MST
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 8
To: x3j13@sail.stanford.edu
Changes to this issue since version 7 (distributed last week) include:
- all references to EQ have been changed to EQL.
- error terminology has (hopefully) been fixed.
- added note about handling of uninterned symbols.
Forum: Compiler
Issue: CONSTANT-CIRCULAR-COMPILATION
References: Issue CONSTANT-COLLAPSING
Issue QUOTE-SEMANTICS
Category: CLARIFICATION, ADDITION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 14 Nov 1988, Cris Perdue
V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
V6, 08 Feb 1989, Sandra Loosemore (replace FLAG with YES)
V7, 11 Mar 1989, Sandra Loosemore (error terminology)
V8, 18 Mar 1989, Sandra Loosemore (changes per Moon, Masinter)
Status: Ready for release
Problem Description:
CLtL does not specify whether constants containing circular or
recursive references may be compiled. It is also not clear whether
the compiler must preserve sharing of EQL substructures; that is, whether
subobjects that are EQL in the source code must remain EQL after being
compiled.
The proposals below apply to constants appearing in a file compiled by
COMPILE-FILE. If proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE
passes, then the same constraints would apply to all constants. The
minimal scope over which sharing would be required to be detected is
over a single call to EVAL or COMPILE.
In the proposals that follow, "preserving EQLness" means that
subobjects that are EQL in the source code must remain EQL after being
compiled; that is, things don't get "less EQL" after compilation.
(Note that coalescing of constants implies that things may get "more
EQL".)
Proposal CONSTANT-CIRCULAR-COMPILATION:NO
State that conforming programs must not contain circular objects
appearing as constants to be compiled. The consequences of compiling
a program containing such an object with COMPILE-FILE and/or LOADing
the output produced by COMPILE-FILE for such a program [and, if we
accept proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE, compiling it
with COMPILE or evaluating it interpretively] are undefined.
State that the compiler is not required to preserve EQLness of
substructures.
Rationale:
This proposal would not require any existing implementation to change.
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
State that conforming programs must not contain circular objects
appearing as constants to be compiled. The consequences of compiling
a program containing such an object with COMPILE-FILE and/or LOADing
the output produced by COMPILE-FILE for such a program [and, if we
accept proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE, compiling it
with COMPILE or evaluating it interpretively] are undefined.
State that the compiler is required to preserve EQLness of
substructures within a file compiled with COMPILE-FILE.
Rationale:
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Some programs (such as PCL) have come to depend on COMPILE-FILE
preserving the EQLness of uninterned symbols, and it is cleaner
to require sharing to be preserved in general instead of making
symbols be a special case. Requiring sharing to be preserved still
allows loaders to build constants bottom-up.
Proposal CONSTANT-CIRCULAR-COMPILATION:YES
State that objects containing circular references may legitimately
appear as constants to be compiled. State that the compiler is
required to preserve EQLness of substructures within a file compiled
with COMPILE-FILE.
Rationale:
Users seem to expect this functionality, and some implementations
already provide it.
Current Practice:
A-Lisp preserves EQLness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant. PSL and Utah Common Lisp both
get stuck in an infinite loop if an attempt is made to compile a
reentrant structure. The TI Explorer compiler is able to reproduce
recursive lists and arrays, but currently hangs in a loop on a
circular list. Neither the Explorer nor Symbolics Genera 7.x detects
EQLness of list CDRs. Lucid handles circular constants correctly.
Franz uses a flag to control whether or not to attempt to detect
circular constants. KCL handles circular structures, but only detects
sharing of top-level structure (it does not traverse constants to look
for shared substructure).
Cost to implementors:
We know of no implementation that would have to change under proposal
NO.
For proposal YES, some implementations would require sweeping
changes; in some cases a completely different dumper/loader strategy
would have to be implemented.
The cost of proposal PRESERVE-SHARING-ONLY would fall somewhere in
between.
Cost to users:
The situation now is that programs which depend upon circularity or
sharing of substructure being preserved by the compiler are already
nonportable. Proposal NO simply formalizes the status quo. Proposal
YES would offer users functionality that is currently not portable.
Portable CommonLoops reportedly requires EQLness of uninterned symbols
to be preserved across a file, and would break under proposal NO.
According to Cris Perdue:
I am told that support for PCL requires the kinds of guarantees about
uninterned symbols [that say EQLness will be preserved]. Jim Kempf
here at Sun tells me he believes that this is true. John Foderaro
said that Franz made their compiler give this behavior in order to
support PCL.
Jim Kempf says he believes that certain GENSYMs appear in multiple
pieces of initialization code across a file in PCL, and the
initialization code only works if symbols EQ at compile time map to
symbols that are EQ at load time.
Benefits:
An area of ambiguity in the language is removed.
Discussion:
The issue of compiler speed is largely a red herring on this issue;
the overhead of detecting circularities is generally quite small. The
main question is whether we should require some implementations to
completely redo their compiler/loader interface in order to support
circular constants.
It has been argued that any "serious" implementation will support
circular constants anyway, because of customer demand. However, since
there appears to be only one implementation (Lucid) that now
implements proposal YES in its full generality, perhaps the demand for
this feature is not really all that strong.
Earlier drafts of this writeup contained a proposal FLAG which would
have added a variable *COMPILE-CIRCLE*, similar to *PRINT-CIRCLE*.
However, there were unresolved problems about what would happen if the
value of this variable were altered within the file being compiled,
and it was generally agreed that this proposal didn't have any
particular advantages over proposal YES and just introduced
unnecessary hairiness.
Since it is usually fairly simple to detect circular constants,
Loosemore would support an amendment to proposals NO and
PRESERVE-SHARING-ONLY to change the word "undefined" to "unspecified",
adding:
Implementations must either correctly handle the circular reference
or signal an error.
This is similar to the language which is already used in proposal
CONSTANT-COMPILABLE-TYPES:SPECIFY.
-------
∂23-Mar-89 1537 X3J13-mailer **DRAFT** Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:36:24 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 441574; Thu 23-Mar-89 16:01:03 EST
Date: Thu, 23 Mar 89 15:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890323155755.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
>> PLEASE DO -NOT- REPLY TO THIS ISSUE <<<
Bring your comments to the meeting.
For those on CL-Cleanup, I modified this version only very slightly
to accomodate out-and-out typos. I have not made any new conceptual
strides on this pass.
All should see of CL-Cleanup discussion at end.
-kmp
-----
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
23-Mar-89, Version 4 by Pitman ([hopefully] just fix typos)
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable filler of the directory
slot, but in order to denote a subdirectory, the use of separators (such
as dots, slashes, or backslashes) would be necessary. The very fact that
such syntax varies from host to host means that although the
representation might be "portable", the code using that representation
is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations it might be a top-level
directory (because "." is not a subdirectory separator). To be safe,
portable programs must avoid all potential separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether the
directory delimiters are a part. eg, is "foo" or "/foo" the directory
filler for a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or
"FOO" the directory filler for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Allow a list to be a filler of a pathname. The car of the list may be either
of the symbols :ABSOLUTE or :RELATIVE.
If the car of the list is :RELATIVE, the rest of the list is the
implementation-dependent result of PARSE-NAMESTRING for file systems which
have relative pathnames. Unless some other proposal is submitted to clarify
the behavior of relative pathnames in merging, etc. that behavior is left
undefined.
If the car of the list is :ABSOLUTE, the rest of the list is a list of
strings each naming a single level of directory structure. The strings
should contain only the directory names themselves -- no separator
characters.
The spec (:ABSOLUTE) represents the root directory.
Clarify that if a string is used as a filler of a directory field in a
pathname, it should be the unadorned name of a toplevel directory.
Specifying a string, str, is equivalent to specifying the list
(:ABSOLUTE str).
In place of a string, at any point in the list, keyword symbols may occur
to deal with special file notations. The following symbols have standard
meanings; they may not be meaningful for all operating systems, and are
intended for use only on those operating systems where they have meaning:
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (syntactic).
:BACK - Go upward in directory structure (semantic).
The difference between up and back is that if there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :BACK "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
Test Case:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:CANONICALIZE passes, only the 2nd return value.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file systems,
which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera represents Unix ".." as :UP. Its treatment of :UP is compatible
with this proposal, but Unix ".." is more properly represented by :BACK.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory field by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES field to a pathname, was
discarded because it imposed an unnatural distinction between a toplevel
directory and its subdirectories. Pitman's guess is the the idea was to
try to make it a compatible change, but since most programmers will
probably want to change from implementation-specific primitives to portable
ones anyway, that's probably not such a big deal. Also, there might have
been some programs which thought the change was compatible and ended up
ignoring important information (the :SUBDIRECTORIES field). Pitman thought
it would be better if people just accepted the cost of an incompatible
change in order to get something really pretty as a result.
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
------
Summary of discussion on CL-Cleanup:
Moon wondered if functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE
and PATHNAME-AS-DIRECTORY should be included either here or in
another issue. (The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix
does not. Also in some systems the root directory has a name and
in others it doesn't. Of course these functions signal an error in
non-hierarchical file systems.
Moon doesn't think :UP and :BACK are meaningful anywhere except
immediately after :RELATIVE, although he concedes Unix disagrees
with him. He suggests that if they were only allowed immediately
after :RELATIVE, you wouldn't need two of them. He also doesn't
think that MERGE-PATHNAMES should ever look at what files/directories
actually exist in the file system, which makes me opposed to the
existence of the one that you have called syntactic. He asks ``is
this really something we need, or will TRUENAME do the job?''
JLM replies (to Moon's query) that if you're trying to create a
filename to be used for output, it might not exist yet
(hence TRUENAME would signal an error), but there might
be various funny links in its directory path you would like to
traverse. Presumably you could use PROBE-FILE on some part of the
name (perhaps recursively down through the super-directories), then
merge in the remaining part, but that seems enough error-prone to be
worth hiding.
Aaron Larson has a competing or related proposal he wants to present
on this issue. I didn't attempt to summarize it here because it was
enough different from this discussion to raise presentational
confusion. My attempt here was mainly to get these thoughts on the
table -- not to preempt what he has to say. Hopefully he'll still
present his views separately.
∂23-Mar-89 1552 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:51:29 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03604g; Thu, 23 Mar 89 13:25:02 PST
Received: by pitney-bowes id AA26521g; Thu, 23 Mar 89 13:23:24 PST
Date: Thu, 23 Mar 89 13:23:24 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903232123.AA26521@pitney-bowes>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: X3J13@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 17:52 EST <19890321225242.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
Food for thought:
An interesting alternative that was just suggested to me would split
the type PATHNAME into something like PATHNAME and PATHNAME-TEMPLATE.
OPEN, TRUENAME, and friends would accept only PATHNAME arguments,
and DIRECTORY would accept only PATHNAME-TEMPLATE arguments.
(DIRECTORY would return a list of PATHNAME's.)
This would perhaps enhance our ability to stabilize the syntax and
semantics of PATHNAME much more rigidly, and leave open room for
experimentation with PATHNAME-TEMPLATE, where there seems to be more
need for it.
The basic idea is that a pathname would specify at most one file (it
could be bogus), whereas PATHNAME-TEMPLATE would specify a set of
files.
jlm
∂23-Mar-89 1527 X3J13-mailer issue DEFINE-OPTIMIZER, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:26:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA13550; Thu, 23 Mar 89 14:18:32 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12741; Thu, 23 Mar 89 14:18:28 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232118.AA12741@defun.utah.edu>
Date: Thu, 23 Mar 89 14:18:27 MST
Subject: issue DEFINE-OPTIMIZER, version 6
To: x3j13@sail.stanford.edu
There have been a number of small changes made to this writeup.
- The description of DEFINE-OPTIMIZER now says that the optimizer should
return only one value.
- The relationship to INLINE/NOTINLINE declarations has been clarified.
- There have been some minor clarifications to wording.
- The discussion section has been expanded.
Forum: Compiler
Issue: DEFINE-OPTIMIZER
References: Issue SYNTACTIC-ENVIRONMENT-ACCESS
Category: ADDITION
Edit history: 28-Sep-88, Version 1 by Pitman
10-Mar-89, Version 2 by Pitman (clarifications, new example),
10-Mar-89, Version 3 by Pitman & Loosemore
11-Mar-89, Version 4 by Pitman
13-Mar-89, Version 5 by Loosemore (discussion)
22-Mar-89, Version 6 by Loosemore (more discussion)
Status: Ready for release
Problem Description:
Often a general functional interface could be bypassed given explicit
knowledge of the arguments passed. This may happen when the arguments
are constant (or otherwise inferrable), an argument type is known (eg,
due to use of THE or DECLARE), or when some particular pattern of
optional, rest or keyword arguments is apparent.
Most implementations provide internally for optimization of generalized
function call interfaces to more specialized ones, but such an
optimization facility is not provided to Common Lisp users.
The absence of this facility in a portable fashion means that some
CL programs run slower than they need to in some implementations, or
else that some operators that should be implemented as functions end
up getting implemented as macros to assure needed efficiency.
Proposal (DEFINE-OPTIMIZER:NEW-FACILITY):
Introduce a facility for declaring compiler optimizations.
DEFINE-OPTIMIZER name arglist {declaration}* {form}* [Macro]
Defines a compiler optimizer for a function named NAME. The ARGLIST,
DECLARATIONS, and FORMS are treated exactly like the arglist,
declarations, and forms in a DEFMACRO. (The arglist may include
&ENVIRONMENT and &WHOLE.)
The argument NAME must name a function which has been previously
defined. The effects of defining an optimizer for a locally or
globally defined macro, a locally defined function, or a special
form are undefined.
When the optimizer is invoked, the forms are executed in the context
of bindings specified by the arglist as an implicit PROGN. The
optimizer should return a form which is preferable to evaluate instead
of the indicated call, or NIL to decline to optimize. If an optimizer
wishes to optimize into a form whose result is NIL, it should return
(QUOTE NIL). The resulting form should be careful to preserve the
semantics (including order-of-evaluation) of the original function
call.
If a call to DEFINE-OPTIMIZER appears at top-level in a file
being processed by the file compiler, it also makes the optimizer
known at compile-time (similar to the way DEFMACRO makes a macro
definition known to the compiler).
OPTIMIZE-EXPRESSION-1 form env [Function]
Similar to MACROEXPAND-1. Invokes the optimizers for the top level of
FORM, but does not iterate on the result. Returns two values:
RESULT and CHANGED-P.
Note: If an optimizer declines to optimize,
OPTIMIZE-EXPRESSION-1 hides the fact by returning FORM,NIL
rather than NIL,NIL.
OPTIMIZE-EXPRESSION form env [Function]
Iterates calling OPTIMIZE-EXPRESSION-1 until the CHANGED-P result
is NIL. Two values are returned: RESULT and CHANGED-P.
An implementation must save optimizer definitions created by
DEFINE-OPTIMIZER in case OPTIMIZE-EXPRESSION is attempted, but is
not actually required to call OPTIMIZE-EXPRESSION itself. Interpreters,
for example, may choose to just call the unoptimized form.
Special forms such as FLET and MACROLET that create local functional
definitions shadow not only functions and their SETF methods,
but also their optimizers. No portable facility is provided for creating
locally defined optimizers.
The effect of defining optimizations for functions in the LISP package
is not defined. (In some implementations, this would clobber or conflict
with existing advice that may be of higher quality.)
The editor is advised that a non-binding style note such as the
following would also be appropriate:
In general, it is poor style for a programmer to define optimizers for
functions that he does not maintain. This is because the correct
implementation of an optimizer for a function usually depends on an
understanding of the internals of that function. As such, a function
definition and any optimizers should be maintained as a unit so that
they can changes in either can be synchronized as appropriate with the
other.
If a function that has an optimizer function is declared INLINE,
the optimizer has precedence. If a function that has an optimizer
function is declared NOTINLINE, the application of the optimizer
function by OPTIMIZE-EXPRESSION and OPTIMIZE-EXPRESSION-1 is
inhibited.
Example:
;; These examples are taken literally from the Macsyma sources,
;; modified only to change DEFOPT to DEFINE-OPTIMIZER. The comments
;; were specially written for the X3J13 audience.
;; M+ is adds a Macsyma expression to another Macsyma expression.
;; The Macsyma internal representation for the sum of X and Y is
;; ((MPLUS) X Y). A all the real work is done by SIMPLIFY, which
;; reduces the expression as needed necessary. However, SIMPLIFY
;; is very complicated, and considerable speed can be gained by
;; entering it at specific known places.
(DEFUN M+ (&REST TERMS)
(PROTECT-&REST-VARIABLE TERMS)
(SIMPLIFY `((MPLUS) ,@TERMS)))
(DEFINE-OPTIMIZER M+ (&REST TERMS)
(COND ((= (LENGTH TERMS) 2) `(ADD2* ,@TERMS))
(T `(ADDN (LIST ,@TERMS) NIL))))
;; M- negates a Macsyma expression, or substracts two Macsyma
;; expressions. Once you figure out which of the two operations is
;; to be done, the problem is similar to that of M+ above. However,
;; often the decision can be made at compile time. In this case,
;; INLINE functions would have worked ok, except that not all
;; implementations do inlining, and even those that do may fail to
;; recognize that EXP2 being NIL means that a test can be eliminated
;; or dead code can be eliminated. Using optimizers is far more
;; likely to be useful in practice.
(DEFUN M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
(M--INTERNAL-NEGATE EXP1)
(M--INTERNAL-SUBTRACT EXP1 EXP2)))
(DEFINE-OPTIMIZER M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
`(M--INTERNAL-NEGATE ,EXP1)
`(M--INTERNAL-SUBTRACT ,EXP1 ,EXP2)))
Rationale:
Many large portable applications expect such a facility on an
implementation-specific basis. Others would use one if available.
Even if implementations don't use the provided optimizers primitively,
user macros and code-walkers can invoke them, so the facility wouldn't
be completely useless even in those implementations.
The rationale for giving optimizers precedence over INLINE declarations
is that the optimizer can look for special patterns in the arguments,
and defer to the inline if it doesn't find them.
Current Practice:
Symbolics Genera provides an optimizer facility which is more elaborate
but not fundamentally incompatible with this facility.
Many (if not most) serious implementations provide a similar facility.
For example, Lucid provides "compiler macros" which serve the same
purpose.
Cost to Implementors:
Since the implementation is not required to use this facility, the
cost of providing the proposed support is very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Portable code would be slower than necessary in some situations.
Benefits:
Some existing non-portable code could become portable.
Aesthetics:
Providing a separate optimizer definition from a main function definition
makes a possibility that the optimizer and main function could drift out
of synch. However, most places where this gets used in the first place
are places where speed is of paramount importance and the programmer is
willing to invest effort in maintaining things correctly and to accept the
risk of lossage if s/he fails.
This is a fairly clean and simple extension which adds significant
power to the compiler.
Discussion:
Pitman strongly supports this proposal, the design of which is modeled
directly after that which has been used in Macsyma for many years.
Information about argument type can come from two different sources:
THE and declarations (via PROCLAIM or DECLARE). The former information
is portably accessible, the latter is not. While a separate proposal
(SYNTACTIC-ENVIRONMENT-ACCESS) for allowing program access to type
declarations would be make this facility more useful, it is still
quite useful without it, as the examples from Macsyma illustrate.
Some implementations provide a way to provide more than one optimizer
for the same function. A multiple optimizer facility can be written
in terms of this simpler facility and vice versa, so the simpler of
the two facilities is proposed here.
Some people have suggested that they would like to see a pattern
matching facility integrated into this facility. The design of a
facility that would satisfy everyone would take a lot of time and
effort. At this point, there is no chance that the design of such a
facility would occur in time for acceptance into the standard.
The choice is this or nothing. Pitman thinks the language is much
better off with some form of optimization support than none.
David Moon says:
I'm not a fan of documentation strings, but shouldn't DEFINE-OPTIMIZER
allow them? Was their omission accidental or intentional?
It was probably accidental, but it's hard to say what should be done
with them if they are supported. Presumably the function already
would have its own FUNCTION documentation. Should the DOCUMENTATION
function be extended to recognize OPTIMIZER as a doc-type symbol?
Loosemore says:
Although I don't really think this is an essential feature to include
in the standard, I don't have any strong objection to adding it. If
people think it's a good idea to provide a standard interface for this
kind of thing, this is a good proposal for doing it -- it's fairly
simple, doesn't introduce any radically new ideas, and is general
enough to allow alternate interfaces (such as the pattern matcher) to
be layered on top of it.
From Barry Margolin:
While I like the proposal in general, I don't think it's appropriate to
add this to the language at this time. If most Lisp vendors are in
favor of it, though, my objection is pretty weak. But there's still the
editorial issue of adding it to the standard. I don't really think it's
worth it for the first version of the standard.
Also, I don't see a whole lot of value in portable optimizers. Yes, the
Macsyma example is a good one, but the real value of optimizers comes
when they translate into calls to extra fast, internal functions.
Portable optimizers can't do this, and non-portable optimizers don't
need to be defined using a portable mechanism.
From Kent Pitman:
I believe this claim is unsubstantiated and unsubstantiable. In many
implementations, internal functions have no special property that user
programs do not. In some cases, that makes the optimizers that much
more important since most internal functions run a constant factor
faster, but do not have any algorithmic leverage over user programs.
Optimizers are potentially able to do much better than built-in
optimizations because they can use domain-specific information that
is beyond the power of even the proverbial SCC (Sufficiently Clever
Compiler).
Optimizers have been around for a -long- time. They are not new
technology. If we cannot adopt at least this much this time, I see
no reason why for CL 2000 we won't have the exact same arguments
raised and we -still- won't get anything. On the other hand, if we
adopt them now we get years of field testing, and next time there
will be a lot of users with suggestions about how to improve them.
Some progress must be made incrementally -- but no progress is made
if the increment is zero.
The risks are very low. This proposal already says the optimizer
function has to be semantics-preserving, and that it might never be
called. It's hard to see how that can go wrong.
For so little cost and so much potential gain, I think it is worth any
associated risk.
From Robert Krajewski:
I think a portable optimizer definer is a fine idea. It's especially
useful for authors of Common Lisp-embedded subsystems that offer safe
access to their data structures in a development environment, but who
also wish to produce fast code for delivery. In such cases, an
optimizer should only run when unsafe code is desired.
From Richard Gabriel:
I oppose this proposal. First, optimization is rarely something that
can be done portably. Using a name like define-optimizer gives the
impression that something will be done more optimally, and maybe it
won't.
Second, it appears that this functionality is isomorphic to macros,
except possibly macros that are only in effect during compilation.
Third, it seems to solve a problem that is addressed by all the various
abstraction mechanisms around already.
Fourth, it is part of a trend I will call ``featherbedding'', which I
will use in my messages to refer to adding comfortable features to
Common Lisp that are redundant or not strictly necessary.
From Dick Waters:
I would like to say that I think that compiler optimizers are an
extremely good idea---right up there with the best of the ideas ever
presented to the committee.
I really hate having to make things macros for trivial reasons,
because this blocks you from funcalling them and using them as
arguments to MAPCAR REDUCE etc. If this mechanism were in Common Lisp
I would use it all the time. I bet it would cover a significant chunk
of what I use macros for.
To be more specific, there are a number of places where such compiler
optimizers would be of HUGE benefit in my portable implementation of
SERIES. In particular, they would be an appropriate framework in
which to state the whole thing. Now, since I have to do it all with
macros, a number of things that should, by every right, be functions
have to be macros instead. This in fact makes it impossible to make an
implementation of what I really want.
-------
∂23-Mar-89 1552 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:51:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03601g; Thu, 23 Mar 89 13:23:09 PST
Received: by challenger id AA24966g; Thu, 23 Mar 89 13:18:25 PST
Date: Thu, 23 Mar 89 13:18:25 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903232118.AA24966@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Moon raises an important point about conceptual versus
representational types. It always struck me that simple arrays as
defined in Version 9 were somewhat like each of these two things.
Moon also points out the FIXNUM/SIMPLE-ARRAY analogy. Let's look more
at this analogy:
Suppose I have some piece of code like this:
(defun f (x) ...)
and I want to know whether to put in a FIXNUM declaration for a
different target CL about which I know everything. In order to do that
I have to look at the calls to F to see whether they all produce
FIXNUMs for the target CL. Usually I look no further, but in general I
must look all the way back from each call to F to the origin of the
argument that is passed to F. The reason I usually have to look no
further than the call is that this is typically where the number is
created.
Now suppose the piece of code really takes an array, and I want to put
in a SIMPLE-ARRAY declaration so that I can get fast array access. I
cannot look only at the calls to F, nor can I look at the creation of
the arrays that get passed to F, but I have to look at all operations
on F to see whether any of them is an ADJUST-ARRAY. That is, I cannot
simply look all the way back from each invocation of F to the creation
of the argument that is passed, but I also have to look all the way
forward to the termination of the program.
In the FIXNUM example, this is as if I had to look at all the
operations on the numbers being fed to F (either before or *after* F
in execution order) to see whether some particular operation was
applied to an argument to F. That is, I cannot look at dataflow up to
the call to F to determine whether it is an simple array, I have to
look at the entire life history of the objects passed to F.
This leads to what I think is an interesting point. Some theorists
define a type as being the set of objects that can be passed to a
particular set of functions or operations. That is, a number is
something you can add, subtract, multiply, and divide, for example.
Some describe this by saying that a type is the set of objects that
respond to the same protocol.
In all implementations, FIXNUMs and BIGNUMs can be operated on by the
same set of functions and operations. Thus, FIXNUMs and BIGNUMs are
merely representational variants on the same type (namely, INTEGER).
In all implementations, ARRAY can be operated on by AREF, SETF of
AREF, and ADJUST-ARRAY (and some others).
In some implementations, SIMPLE-ARRAY can be operated on by AREF, SETF
of AREF (and some others), but not by ADJUST-ARRAY. Thus, in some
implementations SIMPLE-ARRAY responds to a different protocol and so
it is a conceptual type, while in implementations it is a
representational type.
This is, I think, the source of my uneasiness about the whole issue:
Version 9 legitimizes SIMPLE-ARRAY being a representational type in
some Common Lisps and a conceptual type in others. Only people who are
porting will notice the difference.
-rpg-
∂23-Mar-89 1526 X3J13-mailer issue CONSTANT-COMPILABLE-TYPES, version 9
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:24:39 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11960; Thu, 23 Mar 89 13:45:42 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12712; Thu, 23 Mar 89 13:45:38 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232045.AA12712@defun.utah.edu>
Date: Thu, 23 Mar 89 13:45:37 MST
Subject: issue CONSTANT-COMPILABLE-TYPES, version 9
To: x3j13@sail.stanford.edu
There have been extensive revisions made to this writeup since the
previous version was distributed last week. Most of the changes,
however, have been of an editorial nature. There are two substantive
changes to watch out for:
- The special treatment for uninterned symbols (requiring EQLness of
symbols within a single file to be preserved) has been removed from
this issue, since that more properly falls into the domain of issue
CONSTANT-CIRCULAR-COMPILATION.
- The problems of what to do with constant functions have been deferred
to a new issue, CONSTANT-FUNCTION-COMPILATION.
Forum: Compiler
Issue: CONSTANT-COMPILABLE-TYPES
References: CLtL pp. 56, 77-80, 324
Issue CONSTANT-MODIFICATION
Issue CONSTANT-CIRCULAR-COMPILATION
Issue CONSTANT-COLLAPSING
Issue QUOTE-SEMANTICS
Issue LOAD-OBJECTS
Issue CONSTANT-FUNCTION-COMPILATION
Category: CLARIFICATION, ADDITION
Edit history: 11/07/88, V1 by Cris Perdue
11/14/88, V2 by Cris Perdue
11/22/88, V3 by Cris Perdue
12/20/88, V4 by Cris Perdue
01/06/89, V5 by Sandra Loosemore (minor editorial
clarifications, expand discussion)
03/05/89, V6 by Cris Perdue (more response to comments,
especially from Moon and and from Loosemore)
03/05/89, V7 by Loosemore (more editorial tweaks)
03/13/89, V8 by Loosemore (discussion)
03/22/89, V9 by Loosemore (restructure)
Status: Ready for release
Problem description:
CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there is to be between the constant
passed to the compiler and the one that is established by compiling
and then loading its file. Relevant remarks in CLtL concerning file
compilation and the definition of QUOTE suggest that the compiler
handles constants in ways that are not actually possible.
Introduction to the proposal:
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear.
The key is a definition of an equivalence relationship between Lisp
objects, "similarity as constants". Code passed through the file
compiler and then loaded must behave as though quoted constants in it
are "similar" to quoted constants in the corresponding source code.
Issue CONSTANT-COLLAPSING addresses the issue of whether, for two
objects that are not EQL in the source code (but which are similar as
constants), the corresponding objects in the compiled code may be
EQL.
Issue CONSTANT-CIRCULAR-COMPILATION addresses the issue of whether,
for two objects that are EQL in the source code, the corresponding
objects in the compiled code must also be EQL.
Comments within the text of the proposal are enclosed in double angle
brackets, <<like this>>.
Proposal: CONSTANT-COMPILABLE-TYPES:SPECIFY
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original.
Some types of objects, such as streams, are not supported in constants
processed by the file compiler. Such objects may not portably appear
as constants in code processed with COMPILE-FILE. Conforming
implementations are required to handle such objects either by having
the compiler and/or loader reconstruct an equivalent copy of the
object in some implementation-specific manner; or by having the
compiler signal an error.
Of the types supported in constants, some are treated as aggregate
objects. For these types, being similar as constants is defined
recursively. We say that an object of these types has certain "basic
attributes", and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.
This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself. We use
the idea of depth-limited comparison, and say that two objects are
similar as constants if they are similar at all finite levels. This
idea is implicit in the definitions below, and applies in all the
places where attributes of two objects are required to be similar as
constants.
The following terms are used throughout this proposal:
The term "constant" refers to a quoted or self-evaluating constant,
not a named (defconstant) constant.
The term "source code" is used to refer to the objects constructed
when COMPILE-FILE calls READ, and additional objects constructed by
macroexpansion during COMPILE-FILE.
The term "compiled code" is used to refer to objects constructed by
LOAD.
Two objects are defined to be "similar as a constant" if and only if
they are both of one of the types listed below and satisfy the
additional requirements listed for that type.
Number
Two numbers are similar as constants if they are of the same type
and represent the same mathematical value.
Character
Two characters are similar as constants if they both represent
the same character.
<<Note that this definition has to depend on the results of the
Character Set proposals. The intent is that this be compatible with
how EQL is defined on characters.>>
Symbol
Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
and loader handle interned symbols.
An uninterned symbol in the source code is similar as a constant
to an uninterned symbol in the compiled code if their print names
are similar as constants.
Package
A package in the source code is similar as a constant to a package in
the compiled code if their names are similar as constants. Note that
the loader finds the corresponding package object as if by calling
FIND-PACKAGE with the package name as an argument. An error is
signalled if no package of that name exists at load time.
Random-state
Let us say that two random-states are functionally equivalent if
applying RANDOM to them repeatedly always produces the same
pseudo-random numbers in the same order.
Two random-states are similar as constants if and only if copies of
them made via MAKE-RANDOM-STATE are functionally equivalent.
Note that a constant random-state object cannot be used as the "state"
argument to the function RANDOM (because RANDOM side-effects this
data structure).
Cons
Two conses are similar as constants if the values of their respective
CAR and CDR attributes are similar as constants.
Array
Two arrays are similar as constants if the corresponding values each
of the following attributes are similar as constants:
For 1-dimensional arrays:
LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all valid indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all valid indices.
In addition, if the array in the source code is a SIMPLE-ARRAY, then
the corresponding array in the compiled code must also be a
SIMPLE-ARRAY. If the array in the source code is displaced, has a
fill pointer, or is adjustable, the corresponding array in the
compiled code is permitted to lack any or all of these qualities.
Hash Table
Two hash tables are similar as constants if they meet the following
three requirements:
(1) They both have the same test (e.g., they are both EQL hash tables).
(2) There is a unique one-to-one correspondence between the keys of
the two tables, such that the corresponding keys are similar as
constants.
(3) For all keys, the values associated with two corresponding keys
are similar as constants.
If there is more than one possible one-to-one correspondence between
the keys of the two tables, the results are unspecified. A conforming
program cannot use such a table as a constant.
Pathname
Two pathnames are similar as constants if all corresponding pathname
components are similar as constants.
Stream, Readtable, Generic-function, Method
Objects of these types are not supported in compiled constants.
Function
Issue CONSTANT-FUNCTION-COMPILATION specifies how the compiler and
loader handle constant functions.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending which proposes
a mechanism for dealing with objects.>>
Rationale:
For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle. It
also attempts to leave room for implementations to differ. Some
implementations have made opposing choices because the language
doesn't specify one over the other. Some implementations already
handle constants that this proposal defines as not valid in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.
This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.
Current practice:
>From Gail Zacharias (Nov 14): "Coral pretty much implements this
proposal (I think we currently coalesce hash table keys, but that's
just a bug that will be fixed). We also fasdump packages (using the
package name) and compiled functions (but not foreign functions). For
symbols, we dump the name, and if (roughly speaking) the symbol would
get printed with a package prefix, we also dump the package name and
load the symbol into that package (otherwise it gets loaded into the
current load-time package)."
>From David Gray (Nov 9): "The Explorer can compile constant functions,
read tables, and hash tables; an error is signalled for a stream. A
package object used to break the compiler but in release 5 it has been
fixed to generate instructions to call FIND-PACKAGE on the package
name at load time." (Nov 15): [The Explorer does not guarantee
retention of displaced-to and displaced-index-offset attributes.]
"The Explorer also does not currently support dumping closures (either
compiled or evaluated), although non-closure compiled functions can be
dumped."
>From David Moon (Jan 24): "Symbolics Genera current practice: aside
from some current bugs we have with circular structures of certain
types and with preserving the identity of CONSes under EQ, this is
more or less consistent with our current practice, if you made the
changes implied by my earlier comments. We preserve the :displaced-to
and :fill-pointer array attributes. I doubt that we do what the
proposal says for hash-tables, readtables, and random-states. We
support dumping compiled and interpreted functions, but not closures,
which in effect means we don't support dumping functions."
>From Sandra Loosemore (Mar 3): "UCL currently can handle only
constants that are of type number, character, symbol, cons,
simple-vector, or string (which it turns into simple-string). It
signals an error if an attempt is made to compile any other kind of
object as a constant."
Adoption cost:
Not known. Probably moderate or low -- for most implementations. The
cost would be to implementors rather than users since this part of the
language is currently underspecified. The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.
This proposal is close to compatible with the Franz, Lucid, Coral,
Texas Instruments, and Symbolics implementations. It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.
Readtables need not be supported by an implementation. If a readtable
contains only symbols to represent functions, here is Cris Perdue's
suggested spec for similarity of readtables:
Character syntax type for each character in the table;
function for each readmacro character, mappings for
dispatch macros; whether terminating or nonterminating
for each readmacro.
Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances. The cleanup issue LOAD-OBJECTS deals with this.
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
Earlier versions of this proposal specified an additional constraint
on uninterned symbols, requiring EQLness to be preserved across the
entire file. However, this special case was removed because it was
thought that including it in this issue made its presentation
unnecessarily complicated, since preservation of EQLness is really a
separate issue (CONSTANT-CIRCULAR-COMPILATION). A consequence of the
decision to remove the special casing for uninterned symbols is that,
unless we accept one of the two CONSTANT-CIRCULAR-COMPILATION
proposals that requires EQLness of constants to be preserved, the
behavior for uninterned symbols will be rather strange. PCL will
reportedly break if uninterned symbols that are EQL in the source code
do not remain EQL in the compiled code.
-------
∂23-Mar-89 1526 X3J13-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:25:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17795; Thu, 23 Mar 89 16:24:48 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12801; Thu, 23 Mar 89 16:24:44 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232324.AA12801@defun.utah.edu>
Date: Thu, 23 Mar 89 16:24:42 MST
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 6
To: x3j13@sail.stanford.edu
There have been a number of changes to the writeup on this issue since
version 4, which was distributed last week. (Version 5 was circulated
only to cl-compiler.) There are some new functions proposed, and
others have been combined. There seemed to be general agreement that
only the material in proposal SMALL was anywhere near ready to be
standardized at this time, so proposals MEDIUM and LARGE have gone
away.
We have still been having problems deciding upon the exact form of
accessors for declarations. If what's specified in this version is
not acceptable, we may have to scrap that part of the proposal for
now.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
Issue MACRO-FUNCTION-ENVIRONMENT
Issue GET-SETF-METHOD-ENVIRONMENT
Issue COMPILE-FILE-ENVIRONMENT
Issue FUNCTION-NAME
Issue PROCLAIM-LEXICAL
Issue MACRO-ENVIRONMENT-EXTENT
Issue DESTRUCTURING-BIND
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Status: **DRAFT**
Problem description:
When macro forms are expanded, the expansion function is called with
two arguments: the form to be expanded, and the environment in which
the form was found. The environment argument is of limited utility.
The only use sanctioned currently is as an argument to MACROEXPAND or
MACROEXPAND-1 or passed directly as an argument to another macro
expansion function. Recent cleanup issues propose to allow it as an
argument to MACRO-FUNCTION and to GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle
local macro and function definitions, due to insufficient access to
the information contained in environments and the inability to
augment environments with local definitions.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic
environment objects. In all of these functions the argument named ENV
is an environment of the sort received by the &ENVIRONMENT argument to
a macro or as the environment argument for EVALHOOK. (It is not
required that implementations provide a distinguished representation
for such objects.) Optional "env" arguments default to NIL, which
represents the local null lexical environment (containing only global
definitions and proclamations that are present in the runtime
environment). All of these functions should signal an error of type
TYPE-ERROR if the value of an environment argument is not a syntactic
environment.
The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION-INFORMATION retrieve information about declarations that
are in effect in the environment. Since implementations are
permitted to ignore declarations (except for SPECIAL declarations),
these accessors are required only to return information about
declarations that were explicitly added to the environment using
AUGMENT-ENVIRONMENT. Implementations are also permitted to
canonicalize declarations, so the information returned by the
accessors may not be identical to the information that was passed to
AUGMENT-ENVIRONMENT.
VARIABLE-INFORMATION variable &optional env [Function]
This function returns information about the interpretation of the
symbol VARIABLE when it appears as a variable within the lexical
environment ENV. The following four values are returned.
The first value indicates the type of definition or binding which is
apparent in ENV:
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result
will also refer to variables proclaimed lexical.]
The second value indicates whether there is a local binding of the
name. If the name is locally bound, the second value is true.
Otherwise, NIL is returned.
The third value is the type specifier associated with the variable
named by the symbol in the environment. If no explicit association
exists, either by PROCLAIM or DECLARE, then the result is the type
specifier T. It is permissible for implementations to return a type
specifier that is equivalent to or a supertype of the one appearing
in the original declaration.
The fourth value is a property list of containing information about
declarations that apply to the apparent binding of the variable.
The keys in the property list are symbols which name
declaration-specifiers, and the format of the corresponding values
depends on the particular declaration-specifier involved. The only
standard declaration-specifier that may appear as a key in this
property list is IGNORE, with a non-NIL value to indicate that the
variable has been declared IGNORE. If an implementation supports
additional declaration-specifiers that apply to variable bindings,
those declaration-specifiers may also appear in the property list.
Programmers are reminded that the global binding type may differ from
the local one, and can be retrieved by calling VARIABLE-INFORMATION
again with a null lexical environment.
FUNCTION-INFORMATION function &optional env [Function]
This function returns information about the interpretation of the
function name FUNCTION when it in a functional position within
lexical environment ENV. The following four values are returned.
The first value indicates the type of definition or binding of
the function name which is apparent in ENV:
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
Some function names may refer to both a global macro and a global
special form. In such a case, the macro takes precedence, and
:MACRO is returned as the first value.
The second value specifies whether the definition is local or
global. If local, the second value is true, and it is false when
the definition is global.
The third value is the type specifier associated with the function
in the environment, or the symbol FUNCTION if there is no functional
type declaration or proclamation associated with the function. This
value might not include all the apparent FTYPE declarations for
FUNCTION. It is permissible for implementations to return a type
specifier that is equivalent to or a supertype of the one that
appeared in the original declaration.
The fourth value is a property containing informatin about
declarations that apply to the apparent binding of the function.
The keys in the property list are symbols which name
declaration-specifiers, and the format of the corresponding values
depends on the particular declaration-specifier involved. The only
standard declaration-specifiers that may appear as a key in this
property list are INLINE and NOTINLINE, with a non-NIL value to
indicate that the function has been declared INLINE or NOTINLINE
(respectively). If an implementation supports additional
declaration-specifiers that apply to function bindings, those
declaration-specifiers may also appear in the property list.
[Note: The use of "function name" rather than "symbol" as the
description of the function argument is intended to be compatible
with the various proposals to extend the syntax of function
specifiers. If no such change actually occurs then this would only
refer to symbols.]
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a new environment containing the information
present in ENV, augmented with the information provided by the keyword
arguments. It is intended to be used by program analyzers that perform
a code walk.
The arguments are supplied as follows:
:VARIABLE A list of symbols which shall be visible as bound
variables in the new environment. Whether each
binding is to be interpreted as special or lexical
depends on SPECIAL declarations recorded in the
environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, specified as a
list of (name definition) lists (that is, in the same
format as the CADR of a SYMBOL-MACROLET special form).
The new environment will have local symbol-macro bindings
of each symbol to the corresponding expansion, so that
MACROEXPAND will be able to expand them properly.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, specified as a
list of (name definition) lists. Each definition must
be a function of two arguments (a form and an environment).
The new environment will have local macro bindings of each
name to the corresponding expander function, which
will be returned by MACRO-FUNCTION and used by
MACROEXPAND.
:DECLARE A list of decl-specs. Information about these
declarations can be retrieved from the resulting
environment using the VARIABLE-INFORMATION,
FUNCTION-INFORMATION, and DECLARATION-INFORMATION
accessors.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list.
An error is signalled if any of the names specified as keys in the
:MACRO alist are also included in the :FUNCTION list. The consequences
of destructively modifying the list structure of any of the arguments
to this function are undefined.
The extent of the returned environment is the same as the extent of
the argument environment. The result may share structure with the
argument environment, but the argument environment is not modified.
While an environment argument from EVALHOOK is permitted to be used
as the environment argument for this function, the reverse is not
true. If an attempt is made to use the result of AUGMENT-ENVIRONMENT
as the environment argument for EVALHOOK, the consequences are
undefined. The environment returned by AUGMENT-ENVIRONMENT may only
be used for syntactic analysis, ie. the functions specified by this
proposal and functions such as MACROEXPAND.
PARSE-MACRO name lambda-list body &optional env [Function]
This function is used to process a macro definition in the same way
as DEFMACRO and MACROLET. It returns a lambda-expression that accepts
two arguments (a form and an environment). The "name", "lambda-list",
and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
definition.
The "lambda-list" argument may include &ENVIRONMENT and &WHOLE.
The "name" argument is used to enclose the "body" in an implicit
BLOCK, and may also be used for implementation-dependent purposes
(such as including the name of the macro in error messages if the
form does not match the lambda-list).
ENCLOSE lambda-expression &optional env [Function]
This function returns an object of type FUNCTION that is equivalent
to what would be obtained by evaluating `(FUNCTION ,LAMBDA-EXPRESSION)
in syntactic environment ENV. The consequences are undefined if any
of the local variable or function bindings that are visible in the
lexical environment represented by ENV are referenced within the
LAMBDA-EXPRESSION.
DECLARATION-INFORMATION decl-spec &optional env [Function]
This function returns a list of declaration-specifiers whose CAR
is the symbol DECL-SPEC that are in force in the environment ENV,
sorted so that the most recent declaration is first on the list.
Only declarations that do not apply to function or variable
bindings (i.e., those that are "pervasive") can be accessed with
this function.
It is required that this function recognize OPTIMIZE and DECLARATION
as DECL-SPECs. If an implementation has been extended to recognize
additional pervasive declaration specifiers in DECLARE or PROCLAIM,
it is required that either the DECLARATION-INFORMATION function
should also recognize those declarations, or that the implementation
provide an accessor that is specialized for that declaration
specifier.
Rationale:
This proposal defines a minimal set of accessors (VARIABLE-INFORMATION,
FUNCTION-INFORMATION, and DECLARATION-INFORMATION) and a constructor
(AUGMENT-ENVIRONMENT) for environments.
The PARSE-MACRO function is provided so that users don't have to
write their own code to destructure macro arguments. Most
implementations probably already have a similar internal function.
The ENCLOSE function is necessary to support early evaluation of
defining macros such as DEFMACRO by a program analyzer. It is
also necessary to support the revised MACROLET semantics proposed in
issue DEFINING-MACROS-NON-TOP-LEVEL; all implementations would be
required to have similar functionality internally.
Making declarations from an &ENVIRONMENT or EVALHOOK environment
optional continues to allow implementations the freedom to simply
ignore all such declarations in the compiler or interpreter.
Examples:
#1: This example illustrates the first value returned by the function
VARIABLE-INFORMATION.
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-INFORMATION VAR ENV))
(DEFVAR A)
(DEFUN TEST ()
(LET (B)
(LET (C)
(DECLARE (SPECIAL C))
(SYMBOL-MACROLET ((D ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E))))))
(TEST) -> (:SPECIAL :LEXICAL :SPECIAL :SYMBOL-MACRO NIL)
#2: This example illustrates the first value returned by the function
FUNCTION-INFORMATION.
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
`',(FUNCTION-INFORMATION FUNCTION-NAME ENV))
(DEFUN A ())
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(MULTIPLE-VALUE-CALL #'LIST
(KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> (:FUNCTION NIL
:MACRO NIL
:SPECIAL-FORM NIL
:FUNCTION T
:MACRO T
NIL NIL)
#3: This example shows how a code-walker might walk a MACROLET special
form. It assumes that the revised MACROLET semantics described in
proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW are in effect.
(defun walk-macrolet (form env)
(let ((macros (make-macro-definitions (cadr form) env)))
(multiple-value-bind (body decls) (parse-body (cddr form))
(walk-implicit-progn
body
(augment-environment env :macro macros :declare decls))
)))
(defun make-macro-definitions (defs env)
(let ((results nil))
(dolist (d defs)
(push (list (car d)
(enclose (parse-macro (car d) (cadr d) (cddr d) env)
env))
results))
results))
Cost to Implementors:
Most implementations already record some of this information in some
form. Providing these functions should not be too difficult, but it
is a more than trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable
Common Loops defines a subset of this functionality for its code
walker and implements it on a number of diffent versions of Common
Lisp.
Discussion:
The first version of this proposal expressly did not deal with the
objects which are used as environments by EVALHOOK. This version is
extended to support them in the belief that such environments share a
lot of functionality with the syntactic environments needed by a
compiler. While the two types of environments might have very
different implementations, there are many operations which are
reasonable to perform on either type, including all of the accessor
functions described by this proposal.
AUGMENT-ENVIRONMENT currently requires signaling an error when
symbol-macro names match variable names in the same call. This could
be reduced to "should signal". By requiring the error signaling, this
proposal is compatable with Proposal SYMBOL-MACROLET-DECLARE:ALLOW,
which says
"... signals an error if a SPECIAL declaration names one of the symbols
being defined as a symbol-macrolet."
Maintaining compatability with the SYMBOL-MACROLET-DECLARE proposal
allows fairly trivial implementations of the SYMBOL-MACROLET
special-form in terms of the AUGMENT-ENVIRONMENT function.
Moon notes:
Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms. Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT? I'm unsure.
Some people have indicated they think that the :MACRO argument (and
the :SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an
a-list of the form (name . definition).
Some people have indicated they think that implementations must never
discard any declarations, even if they are not otherwise used by the
interpreter or compiler. Proposal SMALL is consistent with what CLtL
says (implementations are free to ignore all declarations except
SPECIAL declarations), but the DECLARATION-INFORMATION function may
not be particularly useful unless it is guaranteed to do something.
Requiring implementations to keep track of declarations they'd otherwise
ignore would involve some implementation cost and also may incur a
performance penalty.
-------
∂23-Mar-89 1527 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:25:15 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14465; Thu, 23 Mar 89 14:45:11 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12759; Thu, 23 Mar 89 14:45:06 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232145.AA12759@defun.utah.edu>
Date: Thu, 23 Mar 89 14:45:03 MST
Subject: issue EVAL-WHEN-NON-TOP-LEVEL, version 7
To: x3j13@sail.stanford.edu
A paragraph on order of processing of top-level forms (which used to be
discussed in issue DEFINING-MACROS-NON-TOP-LEVEL) has been added to
this version of the writeup.
Issue: EVAL-WHEN-NON-TOP-LEVEL
Forum: Compiler
References: EVAL-WHEN (CLtL pp69-70),
Issue DEFINING-MACROS-NON-TOP-LEVEL
Issue COMPILED-FUNCTION-REQUIREMENTS
Issue IN-PACKAGE-FUNCTIONALITY
Issue LOCALLY-TOP-LEVEL
Category: CLARIFICATION/CHANGE
Edit History: 06-May-88, Version 1 by Sandra Loosemore
16-Dec-88, Version 2 by Loosemore (alternate direction)
30-Dec-88, Version 3 by Loosemore (minor wording changes)
07-Jan-89, Version 4 by Loosemore (update discussion)
09-Feb-89, Version 5 by Pitman and Moon (some major changes)
09-Mar-89, Version 6 by Loosemore (clean up wording)
22-Mar-89, Version 7 by Loosemore (order of processing)
Status: Ready for release
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
locations? Even if it is legitimate, what does it mean?
Another issue, referred to here as ``the EVAL-WHEN shadowing problem,''
is that some people have complained that shadowing the symbols EVAL,
COMPILE, or LOAD means that you have to also either shadow EVAL-WHEN
and define it to recognize the new symbol, or else you must resign
yourself to writing (EVAL-WHEN (... LISP:EVAL ...) ...),etc. all over.
While the goal here is not to solve this problem, it might be possible
to solve both problems at once.
There are two proposals presented here, GENERALIZE-EVAL and
GENERALIZE-EVAL-NEW-KEYWORDS.
Background/Analysis:
The proposal which follows was constructed with the following goals
in mind:
1. The lexical and dynamic environment for the EVAL-WHEN body should
be the same for each situation. That is, the body should ``mean
the same thing'' regardless of which situation is being processed.
2. The evaluation context for EVAL-WHEN should be the current
lexical environment.
3. At execution time, EVAL-WHEN should always return the result of
its last form if execution of the body occurred, or NIL if the
body was not executed.
4. If a top-level EVAL-WHEN has a LOAD keyword, its body should
inherit top-level-ness during normal processing. This permits the
use of (EVAL-WHEN (EVAL COMPILE LOAD) ...) at top-level to mean
simply "Do whatever would normally be done for this body, but
also do something at compile time." This, in turn, will later be
the key to allowing defining forms to be usefully described in
terms of EVAL-WHEN.
5. Non-top-level expressions should have no effect until they are
executed. This is the key to making sure that any necessary
environment is present. Since the COMPILE keyword forces effects
to occur earlier than execution time, it follows from this that
any correct solution must not allow the COMPILE keyword to have
an effect at other than top-level.
To accomplish these goals, we formulated the following model:
The purpose of EVAL-WHEN is to accomodate the fact that some of the
semantic processing of an expression may usefully be partitioned
between compile time and run time in some circumstances.
(EVAL-WHEN (EVAL) <code>)
describes a general technique for accomplishing some particular goal
at normal program execution time. However, the pair of expressions
(EVAL-WHEN (COMPILE) <code-A>)
(EVAL-WHEN (LOAD) <code-B>)
can be used to describe an alternate technique for implementing part
of the effect (A) at compile-time, and part of the effect (B) at
load-time.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL):
Replace the description of EVAL-WHEN with the following:
EVAL-WHEN ({situation}*) {form}* [Special Form]
The body of an EVAL-WHEN form is processed as an implicit PROGN, but
only in the situations listed. Each SITUATION must be a symbol,
either COMPILE, LOAD, or EVAL.
The use of COMPILE and LOAD controls whether and when processing
occurs for top-level forms. The use of EVAL controls whether
processing occurs for non-top-level forms.
The EVAL-WHEN construct may be more precisely understood in terms of
a model of how the file compiler, COMPILE-FILE, processes forms in a
file to be compiled.
Successive forms are read from the file by the file compiler using
READ. These top-level forms are normally processed in what we call
`not-compile-time' mode. There is one other mode, called
`compile-time-too' mode, which can come into play for top-level
forms. The EVAL-WHEN special form is used to annotate a program
in a way that allows the program doing the processing to select
the appropriate mode.
Processing of top-level forms in the file compiler works as follows:
* If the form is a macro call, it is expanded and the result is
processed as a top-level form in the same processing mode
(compile-time-too or not-compile-time).
* If the form is a PROGN form, each of its body forms is
sequentially processed as top-level forms in the same processing
mode.
* If the form is a COMPILER-LET, MACROLET, or SYMBOL-MACROLET,
the file compiler makes the appropriate bindings and recursively
processes the body forms as an implicit top-level PROGN with those
bindings in effect, in the same processing mode.
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
COMPILE LOAD EVAL compile-time-too Action
Yes Yes -- -- Process body in compile-time-too mode
No Yes Yes Yes Process body in compile-time-too mode
No Yes Yes No Process body in not-compile-time mode
No Yes No -- Process body in not-compile-time mode
Yes No -- -- Evaluate body
No No Yes Yes Evaluate body
No No Yes No do nothing
No No No -- do nothing
"Process body" means to process the body as an implicit top-level
PROGN. "Evaluate body" means to evaluate the body forms as in
implicit PROGN in the dynamic execution context of the compiler and
in the lexical environment in which the EVAL-WHEN appears.
* Otherwise, the form is a top-level form that is not one of the
special cases. If in compile-time-too mode, the compiler first
evaluates the form and then performs normal compiler processing
on it. If in not-compile-time mode, only normal compiler
processing is performed. [The nature of this processing is
defined more precisely in issue COMPILED-FUNCTION-REQUIREMENTS.]
Any subforms are treated as non-top-level forms.
Note that top-level forms are guaranteed to be processed in the order
in which they textually appear in the file, and that each top-level
form read by the compiler is processed before the next is read.
However, the order of processing (including, in particular, macro
expansion) of subforms that are not top-level forms is unspecified.
For an EVAL-WHEN form that is not a top-level form in the file compiler
(that is, one of: in the interpreter; in COMPILE; or in the file
compiler but not at top-level), if the EVAL situation is specified,
its body is treated as an implicit PROGN. Otherwise, the EVAL-WHEN
form returns NIL.
Clarifications/Consequences:
The following effects are logical consequences of the above proposal:
* It is never the case that the execution of a single EVAL-WHEN
expression will execute the body code more than once.
* The keyword `EVAL' is a misnomer because execution of
the body need not be done by EVAL. In compiled code, such as
(DEFUN FOO () (EVAL-WHEN (EVAL) (PRINT 'FOO)))
the call to PRINT should be compiled.
* Macros intended for use in top-level forms should arrange for all
side-effects to be done by the forms in the macro expansion.
The macro-expander itself should not do the side-effects.
Wrong: (defmacro foo ()
(really-foo)
`(really-foo))
Right: (defmacro foo ()
`(eval-when (compile eval load) (really-foo)))
Adherence to this convention will mean that such macros will behave
intuitively when placed in non-top-level positions.
* Placing a variable binding around an EVAL-WHEN reliably captures the
binding because the `compile-time-too' mode cannot occur (because
introducing a variable binding would mean we were not at top level).
For example,
(LET ((X 3))
(EVAL-WHEN (EVAL LOAD COMPILE) (PRINT X)))
will print 3 at execution [load] time, and will not print anything at
compile time. This is important so that expansions of DEFUN and
DEFMACRO can be done in terms of EVAL-WHEN and can correctly capture
the lexical environment.
(DEFUN BAR (X) (DEFUN FOO () (+ X 3)))
might expand into
(DEFUN BAR (X)
(PROGN (EVAL-WHEN (COMPILE)
(COMPILER::NOTICE-FUNCTION-DEFINITION 'FOO '(X)))
(EVAL-WHEN (EVAL LOAD)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))))
which would be treated the same as
(DEFUN BAR (X)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))
by the above rules.
Test Cases:
;; #1: The EVAL-WHEN in this case is not at top-level, so only the EVAL
;; keyword is considered. At compile time, this has no effect.
;; At load time (if the LET is at top level), or at execution time
;; (if the LET is embedded in some other form which does not execute
;; until later) this sets (SYMBOL-FUNCTION 'FOO1) to a function which
;; returns 1.
(LET ((X 1))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO1) #'(LAMBDA () X))))
;; #2: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting
;; (SYMBOL-FUNCTION 'FOO2) to a function which returns 2.
(EVAL-WHEN (EVAL LOAD COMPILE)
(LET ((X 2))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO2) #'(LAMBDA () X)))))
;; #3: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting the
;; function cell of FOO3 to a function which returns 3.
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO3) #'(LAMBDA () 3)))
;; #4: This always does nothing. It simply returns NIL.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO4)))
;; #5: If this form occurs at top-level of a file to be compiled, FOO5 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (EVAL)
(PRINT 'FOO5)))
;; #6: If this form occurs at top-level of a file to be compiled, FOO6 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (EVAL LOAD)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO6)))
Rationale:
This is compatible with any guarantees made by CLtL, and extends the
behavior usefully to non-top-level situations.
This gives a useful meaning to EVAL-WHEN that supports useful and
predictable behavior if defining macros are used in a non-top-level
situation.
The constraints on the order in which top-level forms are processed
ensure that the compile-time effects of defining macros and EVAL-WHENs
at the beginning of the file are visible during the processing of
forms that appear later in the file, which is what most users expect.
Leaving the order of processing of non-top-level forms unspecified
allows the compiler to perform certain kinds of transformations that
change the textual order of subforms. Users should not depend on
side-effects from macros that require them to be expanded in any
particular order.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS):
As in GENERALIZE-EVAL, but rename the EVAL keyword to :EXECUTE,
the COMPILE keyword to :COMPILE-TOPLEVEL, and LOAD keyword to
:LOAD-TOPLEVEL.
Deprecate the use of keywords EVAL, COMPILE, and LOAD to EVAL-WHEN.
For compatibility, they are supported in EVAL-WHEN
at top-level, but their meaning is not defined elsewhere.
Rationale:
The fact that the situation keywords chosen are not the same as
those now used means that the change can be added in a way that
is truly upward compatible (not only with CLtL but with existing
practice in implementations which have chosen to extend or `clarify'
the definition given in CLtL) since the meaning of EVAL, COMPILE,
and LOAD in non-top-level situations (which was never spelled
out in CLtL) can legitimately differ from the meaning of these
new keywords.
Using other names and/or the keyword package for the names of
situations solves the EVAL-WHEN shadowing problem.
The name `execute' does not promote the confusion that the body of an
EVAL-WHEN must be executed only in the evaluator. It also does not
promote the confusion that the body of an EVAL-WHEN, regardless of when
executed, must run interpreted.
The names `compile-toplevel' and `load-toplevel' emphasize the fact
that these cases are not interesting in non-top-level positions.
Current Practice:
In Symbolics Genera, the interpreter permits EVAL-WHEN in non-top-level
positions in a way that is compatible with this proposal but both the
COMPILE and COMPILE-FILE functions complain about EVAL-WHEN in a
non-top-level position.
Both Lucid Common Lisp and Kyoto Common Lisp already interpret the
EVAL keyword to mean "execute" in non-top-level situations. Both of
these implementations also make (EVAL-WHEN (LOAD) ...) suppress
compile-time "magic" from defining macros such as DEFMACRO.
IIM describes its EVAL-WHEN as:
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
Note that the interpretation of the EVAL situation and the nesting
behavior is different.
Cost to Implementors:
The actual change to EVAL-WHEN in both cases is probably fairly
localized and straightforward to make in most or all implementations.
The second-order costs of proposal GENERALIZE-EVAL will vary depending
on whether existing implementations have extended the definition of
EVAL-WHEN in incompatible ways. If an implementation has made such
extensions, there may be user and system code which depends on them
and the cost of converting that code may be non-trivial. There is
presumably also documentation impact.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS avoids most or all of the
second-order costs of proposal GENERALIZE-EVAL.
The compiler processing for top-level forms might be implemented
something like:
;;; Forms read by the file compiler are passed to PROCESS-TOP-LEVEL-FORM
;;; with a env compile-time-too both NIL.
(defun process-top-level-form (form env compile-time-too)
(setq form (macroexpand form env))
(cond ((not (consp form))
nil)
((eq (car form) 'progn)
(dolist (f (cdr form))
(process-top-level-form f env compile-time-too)))
((eq (car form) 'compiler-let)
(process-compiler-let form env compile-time-too))
((eq (car form) 'macrolet)
(process-macrolet form env compile-time-too))
((eq (car form) 'symbol-macrolet)
(process-symbol-macrolet form env compile-time-too))
((eq (car form) 'eval-when)
(process-eval-when form env compile-time-too))
(t
(if compile-time-too
(internal-eval form env))
(compile-form form env))
))
(defun process-eval-when (form env compile-time-too)
(let* ((situations (cadr form))
(body (cddr form))
(compile-p (member 'compile situations))
(load-p (member 'load situations))
(eval-p (member 'eval situations)))
(cond ((or (and compile-p load-p)
(and eval-p load-p compile-time-too))
(process-top-level-form `(progn ,@body) env t))
(load-p
(process-top-level-form `(progn ,@body) env nil))
((or compile-p
(and eval-p compile-time-too))
(dolist (f body)
(internal-eval f env)))
(t
nil))))
;;; PROCESS-COMPILER-LET, PROCESS-MACROLET, and PROCESS-SYMBOL-MACROLET
;;; do the obvious things.
;;; INTERNAL-EVAL evaluates "form" in lexical environment "env".
Cost to Users:
Technically, none. Either proposal is technically upward compatible
with CLtL.
Proposal GENERALIZE-EVAL might force some extended implementations to
change incompatibly. As such, some users who depend on
implementation-dependent extensions might have to adjust their code
somewhat to deal with those changes.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS does not force implementations
to change incompatibly, so has no forced impact on users.
Cost of Non-Adoption:
EVAL-WHEN is a mess. Using it as the low-level substrate into which
defining macros should expand, and guaranteeing any predictable effects
of those macros in non-top-level situations is currently difficult and
would continue to be so in the absence of some resolution on this issue.
Benefits:
The costs of non-adoption would be avoided: it would be possible to
use EVAL-WHEN in many situations where it cannot currently be used
reliably.
The portability of many existing tools which use EVAL-WHEN internally
in macros will be enhanced.
Aesthetics:
This generalization of the meaning makes the purpose and uses of
EVAL-WHEN less mysterious. In that sense, aesthetics are simplified
somewhat.
Discussion:
The cleanup issue LOCALLY-TOP-LEVEL would make LOCALLY also "pass
through" top-level-ness to its body. The reason why that is not
addressed in this issue is that it involves making LOCALLY a special
form.
Pitman and Moon don't care whether we say `top level,' `top-level,' or
`toplevel.' The spelling choices in this writeup are arbitrary. If
necessary, the proposal GENERALIZE-EVAL-NEW-KEYWORDS could be amended
to propose :COMPILE-TOP-LEVEL, etc.
Pitman, Moon, and Bob Laddaga (a Symbolics Cloe implementor) support
both of these proposals. Pitman and Laddaga have a preference for
GENERALIZE-EVAL-NEW-KEYWORDS. Moon is neutral about which should be
preferred.
Sandra Loosemore says:
I still feel somewhat uncomfortable with the definition of EVAL-WHEN
presented here, mostly because its nesting behavior is so unintuitive
(as in test case number 6). We have also had a hard time in deciding
what the term "top-level" really means; the definition presented here
is rather arbitrary. However, since we have run out of time in which
to come up with acceptable alternatives, I'm willing to go along with
proposal GENERALIZE-EVAL. It is compatible with the description in
CLtL but presented in a more coherent way, and I think it is an
improvement. On the other hand, I don't really like the idea of
changing the names of the keywords; if we are going to make an
incompatible change, the right thing to do would be to throw out
EVAL-WHEN entirely and start from scratch.
Treating MACROLET and SYMBOL-MACROLET (and possibly LOCALLY)
complicates the treatment of top-level DEFMACROs and other
defining macros that cause functions to be created at compile-time
(because the lexical environment the functions are defined in may
not be null). See issue DEFINING-MACROS-NON-TOP-LEVEL for details.-------
∂23-Mar-89 1538 CL-Cleanup-mailer The Revised Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:33:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:44:52 PST
Date: 23 Mar 89 13:43 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: The Revised Cleanup Issue Status List
to: X3J13@sail.stanford.edu
Message-ID: <890323-134452-5540@Xerox>
This is the revised (as of 23-Mar-89 13:43:08) complete list of
Cleanup issues that are either:
passed: passed at *any* previous meeting, including Jan 89
pending: have been distributed for the March meeting
in progress: might possibly be distributed for the March meeting,
or that I think are worth pursuing.
Of course, some more might come up or be revived.
I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
clcleanup/pending
clcleanup/passed
directories respectively.
Codes:
! released for Jan 89 meeting
+ passed
* need new version
!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider
!
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Version 9, 17-Mar-89, released 21-mar-89
Comments: (whew!)
Status: ready for vote
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
! COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote
! COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ** NEED NEW VERSION **
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Comments: "and calls DESCRIBE recursively argument if there are ... "
status: need to strike "argument"; then vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Comments: (at end) + "can't extend by defining harmless...????"
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 3, 20-Mar-89
Status: vote?
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
! HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Comments: How about MAKE-LOAD-FORM-SAVING-SLOTS?
Status: ready for vote w/ name change?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13
!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
! PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: vote???
! PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote?
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
! PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
! REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 6, 17-Mar-89
Status: ready for vote?
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
! SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: ready for vote?
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***
! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal.
No version arrived.
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
! WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: ready?
∂23-Mar-89 1657 X3J13-mailer cl-compiler issue status as of Mar 23
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 16:23:32 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18840; Thu, 23 Mar 89 16:53:11 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12850; Thu, 23 Mar 89 16:53:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903232353.AA12850@defun.utah.edu>
Date: Thu, 23 Mar 89 16:53:06 MST
Subject: cl-compiler issue status as of Mar 23
To: x3j13@sail.stanford.edu
Here is the current list of active cl-compiler issues. I have mailed
out revised versions of most of the issues where we got some specific
comments on the previous version, and I've noted other comments below.
There will be hardcopies of all of the latest and greatest writeups
available at the meeting. I'm not anticipating that we will be
producing another round of revisions before then, so if you want
something changed, please be prepared to present an amendment at the
meeting.
CLOS-MACRO-COMPILATION (version 3)
Clarify compile-time behavior of CLOS defining macros.
Proposal MINIMAL
Proposal NOT-SO-MINIMAL
[New version distributed in response to comments.]
COMPILE-ENVIRONMENT-CONSISTENCY (version 5)
What kinds of things can/must the compiler "wire in" to the code
it compiles?
Proposal CLARIFY
[New version distributed in response to comments.]
COMPILE-FILE-SYMBOL-HANDLING (version 2)
How does COMPILE-FILE tell LOAD what package to put symbols in?
Proposal CURRENT-PACKAGE
Proposal HOME-PACKAGE
Proposal REQUIRE-CONSISTENCY
[Some people want to leave this unspecified.]
COMPILED-FUNCTION-REQUIREMENTS (version 5)
What does the COMPILED-FUNCTION type imply? Do COMPILE and
COMPILE-FILE construct COMPILED-FUNCTIONs?
Proposal TIGHTEN
Proposal TIGHTEN-COMPILE
Proposal FLUSH
[New version distributed in response to comments.]
COMPILER-DIAGNOSTICS (version 10)
Clarify status and handling of errors and warnings signalled during
compilation.
Proposal USE-HANDLER
[New version distributed in response to comments.]
COMPILER-LET-CONFUSION (version 8)
The description of COMPILER-LET in CLtL is broken -- should we fix
it or eliminate it entirely?
Proposal REPAIR
Proposal ELIMINATE
[New version distributed in response to comments.]
COMPILER-VERBOSITY (version 6)
Mechanisms for controlling progress messages issued by the compiler.
Proposal LIKE-LOAD
CONSTANT-CIRCULAR-COMPILATION (version 8)
Must circular or recursive objects be compiled correctly? Must the
compiler preserve sharing of substructures?
Proposal NO
Proposal PRESERVE-SHARING-ONLY
Proposal YES
[New version distributed in response to comments.
Expect amendment to change error terminology.]
CONSTANT-COLLAPSING (version 6)
Should the compiler be allowed to "collapse" or coalesce constants
that satisfy a more general equivalence relationship than EQUAL?
Proposal GENERALIZE
[New version distributed in response to comments.]
CONSTANT-COMPILABLE-TYPES (version 9)
What types of objects can appear as quoted or self-evaluating constants
in compiled code?
Proposal SPECIFY
[New version distributed in response to comments.]
CONSTANT-FUNCTION-COMPILATION (version 1)
What do we do about quoted function constants?
Proposal NO
[This is a new issue, split off from CONSTANT-COMPILABLE-TYPES. We
are willing to consider alternate proposals.]
DEFCONSTANT-NOT-WIRED (**DRAFT** version 6)
How do you declare a variable to be constant without giving the
compiler permission to make assumptions about its value?
[None of the proposals are ready to be voted on. This issue
is being distributed only for informational purposes.]
DEFINE-OPTIMIZER (version 6)
Provide a macro-like way of specifying source-level optimizations
on function calls.
Proposal NEW-FACILITY
[New version distributed in response to comments.]
DEFINING-MACROS-NON-TOP-LEVEL (version 9)
Are defining macros such as DEFUN meaningful in non-top-level locations?
Proposal ALLOW
[New version distributed in response to comments.]
EVAL-WHEN-NON-TOP-LEVEL (version 7)
What does EVAL-WHEN mean when it appears in non-top-level locations?
Proposal GENERALIZE-EVAL
Proposal GENERALIZE-EVAL-NEW-KEYWORDS
[New version distributed in response to comments.]
LOAD-TIME-EVAL (version 11)
Add a new special form, LOAD-TIME-VALUE.
Proposal R**2-NEW-SPECIAL-FORM
Proposal R**3-NEW-SPECIAL-FORM
[Proposal R**2-NEW-SPECIAL-FORM was approved at the January meeting,
but some additional suggestions were made after the meeting.]
MACRO-CACHING (version 2)
Is it legitimate to cache macro expansions?
Proposal DISALLOW
Proposal RESTRICT
[Moon suggested the presentation could be simplified.]
MACRO-ENVIRONMENT-EXTENT (**DRAFT** version 3)
Do environment objects received as the &ENVIRONMENT argument to a
macro have dynamic or indefinite extent?
Proposal INDEFINITE
Proposal DYNAMIC
Proposal DYNAMIC-WITH-COPIER
[Barmar wants the copier function renamed (to what?)]
PROCLAIM-ETC-IN-COMPILE-FILE (**DRAFT** version 4)
Are top-level calls to PROCLAIM handled specially by the compiler?
Proposal YES
Proposal NO
Proposal NEW-MACRO
[New name for DEFPROCLAIM?]
QUOTE-SEMANTICS (version 3) (replaces QUOTE-MAY-COPY)
May COMPILE and EVAL construct equivalent copies of quoted or
self-evaluating constants, or must constants share structure with
the source code for the program? Do the constraints on what objects
are valid constants also apply to COMPILE and EVAL, or only to
COMPILE-FILE?
Proposal NO-COPYING
Proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS
Proposal SAME-AS-COMPILE-FILE
[New version distributed in response to comments.]
SAFE-CODE (version 1)
What does the term "safe code" mean?
Proposal SAFETY-3
[This issue has been withdrawn.]
SYNTACTIC-ENVIRONMENT-ACCESS (version 6)
Provide accessors and constructors for lexical environment objects.
Proposal SMALL
[New version distributed in response to comments.]
WITH-COMPILATION-UNIT (version 3)
Provide a way to compile a group of files as a unit for the purposes
of error messages.
Proposal NEW-MACRO
[There have been complaints that the proposal is not ready to be
voted on.]
-------
∂23-Mar-89 1656 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:52:13 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03552g; Thu, 23 Mar 89 12:36:58 PST
Received: by pitney-bowes id AA26463g; Thu, 23 Mar 89 12:35:22 PST
Date: Thu, 23 Mar 89 12:35:22 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903232035.AA26463@pitney-bowes>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: X3J13@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 17:52 EST <19890321225242.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
PATHNAME-COMPONENT-VALUE:SPECIFY seems seriously flawed to me. I give
some reasons, a sktech of a strawman alternative, and some options to
consider. Pardon the length, but the issue is one of the messiest that
CL must deal with. If you're really pressed, search for "given all".
My particular concern is that by restricting pathname-names, for
example, to be strings, PATHNAME-COMPONENT-VALUE:SPECIFY hides the
semantics associated with a pathname behind host-specific string
parsing rules. ("Structured" names are forbidden.) My comments will
refer to pathname-names, but similar arguments should apply for
pathname-types and elements of directory lists.
Part of the rationale says:
Removing "structured" names should improve portability without causing
any harm, assuming no implementation uses structured names. This will
improve portability by allowing programs to do string manipulation on
names, although such programs still have to be careful since the valid
characters and maximum length of a name are implementation-dependent.
But I fail to see how string manipulation functions are particularly
useful or intuitive when porting the un*x c-shell wildcard name
"/foo/a?b.lisp" into an MVS pathname, where there is no system support
for single-character wildcards. I would rather specify something
like:
(MAKE-PATHNAME :DIRECTORY *source-dir*
:NAME '("a" :WILD-CHARACTER "b")
:EXTENSION "lisp")
and let CL handle the wildcard problem if the OS doesn't.
Also note that the "host" parsing rules may be something as specific
as a shell convention. E.e., un*x filesystems do not treat "*" at
all specially--that is done by the shells. Only a kind of peer
pressure keeps the shells and other utilities fairly consistent on a
given machine.
In spite of the paragraph quoted above from the rationale, I assume
the best motivation for hiding the semantics is to be able to defer
all such semantic questions to the host, to avoid any need to query
the host during normal pathname manipulations. I.e., when a user
types "a$b" for host foo, lisp don't need to query foo to discover
that this is a wildcard template or means burn after reading. (Don't
laugh--the "3" in "FOO LISP A3" for CMS means erase this file as soon
as the first reference is closed, as opposed to "FOO LISP A1" which
means treat this as a normal file, or "FOO LISP A7" which is illegal.)
Overall, I see three generic problems:
(1) To determine if a given pathname-name (e.g. "a$b") is a specific
filename or a template, one needs to invoke some as-yet
unspecified oracle. Something like the proposal
PATHNAME-EXTENSIONS would be needed to address this issue.
(2) To portably make a template to select a given set of filenames,
one needs to consult an unspecified inverse oracle.
>> I've seen no proposal that addresses this problem. <<
E.g., consider the problem of making a template that will match
all filenames on a given directory starting with "a" and ending
with "b". How would I write this??
Or consider the problem of finding all files that match "*foo*"
(using Unix csh conventions), but not "*.lisp". Under the
given proposal, one is forced to use the DIRECTORY function to
get truenames for all the "*.lisp" files before doing the
set-difference. This seems very clumsy and wasteful when
compared to what DIRECTORY could accomplish if it understood
pathnames containing regular expressions.
Also note that some operating systems (e.g. MVS) support the
notion of the "*" wildcard convention (wild string), but not
"?" (wild character). So the proposal mandates that it must be
impossible to portably create a pathname template for names of
three characters starting with "a" and ending with "b".
(3) OS oracles such as those proposed by PATHNAME-EXTENSIONS cannot
hope to address all novel or idiosyncratic features of
file-systems, except in the very weak sense of saying "here be
dragons". More informative oracles would be needed for
portability, so over time we must be prepared to augment the
standard or ports must write ad hoc oracles for things like
"A3" on CMS. This is only vaguely addressed through the
proposals about legal extensions to Common Lisp.
An alternative scheme (admittedly not perfect) would be to standardize
an internal format for things like wildcard templates, e.g.
("a" :WILD-STRING "b"). This addresses the three problems as follows:
(1) The first problem partially goes away--e.g., "a$b" could be
treated unambiguously as a three-character filename, even for
hosts where shells, etc. tend to treat "$" specially.
Templates would be required to be non-atomic objects, perhaps
lists starting with :WILD. (In effect, the oracle at this
level has been reduced to simple standardized rules on obvious
lisp data formats.)
Unfortunately, the problem has been pushed to another level,
since users are presumably typing filenames according to host-
specific conventions which they expect to be honored. Even if
the internal representation becomes largely host-independant,
parse-namestring may need to consult the same oracles mentioned
above to be able to internalize correctly. This could even be
pessimal in putting all of the semantic burden (hence perhaps
file-system queries) up front when it might otherwise be
avoided. In general though, there can be CL code to emulate
most of the parsing that would be done by the filesystem, and
there could be an escape such as (:UNPARSED "a$b"), to allow
parsing to be deferred until necessary.
On the whole, I think something like this alternative scheme
would win on this point.
(2) The second problem goes away (it was the original motivation
for this message). E.g., the rules for making a wildcard are
standardized and portable. (Of course, each implementor then
needs to interpret ("a" :WILD-STRING "b") appropriately, which
might involve the creation of a string like "a$b". But
implementors are trained to deal with such details.)
(3) The third problem comes back with a vengeance, since nothing
would be passed through "as is", and thus novel features by
definition would be prohibited. This could be addressed by
adding an escape that passes things through to the OS for
semantic parsing without CL attempting to understand them. How
users would indicate this option is problematic.
Given all of the above, I think a more flexible proposal for pathnames
would allow the name field (for example) to be structured as at least
any of the following:
"a*b" -- a 3-character filename, or
(:EXPLICIT "a*b") -- a 3-character filename
("a" :WILD-STRING "b") -- a template for filenames string with "a"
and ending with "b"
(:UNPARSED "a*b") -- a filename or template that may require
an OS request to disambiguate (when
parsed, this should yield a standard CL
format)
(:UNINTERPRETED "a*b") -- a filename or template that CL will not
attempt to understand (if used
inappropriately, the consequences are
undefined)
It should be a separate issue which of these (PARSE-NAMESTRING "a*b")
would produce.
PATHNAME-COMPONENT-VALUE:SPECIFY seems to give "a*b" the semantics of
:UNINTERPRETED and forbid all other options. Personally, I would
prefer to give "a*b" the semantics of :EXPLICIT and allow at least
these four options.
The rules for parse-namestring require more thought than I can afford
right now, but I hope this suffices to show that the stated proposal
is, unfortunately, far more problematic than advertized.
jlm
∂23-Mar-89 2100 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 21:00:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564017; Thu 23-Mar-89 17:34:54 EST
Date: Thu, 23 Mar 89 17:34 EST
From: CL-Cleanup@SAIL.Stanford.EDU
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Reply-To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: GENSYM-NAME-STICKINESS (Version 3)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890323173428.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
15-Mar-89, Version 2 by Steele (add GENSYM-COUNTER function)
20-Mar-89, Version 3 by Pitman (make it a variable)
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:LIKE-TEFLON)
Define that if an optional argument [either a string or a number] is
given to GENSYM, it does NOT have a side-effect on GENSYM's internal state.
Introduce a new variable, *GENSYM-COUNTER*, which holds the state of
the gensym counter. That is, the next symbol generated by GENSYM will
be number n. The initial value of this variable is not defined, but
must always be a non-negative integer. This variable may be either
assigned or bound by users at any time, but always to a non-negative
integer.
Deprecate the use of a numeric argument to GENSYM.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Occasionally you want to reset the GENSYM counter so that, for example,
you can get the compiler to generate the same symbol names again
(good for comparing results to see what really changed).
Test Case:
;; #1: Test stickiness of name part.
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
;; #2: Test stickiness of number part.
(= (PARSE-INTEGER (PROGN (GENSYM 6789) (STRING (GENSYM "G"))) :START 1)
6790)
=> T ;under CLtL
=> NIL ;under this proposal (except when *gensym-counter* happens to align)
;; #3: Illustrate use of new variable.
(STRING= (SYMBOL-NAME (LET ((*GENSYM-COUNTER* 43)) (GENSYM "FOO")))
"FOO43")
=> T ;under this proposal (not meaningful previously)
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
If any implementations currently use a more compact representation for
the internal state of GENSYM than a variable holding a string and a
separate variable holding an integer, they might be forced to change.
Even then, the change would proabably still be quite small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Making the gensym counter visible as a variable means that people will
be able to bind the gensym counter locally when they don't want to affect
the global counter.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman and Steele support LIKE-TEFLON.
∂23-Mar-89 2059 X3J13-mailer **DRAFT** Issue: PATHNAME-PRINT-READ (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 20:59:42 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 563865; 23 Mar 89 15:36:42 EST
Date: Thu, 23 Mar 89 15:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: PATHNAME-PRINT-READ (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890323153624.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE <<<
Ponder it and come prepared to discuss it at the meeting.
See summary of Cleanup discussion at end.
-kmp
-----
Issue: PATHNAME-PRINT-READ
References: File System Interface (pp409-427)
Category: CHANGE/ADDITION
Edit history: 21-Oct-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Although pathnames are required to print re-readably, there is no
standardized representation for pathnames and so no standardized
way in which they should print.
Further, it is common in programs to want pathnames to print in
their file-system specific format.
Proposal (PATHNAME-PRINT-READ:SHARPSIGN-P):
Define the reader syntax #P"..." to be equivalent to
#.(PARSE-NAMESTRING "...").
Define that when *PRINT-ESCAPE* is T, the syntax #P"..." is
how a pathname should be printed by WRITE (and hence by PRIN1,
PRINT, etc.). The "..." is the namestring representation of the
pathname.
Define that when *PRINT-ESCAPE* is NIL, WRITE writes a pathname
object P by writing (NAMESTRING p) instead.
Test Case:
(PARSE-NAMESTRING "foo.lisp")
=> #P"foo.lisp"
(FORMAT NIL "Written to ~A." #P"foo.bin")
=> "Written to foo.bin."
(TYPEP #P"foo.bin" 'PATHNAME)
=> T
Rationale:
This satisfies the stated goals.
[For :ESCAPE T] It will not be possible to make the printed
pathname printed representation totally portable because of
variations in file systems, but for different Common Lisp
implementations on the same file system, or for Common Lisp
systems running on file systems having compatible syntax,
portability would be improved by this specification.
Also, some implementations (eg, Symbolics Genera) use
specialized representations for pathnames on different file
systems. Eg, an MSDOS pathname is of type MSDOS-PATHNAME,
not just type PATHNAME. #S(PATHNAME ...) is not only more
verbose than necessary but might be misleading to some users
because the object created will not have a TYPE-OF PATHNAME.
[For :ESCAPE NIL] Printing the namestring of a pathname is
a common operation and it is convenient to have a shorthand
for doing it. Further, some implementations may be able to
optimize the presentation of a pathname in this mode by
printing it without actually consing the string.
Current Practice:
Symbolics Genera implements the proposed behavior.
Cost to Implementors:
Fairly minor changes to the readtable and the printer.
Cost to Users:
Users who now use the non-portable syntax #S(...) in order
to enter literal pathnames might have to change. [However,
implementations would be free to continue to support this
read syntax for compatibility.]
Cost of Non-Adoption:
Portability of code and data involving pathnames within a
given file system (or between suitably similar file systems)
would be hampered needlessly.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The #P syntax is pretty and hides unimportant details.
Discussion:
Pitman supports this change.
-----
Summary of discussion on CL-Cleanup:
EB noted that Lucid CL implements the proposed behavior and that there
is cost to users who define their own #P read macro. He weakly supports
the proposal but wishes someone had pursued a `generic pathnames' proposal.
Pierson noted that KCL uses #"...", but that this collides with proposed
syntax for Dick Waters' pretty printer. He also thinks #P is better
because it is already more widely used for that purpose.
Masinter noted that Envos Medley prints pathnames with the syntax
#.(pathname "asdf"), which he thinks is not as pretty as #P"asdf"
but currently more portable.
KMP and JonL raised the issues that #. has the disadvantage that it must
be parsed by the full Lisp engine, while #P can be parsed by something
simpler. Permitting #. leaves a gaping hole for trojan horses, and
also requires the presence of the evaluator in a delivery system.
MLY, GSB, Peirson, and IIM argued for not using up an extra dispatch
character.
MLY suggested #S(PATHNAME namestring [optional-host]).
IIM noted they use #.(PATHNAME namestring host) because different file
systems have different parsing conventions.
∂23-Mar-89 2059 X3J13-mailer **DRAFT** Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 20:59:16 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563835; Thu 23-Mar-89 15:19:53 EST
Date: Thu, 23 Mar 89 15:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890323151934.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE <<<
Ponder it and bring your comments to the meeting.
See summary of CL-Cleanup discussion at end.
-kmp
-----
Issue: PATHNAME-SYNTAX-ERROR-TIME
References: File System Interface (pp409-427)
Category: CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
There exist conceivable pathnames for which there is no valid mapping in a
particular implementation. CLtL is not clear about the time at which this
error might be detected.
For example, on file systems which constrain pathname-types to be three
letters or fewer, the type "LISP" is not valid. The question arises: when
is this error detected?
In some implementations, the error might be detected while forming the
pathname. That is, (MAKE-PATHNAME :TYPE "LISP") signals an error.
In some implementations, the error might be detected while forming the
namestring. That is, (MAKE-PATHNAME :TYPE "LISP") succeeds, but
(NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) signals an error.
In some implementations, validity checking might be done only by the host
operating system, so Lisp does not detect the error unless the operating
system complains. For example, (MAKE-PATHNAME :TYPE "LISP") succeeds,
and even (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) constructs a plausible
looking pathname, but (OPEN (NAMESTRING (MAKE-PATHNAME :TYPE "LISP"))) fails.
In some implementations, Lisp might make `friendly' corrections to the
pathname in order to form a namestring. For example,
(MAKE-PATHNAME :TYPE "LISP") might succeed, but
(NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) might produce a namestring with
an extension such as ".LIS" or ".LSP".
Similar issues might come up in file systems which don't allow wildcard
pathnames. Is :WILD allowed in a name or type slot and then disallowed
upon coercion to a pathname, or is :WILD complained about "up front"?
This phenomenon is a barrier to portability because if a program is
debugged in an implementation that does, for example, NAMESTRING-time
error checking, the programmer may be lulled into an expectation that
it is acceptable to construct and manipulate invalid pathnames as long
as the problem is caught before an attempt to call NAMESTRING is
attempted. On the other hand, another programmer may debug his code in
a Lisp which does early error checking of syntax and may assume that
he is home free if the pathname gets constructed correctly.
Proposal (PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION):
Clarify that operations such as MAKE-PATHNAME and MERGE-PATHNMES which
construct new pathnames do plausibility checking of their arguments
and signal an error rather than construct a pathname for which NAMESTRING
would not produce a valid pathname.
Rationale:
This would identify clearly to the programmer where he should expect an
error to be signalled for a pathname.
This would mean that fully constructed pathnames could reliably
be converted to namestrings.
Cost to Implementors:
Some implementors, especially those which rely on the operating system
to be the sole authority on pathname syntax, might have to introduce
some new syntax-checking facilities.
Implementations where this error checking is done later would have to be
changed both to do it earlier, and to not make the unwarranted assumption
that pathnames with no valid namestring representation are constructable.
Cost to Users:
The ability to represent non-viable pathnames for the purpose of merging
would be lost. This feature was not portably available, but was available
in some operating systems.
Some code which expected an error, but expected it at a different time
would have to be changed.
Proposal (PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION):
Clarify that it was valid to create a pathname which could not be
converted to a namestring. Require NAMESTRING (and related functions,
such as ENOUGH-NAMESTRING or any internal functions that might be used
in place of NAMESTRING by functions like OPEN and PROBE-FILE) to signal
an error for pathnames which do not represent valid filenames in the
designated file system.
Rationale:
This would identify clearly to the programmer where he should expect an
error to be signalled for a pathname.
This would allow the construction of pathnames for the sole purpose of
merging without causing what might seem to some as gratuitous errors.
Cost to Implementors:
Implementors who rely on the operating system to be the sole authority
on pathname syntax, might have to introduce some new syntax-checking
facilities.
Implementations where this error checking is done earlier would have to
be changed both to do it later, and to not make the unwarranted
assumption that any pathname has a valid namestring representation.
Cost to Users:
Early error checking of faulty pathnames would be lost.
Some code which expected an error, but expected it at a different time
would have to be changed.
Benefits:
Macsyma, for example, has encountered a need for "hostless" pathnames
(in merging). The concept makes no sense if every pathname must have
a namestring, because a pathname with no host cannot have a namestring.
However, if it's NAMESTRING's responsibility to signal an error, then
hostless pathnames are still useful for merging. Consider:
(MERGE-PATHNAMES (MAKE-PATHNAME :NAME "FRED") MARY)
This will override both the NAME and the HOST field of MARY because you
must currently have a host in every pathname. But if MAKE-PATHNAME did
not force the host, or if one could explicitly say :HOST NIL, then
such pathnames would be considerably more useful for merging.
Proposal (PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE):
Clarify that we were unable to reach agreement on this issue and that
the time at which this error detection occurs is not well-specified.
Advise the editorial group to warn users clearly about this known source
of program portability problems.
Rationale:
This implements the status quo.
Cost to Implementors:
None.
Cost to Users:
No existing code must be modified, but there is an ongoing cost
associated with providing error checking at multiple points in a
program because implementations disagree as to where an error
might be signalled. In some cases, the effects of having to handle
this in multiple places may cause unpleasant modularity violations.
Test Case:
See problem description.
Current Practice:
Symbolics Genera signals an error at pathname construction time if a
pathname will be invalid. Once a pathname is successfully constructed,
it can generally be assumed that NAMESTRING will always succeed.
Aesthetics:
Making this more well-defined would cause a definite aesthetic
improvement to some programs.
Discussion:
Pitman prefers PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION but
believes that anything is an improvement over ...:EXPLICITLY-VAGUE.
CL pathname functions were not adequate for use in Macsyma because
they did not adequately represent to-be-merged-only pathnames (a
feature used very extensively in Macsyma), because errors could be
signalled at radically different times. To get around this, Pitman
had to create a data structure in Macsyma called an MPATHNAME which
was only trivially different than a PATHNAME but which made it
possible to deal portably with this issue of when errors occurred
and what kinds of errors occured. Unfortunately, since none of the
CL functions worked on MPATHNAMEs, a whole series of functions,
also only trivially different, had to be created: MAKE-MPATHNAME,
MNAMESTRING, MERGE-MPATHNAMES, MPATHNAME-NAME, MPATHNAME-TYPE,
MOPEN, WITH-MOPEN-FILE, etc.
------
Summary of CL-Cleanup discussion:
Most of the mail was endorsements for option PATHNAME-CREATION.
Sandra brought up a tangential issue about truenames that eventually
became a separate issue.
I think I'm the only person pushing NAMESTRING-COERCION. I strongly
believe it is the right thing, and that PATHNAME-CREATION is suboptimal,
based on problems that have struck me with existing CL pathname system.
However, even PATHNAME-CREATION would be an improvement from a
portability standpoint and I am probably not going to push it because
there are compatibility issues on the side of PATHNAME-CREATION (many
implementations do this already), and because there are more important
issues for us to spend time on at the meeting.
[Please try to come prepared to vote yes on one or both of
PATHNAME-CREATION or NAMESTRING-COERCION so we don't have to fall back
on EXPLICITLY-VAGUE, which is a total loss for program portability.
-kmp]
∂24-Mar-89 0824 X3J13-mailer Re: 20 March cs proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Mar 89 08:24:29 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02507; Fri, 24 Mar 89 09:24:27 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA13370; Fri, 24 Mar 89 09:24:24 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903241624.AA13370@defun.utah.edu>
Date: Fri, 24 Mar 89 09:24:23 MST
Subject: Re: 20 March cs proposal
To: Thom Linden <baggins@IBM.com>
Cc: Common Lisp mailing <x3j13@sail.stanford.edu>
In-Reply-To: Thom Linden <baggins@IBM.com>, Wed, 22 Mar 89 15:01:01 PST
The organization of this document is much improved -- I found the
presentation to be much more coherent (although some of the proposals
still seem to be grouped in the wrong place) and was able to make some
connections between the various parts that I hadn't been able to make
before. However, there also seemed to be a few things that got lost
between the last version and this one.
Page 4: I find the use of the word "control" to describe non-graphic
characters confusing (it has too many other connotations). CLtL used
"non-graphic"; let's stick with that term.
Page 6: Something that appears to have gotten lost from the previous
version is removing the statement from CLtL that characters with
non-zero bits and font are not STANDARD-CHARs. As I understand your
proposals, you want STANDARD-CHARs to be STANDARD-CHARs regardless of
whether or not they have any attributes associated with them, right?
Page 7: "Redefine STRING-CHAR". Why not just remove/deprecate it
entirely? STRING-CHAR used to identify what characters could be
stored in a string; the new set of proposals has defined STRING so
that any character can be stored in one. Also, it seems like this
item doesn't really belong in this particular proposal (since it has
little to do with removing bits and fonts).
Page 12: "it is an error to insert an extended character into a base
string" => "the consequences are undefined"?
Page 14, section 2.4: Unless and until there is an ISO standard for
character registries, I think it would be silly to include the
proposals in this section in the standard. For example, implementors
would have to arbitrarily define their own repertoires and labels for
the characters they support, which would almost certainly be
incompatible with any standard that is eventually adopted as well as
with the repertoires defined by other implementations. This would
make it impossible to use the functions proposed in this section
portably.
Page 18: In proposal 2.5.1, what is the interpretation of the "name"
argument? Must it follow the same rules as described for the
:EXTERNAL-CODE option to OPEN below? Is a list valid? How about
the keyword :DEFAULT?
Page 18: The material in proposals 2.5.1 and 2.5.2 can not be used
portably, for two reasons. First, there are no standard names for
coded character sets being proposed here. Second, even if we
standardized names, implementations are not being required to support
any particular coded character sets. Therefore I believe this
functionality has no place in the standard. I wouldn't have any
objection to simply stating that OPEN can be extended to accept
additional keyword arguments that are treated in an
implementation-specific manner, or even saying that it takes an
:EXTERNAL-CODE keyword that is treated in an implementation-specific
manner, but let's at least be honest about the nonportability and
not mislead users into thinking these things are more portable than
they really are.
Page 19, Proposal 2.5.4: Given the discussion on page 11, it seems
like the right default :ELEMENT-TYPE is BASE-CHARACTER. But I won't
quibble about it.
Page 20, STRING-ENCODED-LENGTH: In the previous version of the
writeup, there was some verbiage (on page 14) that said that this
function takes a string or character object as its required argument.
This has been lost. Is this function now intended to take *any*
object as an argument and determine how much room its printed
representation will take?
I still think this function is useless as currently defined.
"Implementation defined units" is just too vague. I could probably be
convinced to vote for adding such a function if it were tied to the
FILE-POSITION function -- for example, define STRING-ENCODED-LENGTH as
the difference between what (FILE-POSITION output-stream) would be
after writing the string and its current value. It might also be
more appropriate to name it FILE-STRING-LENGTH or something like that
and rearrange the arguments to make it parallel FILE-POSITION and
FILE-LENGTH.
Page 20, Proposal 2.6.2: Why prohibit control (non-graphic) characters
from appearing in a symbol's print name? The context in which the
sentence this replaces appears has to do with how the reader deals
with the case of symbol names, not with restricting what characters
are valid in the print name.
Page 20, Proposal 2.6.4: "It is an error" => "the consequences are
undefined"?
-------
∂24-Mar-89 1457 X3J13-mailer **DRAFT** Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 89 14:57:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564943; Fri 24-Mar-89 17:57:27 EST
Date: Fri, 24 Mar 89 17:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
To: X3J13@SAIL.STANFORD.EDU
In-Reply-To: <890323155755.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890324225719.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Due to a lack of coordination on our part, both Kent and I sent
mailings labelled Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4).
The two mailings were quite different. Kent agrees that the one
he sent should be ignored and the one I sent on Wednesday is the
one you're supposed to read. Sorry about that.
∂25-Mar-89 2231 X3J13-mailer **DRAFT** Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Mar 89 22:31:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 565470; Sun 26-Mar-89 01:31:28 EST
Date: Sun, 26 Mar 89 01:30 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: READ-CASE-SENSITIVITY (Version 2)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890326013058.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE <<<
This is just for the reference of anyone still reading mail this close
to the meeting, so that you will have seen it in case it (or some further
revision) comes up at the meeting. If you have any comments, just bring
them to the meeting. Thanks. -kmp
-----
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts,
especially p 337, step 8, point 1.
CLtL p 360 ff: The Readtable
COPY-READTABLE (CLtL, p 361)
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: Version 1, 15-Feb-89, by Dalton
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
This behavior is not always desirable.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol, or else you must write a reader from scratch.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
Define a new settable function, (READTABLE-CASE <readtable>) to
control the reader's interpretation of case. The following values
may be given:
:UPCASE -- convert unescaped characters to upper-case, as now.
:DOWNCASE -- convert unescaped characters to lower-case.
:PRESERVE -- don't convert, leaving lower-case letters in lower
case and upper-case characters in upper case.
:INVERT -- convert lower-case to upper and upper-case to lower.
COPY-READTABLE copies the setting of READTABLE-CASE. The value of
READTABLE-CASE for the standard readtable is :UPCASE.
The READTABLE-CASE of a readtable also has significance when
printing. The case in which letters are printed is determined as
follows:
When READ-CASE is :UPCASE, upper-case letters are printed in the
case specified by *PRINT-CASE*.
When READ-CASE is :DOWNCASE, lower-case letters are printed in
the case specified by *PRINT-CASE*.
When READ-CASE is :PRESERVE, letters are printed in their own
case.
When READ-CASE is :INVERT, the case of all letters is inverted.
(The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
the first character and :DOWNCASE for the rest.)
The rules for escaping letters are also affected by the READTABLE-CASE.
If *PRINT-ESCAPE* is true, letters are escaped as follows:
When READ-CASE is :UPCASE, all lower-case letters must be escaped.
When READ-CASE is :DOWNCASE, all upper-case letters must be escaped.
Otherwise, no letters need be escaped.
Proposal (READ-CASE-SENSITIVITY:READTABLE-FUNCTION)
Define a new settable function (READTABLE-CHARACTER-TRANSLATION
<readtable>) to control the reader's interpretation of unescaped
constituent characters. The value may be any function of type
(FUNCTION (CHARACTER) CHARACTER). Where the reader now converts
such characters to upper case it should instead call the function
that is the value of READTABLE-CHARACTER-TRANSLATION for the current
readtable. (See CLtL, page 337, step 8, point 1.)
COPY-READTABLE copies the setting of READTABLE-CHARACTER-TRANSLATION.
The value for the standard readtable is CHAR-UPCASE.
The READTABLE-CHARACTER-TRANSLATION of a readtable also has
significance when printing. The reader recognizes certain functions
which control the reader's interpretation of case and alters its
behavior accordingly. This behavior is given by the following
correspondence between functions and the keywords described above.
[This is just to avoid repeating a lot of text.]
function keyword
CHAR-UPCASE :UPCASE
CHAR-DOWNCASE :DOWNCASE
IDENTITY :PRESERVE
CHAR-INVERT-CASE :INVERT
The function can be given either as a symbol or as one of the values
#'CHAR-UPCASE, #'CHAR-DOWNCASE, #'IDENTITY, #'CHAR-INVERT-CASE.
If the READTABLE-CHARACTER-TRANSLATION is not one of the functions
listed above, letters are always printed in their own case (in
particular, *PRINT-CASE* has no effect), and all characters in
symbol names are escaped if *PRINT-ESCAPE* is true.
Define a new function CHAR-INVERT-CASE of type (FUNCTION (CHARACTER)
CHARACTER) analogous to CHAR-UPCASE and CHAR-DOWNCASE. It attempts
to convert its argument to upper-case if the argument is lower-case
and to lower-case if the argument is upper-case.
Rationale:
There are a number of different ways to achieve case-sensitivity.
These proposals are fairly simple but provide all of the
functionality that one could reasonably expect.
By using a property of the readtable, we avoid introducing a new
special variable. Any code that wishes to control all of the
reader's parameters already takes *READTABLE* into account. A new
special variable would require such code to change.
:DOWNCASE is included for symmetry with :UPCASE. :INVERT is
included so that case conventions could be used in Common Lisp code
without requiring that the names symbols in the "LISP" package be
written in upper case. (Opinions vary as to whether is is advisable
to use such conventions, but this proposal leaves that choice to the
user.)
In order to avoid complex interactions between the case setting of
the readtable and *PRINT-CASE*, this proposal specifies a
significance for *PRINT-CASE* only when the case setting is :UPCASE
or :DOWNCASE. The meaning of *PRINT-CASE* when the readtable
setting is :DOWNCASE was chosen for its simplicity and for symmetry
with :UPCASE while still being useful.
Test Case:
;; keyword version
(let ((rt (copy-readtable nil)))
(mapcar
#'(lambda (case)
(setf (readtable-case rt) case)
(read-from-string "Zebra"))
'(:upcase :downcase :preserve :invert)))
=> (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
;readtable and *print-case* :upcase
Current Practice:
While there may not be any current implementation that supports
exactly this proposal, several implementations provide some means
for changing case sensitivity.
Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
the "preferred case" (the case of character in the print names of
standard symbols such as CAR) and whether or not the reader is case-
sensitive.
In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
can be used to make the translation of a letter be that same letter,
thus achieving case-sensitivity.
Xerox Medley has a function for setting a readtable flag that
determines case sensitivity.
Cost to Implementors:
Fairly small. The reader will be slightly slower and readtables
will be slightly more complex.
Cost to Users:
Slight. Programmers must already take into account the possibility
that *READTABLE* will be a non-standard readtable. Case-sensitivity
is no worse than character macros in this respect.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will be effectively impossible in Common Lisp.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposals:
The language will have greater symmetry, because it will be
possible to control the treatment of case on both input and output
instead of only on output (as is now the case).
The language will look less old-fashioned.
Against the proposals:
It is, perhaps, inconsistent to control case-sensitivity by a
readtable operation when other aspects of the reader, such as the
input base and the default float format (not to mention the
package), are controlled by special variables. However, it can be
argued that character-level syntax is determined chiefly by the
readtable. Case-sensitivity can be seen as analogous to character
macros in this respect.
Keywords vs function
The keyword proposal is somewhat simpler and avoids raising the
possibility of character translation that applies in general and
not just for unescaped constituents.
The function proposal is perhaps more elegant.
Discussion:
Dalton supports both proposals but slightly prefers READTABLE-CASE.
Version 1 of the proposal suggested a new global variable rather
than a property of the readtable. Pitman was strongly opposed to
that proposal and gave convincing arguments that it should be
dropped. Gray suggested that the readtable property should be a
function.
∂25-Mar-89 2239 X3J13-mailer **DRAFT** Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Mar 89 22:38:54 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 565475; Sun 26-Mar-89 01:38:41 EST
Date: Sun, 26 Mar 89 01:38 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890326013810.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE <<<
It's too late for any discussion, but this is just for the information
of anyone still tracking mail at this late date. If you have comments,
just bring them to the meeting. Thanks.
-kmp
-----
Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Forum: Cleanup
References: Numbers (pp193-232),
S:>kmp>cl>conditions>revision-18-notes.text.34
(formerly S:>kmp>cl-conditions.text.34),
Category: CHANGE
Edit history: 06-Mar-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
In many cases, CLtL specifies ``is an error'' situations for functions
in places that programmers would prefer to see an error signalled.
Reliably signalling an error accomplishes two things...
- It eases the development process by making it easier to notice errors
in a timely fashion.
- It makes it easier for code to reliably handle errors at runtime,
leading to greater robustness in delivered applications.
Proposal (ERROR-CHECKING-IN-NUMBERS-CHAPTER:SCARECROW): - a straw man...
ABS should signal TYPE-ERROR if its argument is not type NUMBER.
ACOS should signal TYPE-ERROR if its argument is not type NUMBER.
ACOS might signal ARITHMETIC-ERROR.
ACOSH should signal TYPE-ERROR if its argument is not type NUMBER.
ACOSH might signal ARITHMETIC-ERROR.
ASH should signal TYPE-ERROR if either argument is not type INTEGER.
ASH might signal ARITHMETIC-ERROR.
ASIN should signal TYPE-ERROR if its argument is not type NUMBER.
ASIN might signal ARITHMETIC-ERROR.
ASINH should signal TYPE-ERROR if its argument is not type NUMBER.
ASINH might signal ARITHMETIC-ERROR.
ATAN should signal TYPE-ERROR if exactly one argument is given and that
argument is not type NUMBER.
ATAN should signal TYPE-ERROR if exactly two arguments are given and
either argument is not type (AND NUMBER (NOT COMPLEX)).
ATAN might signal ARITHMETIC-ERROR.
ATANH should signal TYPE-ERROR if its argument is not type NUMBER.
ATANH might signal ARITHMETIC-ERROR.
BOOLE should signal TYPE-ERROR if its first argument is not type
(MEMBER #.BOOLE-CLR #.BOOLE-SET #.BOOLE-1 #.BOOLE-2
#.BOOLE-C1 #.BOOLE-C2 #.BOOLE-AND #.BOOLE-IOR
#.BOOLE-XOR #.BOOLE-EQV #.BOOLE-NAND #.BOOLE-NOR
#.BOOLE-ANDC1 #.BOOLE-ANDC2 #.BOOLE-ORC1 #.BOOLE-ORC2)
BOOLE should signal TYPE-ERROR if either its second or third
argument is not type INTEGER.
BYTE should signal TYPE-ERROR if either argument is not type INTEGER.
BYTE-POSITION might signal TYPE-ERROR if its argument is not a byte
specifier (something that was returned by the BYTE
function). Note that byte specifiers are not required
to be disjoint from other types, so this error checking
is only heuristic.
BYTE-SIZE might signal TYPE-ERROR if its argument is not a byte
specifier (something that was returned by the BYTE
function). Note that byte specifiers are not required
to be disjoint from other types, so this error checking
is only heuristic.
CEILING should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
CEILING should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
CEILING should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
CEILING might signal ARITHMETIC-ERROR.
COMPLEX should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
COMPLEX should signal TYPE-ERROR if its second argument is provided
but is not type (AND NUMBER (NOT COMPLEX)).
CONJUGATE should signal TYPE-ERROR if its argument is not type NUMBER.
CIS should signal TYPE-ERROR if its argument is not type
(AND NUMBERP (NOT COMPLEX)).
CIS might signal ARITHMETIC-ERROR.
COS should signal TYPE-ERROR if its argument is not type NUMBER.
COS might signal ARITHMETIC-ERROR.
COSH should signal TYPE-ERROR if its argument is not type NUMBER.
COSH might signal ARITHMETIC-ERROR.
DECF might signal SYNTAX-ERROR at semantic processing time.
DECF should signal TYPE-ERROR at runtime if the variable to be
incremented does not have a value of type NUMBER.
DECF might signal ARITHMETIC-ERROR at runtime.
DECODE-FLOAT should signal TYPE-ERROR if its argument is not type FLOAT.
DENOMINATOR should signal TYPE-ERROR if its argument is not type RATIONAL.
DEPOSIT-FIELD should signal TYPE-ERROR if its first argument is not type
INTEGER.
DEPOSIT-FIELD might signal TYPE-ERROR if its second argument is not a
bytespec (something returned by BYTE). Note that byte
specifiers are not required to be disjoint from other types,
so this error checking is only heuristic.
DEPOSIT-FIELD should signal TYPE-ERROR if its third argument is not type
INTEGER.
DPB should signal TYPE-ERROR if its first argument is not type INTEGER.
DPB might signal TYPE-ERROR if its second argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
DPB should signal TYPE-ERROR if its third argument is not type INTEGER.
EVENP should signal TYPE-ERROR if its argument is not type INTEGER.
FCEILING should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FCEILING should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FCEILING should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FCEILING might signal ARITHMETIC-ERROR.
FFLOOR should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FFLOOR should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FFLOOR should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FFLOOR might signal ARITHMETIC-ERROR.
FLOOR should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FLOOR should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FLOOR should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FLOOR might signal ARITHMETIC-ERROR.
FROUND should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FROUND should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FROUND should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FROUND might signal ARITHMETIC-ERROR.
FTRUNCATE should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FTRUNCATE should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
FTRUNCATE should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
FTRUNCATE might signal ARITHMETIC-ERROR.
GCD should signal TYPE-ERROR if any argument is not type INTEGER.
GCD might signal ARITHMETIC-ERROR.
EXP should signal TYPE-ERROR if its argument is not type NUMBER.
EXP might signal ARITHMETIC-ERROR.
EXPT should signal TYPE-ERROR if either argument is not type NUMBER.
EXPT might signal ARITHMETIC-ERROR. e.g., (EXPT 0 0.0)
FLOAT should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
FLOAT should signal TYPE-ERROR if its second argument is supplied
but is not type FLOAT.
FLOAT might signal ARITHMETIC-ERROR.
FLOAT-DIGITS should signal TYPE-ERROR if its argument is not type FLOAT.
FLOAT-PRECISION should signal TYPE-ERROR if its argument is not type FLOAT.
FLOAT-RADIX should signal TYPE-ERROR if its argument is not type FLOAT.
FLOAT-SIGN should signal TYPE-ERROR if its first argument is not type
FLOAT.
FLOAT-SIGN should signal TYPE-ERROR if its second argument is supplied
but is not type FLOAT.
INCF might signal SYNTAX-ERROR at semantic processing time.
INCF should signal TYPE-ERROR at runtime if the variable to be
incremented does not have a value of type NUMBER.
INCF might signal ARITHMETIC-ERROR at runtime.
INTEGER-DECODE-FLOAT should signal TYPE-ERROR if its argument is not
type FLOAT.
INTEGER-LENGTH should signal TYPE-ERROR if its argument is not type INTEGER.
IMAGPART should signal TYPE-ERROR if its argument is not type NUMBER.
ISQRT should signal TYPE-ERROR if its argument is not type (INTEGER 0).
ISQRT might signal ARITHMETIC-ERROR.
LCM should signal TYPE-ERROR if any argument is not type INTEGER.
LCM might signal ARITHMETIC-ERROR.
LDB might signal TYPE-ERROR if its first argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
LDB should signal TYPE-ERROR if its second argument is not type INTEGER.
LDB-TEST might signal TYPE-ERROR if its first argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
LDB-TEST should signal TYPE-ERROR if its second argument is not type INTEGER.
LOG should signal TYPE-ERROR if either argument is not type NUMBER.
LOG might signal ARITHMETIC-ERROR.
LOGAND should signal TYPE-ERROR if any argument is not type INTEGER.
LOGANDC1 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGANDC2 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGBITP should signal TYPE-ERROR if its first argument is not type
(INTEGER 0).
LOGBITP should signal TYPE-ERROR if its second argument is not type
INTEGER.
LOGCOUNT should signal TYPE-ERROR error if its argument is not type INTEGER.
LOGEQV should signal TYPE-ERROR if any argument is not type INTEGER.
LOGIOR should signal TYPE-ERROR if any argument is not type INTEGER.
LOGNAND should signal TYPE-ERROR if either argument is not type INTEGER.
LOGNOR should signal TYPE-ERROR if either argument is not type INTEGER.
LOGNOT should signal TYPE-ERROR error if its argument is not type INTEGER.
LOGORC1 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGORC2 should signal TYPE-ERROR if either argument is not type INTEGER.
LOGTEST should signal TYPE-ERROR if either argument is not type INTEGER.
LOGXOR should signal TYPE-ERROR if any argument is not type INTEGER.
MAKE-RANDOM-STATE should signal TYPE-ERROR if an argument is supplied
but is not type (OR (MEMBER NIL T) RANDOM-STATE).
MASK-FIELD might signal TYPE-ERROR if its first argument is not a bytespec
(something returned by BYTE). Note that byte specifiers are not
required to be disjoint from other types, so this error checking
is only heuristic.
MASK-FIELD should signal TYPE-ERROR if its second argument is not type
INTEGER.
MAX should signal TYPE-ERROR if any argument is not type
(AND NUMBERP (NOT COMPLEX)).
MAX might signal ARITHMETIC-ERROR.
MIN should signal TYPE-ERROR if any argument is not type
(AND NUMBERP (NOT COMPLEX)).
MIN might signal ARITHMETIC-ERROR.
MINUSP should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
MOD should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
MOD should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
MOD should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
MOD might signal ARITHMETIC-ERROR.
NUMERATOR should signal TYPE-ERROR if its argument is not type RATIONAL.
ODDP should signal TYPE-ERROR if its argument is not type INTEGER.
PHASE should signal TYPE-ERROR if its argument is not type NUMBER.
PHASE might signal ARITHMETIC-ERROR.
PLUSP should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
RANDOM should signal TYPE-ERROR if its first argument is not
type (INTEGER 1).
RANDOM should signal TYPE-ERROR if its second argument is supplied
but is not type RANDOM-STATE.
RANDOM-STATE-P will never signal an error.
RATIONAL should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
RATIONAL might signal ARITHMETIC-ERROR.
RATIONALIZE should signal TYPE-ERROR if its argument is not type
(AND NUMBER (NOT COMPLEX)).
RATIONALIZE might signal ARITHMETIC-ERROR.
REALPART should signal TYPE-ERROR if its argument is not type NUMBER.
REM should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
REM should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
REM should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
REM might signal ARITHMETIC-ERROR.
ROUND should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
ROUND should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
ROUND should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
ROUND might signal ARITHMETIC-ERROR.
SCALE-FLOAT should signal TYPE-ERROR if its first argument is not
type FLOAT.
SCALE-FLOAT should signal TYPE-ERROR if its second argument is not
type INTEGER.
SIGNUM should signal TYPE-ERROR if its argument is not type NUMBER.
SIN should signal TYPE-ERROR if its argument is not type NUMBER.
SIN might signal ARITHMETIC-ERROR.
SINH should signal TYPE-ERROR if its argument is not type NUMBER.
SINH might signal ARITHMETIC-ERROR.
SQRT should signal TYPE-ERROR if its argument is not type NUMBER.
SQRT might signal ARITHMETIC-ERROR.
TAN should signal TYPE-ERROR if its argument is not type NUMBER.
TAN might signal ARITHMETIC-ERROR.
TANH should signal TYPE-ERROR if its argument is not type NUMBER.
TANH might signal ARITHMETIC-ERROR.
TRUNCATE should signal TYPE-ERROR if its first argument is not type
(AND NUMBER (NOT COMPLEX)).
TRUNCATE should signal TYPE-ERROR if its second argument is supplied
but is not type (AND NUMBER (NOT COMPLEX)).
TRUNCATE should signal DIVISION-BY-ZERO if its second argument is
supplied and is zero.
TRUNCATE might signal ARITHMETIC-ERROR.
ZEROP should signal TYPE-ERROR if its argument is not type NUMBER.
* should signal TYPE-ERROR if any argument is not type NUMBER.
* might signal ARITHMETIC-ERROR.
+ should signal TYPE-ERROR if any argument is not type NUMBER.
+ might signal ARITHMETIC-ERROR.
- should signal TYPE-ERROR if any argument is not type NUMBER.
- might signal ARITHMETIC-ERROR.
/ should signal TYPE-ERROR if any argument is not type NUMBER.
/ should signal DIVISION-BY-ZERO if any divisor argument is zero.
/ might signal ARITHMETIC-ERROR.
/= should signal type-error if any argument is not type NUMBER.
/= might signal ARITHMETIC-ERROR.
1+ should signal TYPE-ERROR if any argument is not type NUMBER.
1+ might signal ARITHMETIC-ERROR.
1- should signal TYPE-ERROR if any argument is not type NUMBER.
1- might signal ARITHMETIC-ERROR.
< should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
< might signal ARITHMETIC-ERROR.
<= should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
<= might signal ARITHMETIC-ERROR.
= should signal TYPE-ERROR if any argument is not type NUMBER.
= might signal ARITHMETIC-ERROR.
> should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
> might signal ARITHMETIC-ERROR.
>= should signal TYPE-ERROR if any argument is not type
(AND NUMBER (NOT COMPLEX)).
>= might signal ARITHMETIC-ERROR.
Rationale:
This addresses the development and delivery concerns mentioned in the
Problem Description.
Current Practice:
Most implementations probably do not reliably signal the indicated
errors in safe code.
Cost to Implementors:
In implementations not providing the indicated error checking,
considerable work might need to be done.
The alternative is to identify the implementation as an "unsafe" subset.
However, while it is a "subset" in the sense that code that was developed
in it will run in the superset, it is important to understand that such
implementations are not simply "places you can run code that's been
thoroughly debugged in the full language" since such debugged code may
still depend on the reliable detection and handling of certain kinds of
errors.
Cost to Users:
Technically none. These are supposedly already all `is an error'
cases that people can't depend on.
Some users might be relying on an implementation not to signal a particular
error in compiled code. Such code is already not portable, however.
In some cases, where an implementation adds error checking that they
consider unnecessary, the user will need to add some OPTIMIZE proclamations.
Some users will see this as a bug fix.
Cost of Non-Adoption:
The error handling facilities will be a lot less useful.
Code that uses error handling will not port well.
Benefits:
Better development environments. More robust delivered applications.
Aesthetics:
Hopefully improved.
Discussion:
Pitman getting this level of detail is a good idea. He's ammenable to
specific changes if they improve the overall level of receptiveness to
the proposal.
Notes about how to proceed on this issue
(to be removed prior to final vote):
- Is anyone uncomfortable about the name ARITHMETIC-ERROR?
If so, can someone mathematically inclined suggest a better name?
`MATH-ERROR' or `NUMBER-ERROR' come to mind.
- In some of the cases of "might signal", it might be the case that
no signal should ever occur. Someone who's actually implemented these
functions might want to suggest that in some cases we can remove
this verbiage, or give examples of the circumstances under which the
condition might be signalled?
∂26-Mar-89 2005 X3J13-mailer **DRAFT** Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Mar 89 20:05:29 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 565792; Sun 26-Mar-89 23:05:21 EST
Date: Sun, 26 Mar 89 23:04 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890326230447.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> DO -NOT- REPLY TO THIS ISSUE <<<
No one is reading mail at this point anyway. (I don't even seriously
believe anyone will read -this- before the meeting, but I wanted it to
be on file just in case.) Just ponder it and bring any comments you
have to the meeting.
See additional notes at end.
-----
Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Forum: Cleanup
References: *PRINT-ESCAPE* (pp370-371), *PRINT-CASE* (pp372), WRITE
Category: CLARIFICATION
Edit history: 26-Jan-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The wording on page 372 of CLtL uses fuzzy terms that make it hard
to tell if *PRINT-ESCAPE* interacts with *PRINT-CASE*.
Paragraph 1 of the description of *PRINT-CASE* says "This variable
controls the case (upper, lower, or mixed) in which to print any
uppercase characters in the names of symbols when vertical-bar
syntax is used."
Paragraph 2 begins with the seemingly unambiguous statement "Lowercase
characters in the internal print name are always printed in lowercase"
but then goes on to muddy the water by saying "and are preceded by
a single escape character or enclosed by multiple escape characters".
This escaping presumably only happens in *PRINT-ESCAPE* T mode, which
leads one to wonder if other parts of the *PRINT-ESCAPE* description are
implicitly controlled by *PRINT-ESCAPE* as well.
The function WRITE is affected by implication.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-PRIN1):
Define that *PRINT-CASE* cases characters the same as PRIN1 would.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:LIKE-WRITE-STRING):
Define that *PRINT-CASE* has an effect only when *PRINT-ESCAPE* is T.
When *PRINT-CASE* is NIL, WRITE-STRING is used directly.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-NO-UPCASE):
Define that *PRINT-CASE* has an effect at all times when *PRINT-ESCAPE*
is NIL. Define that *PRINT-CASE* also has an effect when *PRINT-ESCAPE*
is T unless inside an escape context (i.e., unless between vertical bars
or after a slash). Under no circumstance is any character which was
lowercase in the internal representation ever presented as uppercase
due to *PRINT-CASE*.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:VERTICAL-BAR-RULE-PERMIT-UPCASE):
Like VERTICAL-BAR-RULE-NO-UPCASE, but permit *PRINT-CASE* to upcase
lowercase characters in the *PRINT-ESCAPE* NIL case since preservation of
Lisp syntax is not important there.
Proposal (PRINT-CASE-PRINT-ESCAPE-INTERACTION:EXPLICITLY-VAGUE):
Specify that the effect of *PRINT-CASE* when *PRINT-ESCAPE* is NIL
is implementation-dependent.
Test Case:
(LET ((RESULT '()) (TABWIDTH 12))
(DOLIST (SYMBOL '(|x| |FoObAr| |fOo|))
(LET ((TAB -1))
(FORMAT T "~&")
(DOLIST (ESCAPE '(T NIL))
(DOLIST (CASE '(:UPCASE :DOWNCASE :CAPITALIZE))
(FORMAT T "~VT" (* (INCF TAB) TABWIDTH))
(WRITE SYMBOL :ESCAPE ESCAPE :CASE CASE))))))
For each of the following, two clusters of output is shown. The first is
how an implementation which leans heavily on vertical bars might work.
The second is how an implementation which leans heavily on slash might
work. In fact, other interpretations are possible (mixing slash and
vertical bar). These examples are not an exhaustive analysis of the
implications of each proposal.
Possible outputs under LIKE-PRIN1:
|x| |x| |x| x x x
|FoObAr| |FoObAr| |FoObAr| FoObAr FoObAr FoObAr
|fOo| |fOo| |fOo| fOo fOo fOo
\x \x \x x x x
F\oO\bA\r f\oo\ba\r F\oo\ba\r FoObAr foobar Foobar
\fO\o \fo\o \fo\o fOo foo foo
Possible output under LIKE-WRITE-STRING:
|x| |x| |x| x x x
|FoObAr| |FoObAr| |FoObAr| FoObAr FoObAr FoObAr
|fOo| |fOo| |fOo| fOo fOo fOo
\x \x \x x x x
F\oO\bA\r f\oo\ba\r F\oo\ba\r FoObAr FoObAr FoObAr
\fO\o \fo\o \fo\o fOo fOo fOo
Possible output under VERTICAL-BAR-RULE-NO-UPCASE:
|x| |x| |x| x x x
|FoObAr| |FoObAr| |FoObAr| FoObAr foobar Foobar
|fOo| |fOo| |fOo| fOo foo foo
\x \x \x x x x
F\oO\bA\r f\oo\ba\r F\oo\ba\r FoObAr foobar Foobar
\fO\o \fo\o \fo\o fOo foo foo
Possible output under VERTICAL-BAR-RULE-PERMIT-UPCASE:
|x| |x| |x| X x X
|FoObAr| |FoObAr| |FoObAr| FOOBAR foobar Foobar
|fOo| |fOo| |fOo| FOO foo Foo
\x \x \x X x X
F\oO\bA\r f\oo\ba\r F\oo\ba\r FOOBAR foobar Foobar
\fO\o \fO\o \fO\o FOO foo Foo
Rationale:
It's silly for implementations to vary on this point.
Current Practice:
A strict reading of CLtL suggests that probably VERTICAL-BAR-RULE-NO-UPCASE
is the most correct.
Symbolics Genera doesn't do any of these. It was trying to do
VERTICAL-BAR-NO-UPCASE, but it had a bug which was about to be fixed when
this issue was raised.
Cost to Implementors:
Probably trivial.
Cost to Users:
Negligible in most cases. Probably very few users depend on this.
Those who do depend on it probably do so because they think the
behavior doesn't vary and probably don't get the portable behavior they
expect.
Cost of Non-Adoption:
Gratuitous variation between implementations.
Benefits:
Cost of non-adoption is avoided.
Aesthetics:
Anything that makes the language tighter probably improves aesthetics.
Only VERTICAL-BAR-RULE-PERMIT-UPCASE and LIKE-WRITE-STRING have really
useful behaviors in the :ESCAPE NIL situation. Of these, perhaps only
VERTICAL-BAR-RULE-PERMIT-UPCASE is really visually pleasant.
Discussion:
Pitman doesn't think the particular choice is very important. He just
wants the issue to be resolved. His slight preference is for
VERTICAL-BAR-RULE-PERMIT-UPCASE, then LIKE-WRITE-STRING, then either
of LIKE-PRIN1 or VERTICAL-BAR-RULE-NO-UPCASE. He sees no reason to go
with EXPLICITLY-VAGUE unless we deadlock.
Michael Greenwald, who raised the issue at Symbolics, doesn't have
a preference either but believes that CLtL (perhaps unintentionally)
leans toward VERTICAL-BAR-RULE-NO-UPCASE.
-----
Additional Discussion from CL-Cleanup:
David Gray responds:
> Possible output under VERTICAL-BAR-RULE-NO-UPCASE:
>
> |x| |x| |x| x x x
> |FoObAr| |FoObAr| |FoObAr| FoObAr foobar Foobar
> |fOo| |fOo| |fOo| fOo foo foo
This is exactly what the Explorer does.
There are several options for this issue, but if you're looking for one
to focus on, VERTICAL-BAR-RULE-NO-UPCASE is probably the one we'll push
if this issue comes up for discussion since it is believed most compatible
with current practice.
-kmp
∂26-Mar-89 2146 CL-Characters-mailer Really about TYPEP failures
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 26 Mar 89 21:46:40 PST
Received: from F.ILA.Dialnet.Symbolics.COM (DIAL|16174944833) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 326013; 27 Mar 89 00:44:44 EST
Received: from CALVARY.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 12127; Mon 27-Mar-89 00:45:13 EST
Date: Mon, 27 Mar 89 00:45 EST
From: Dennis L. Doughty <doughty@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: Really about TYPEP failures
To: David A. Moon <Moon@Riverside.SCRC.Symbolics.COM>
cc: Jon L White <jonl%lucid.com@Riverside.SCRC.Symbolics.Com>, Baggins%IBM.COM@Riverside.SCRC.Symbolics.Com,
CL-Characters%SAIL.STANFORD.EDU@Riverside.SCRC.Symbolics.Com, X3J13%SAIL.STANFORD.EDU@Riverside.SCRC.Symbolics.Com,
Common-Lisp-Implementors@Riverside.SCRC.Symbolics.Com, KMP@Riverside.SCRC.Symbolics.Com,
Palter@Riverside.SCRC.Symbolics.Com
In-Reply-To: <19890303033902.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890327054506.1.DOUGHTY@CALVARY.ILA.Dialnet.Symbolics.COM>
Date: Thu, 2 Mar 89 22:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Sat, 4 Feb 89 09:27 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Legitimate operations on BASE-CHARACTER do not
produce characters in (AND CHARACTER (NOT BASE-CHARACTER)).
I'm not sure which programs written using symbols in the LISP package
are "legitimate operations" and which are not.
What I had in mind was that the following function is not
legitimate:
(defun pick-a-char (char)
(code-char (mod (+ (random char-code-limit)
(code-char char))
char-code-limit)))
In other words, manipulating characters AS CHARACTERS doesn't
extend the range beyond the domain. Playing games with char-codes
can do all sorts of weird shit, but that's not part of the semantics
of the language.
However, I didn't see
anything in the 21 Feb 89 proposal that says that CHAR-UPCASE of
a BASE-CHARACTER is necessarily a BASE-CHARACTER, for example.
That doesn't sound unreasonable, though; should it be added?
Good point. Yes, I think so.
∂03-Apr-89 1231 X3J13-mailer compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89 12:31:06 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18809; Mon, 3 Apr 89 13:31:05 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA18372; Mon, 3 Apr 89 13:31:02 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904031931.AA18372@defun.utah.edu>
Date: Mon, 3 Apr 89 13:31:01 MDT
Subject: compiler issues
To: x3j13@sail.stanford.edu
Here is what happened to the various compiler issues that were
distributed prior to last week's meeting. The issues that were passed
will show up on cs.utah.edu in the ~ftp/pub/cl-compiler/passed
directory within the next day or two (all of the amendments were
fairly trivial this time). Further discussion on the issues that were
tabled will happen on the cl-compiler mailing list.
CLOS-MACRO-COMPILATION
Tabled for consideration of amendment.
COMPILE-ENVIRONMENT-CONSISTENCY
Tabled for consideration of amendment.
COMPILE-FILE-SYMBOL-HANDLING
We agreed to consider only some variant of proposal REQUIRE-CONSISTENCY.
Some people are unhappy with the restrictions on placement of
IN-PACKAGE and would like this fixed.
Tabled so we can produce a new proposal.
COMPILED-FUNCTION-REQUIREMENTS
A straw vote showed most people want to retain the COMPILED-FUNCTION
type. Proposal TIGHTEN had the most support, but some people wanted it
only to apply to COMPILE-FILE and not COMPILE.
Tabled so we can produce a new proposal.
COMPILER-DIAGNOSTICS
Proposal USE-HANDLER passed with amendment.
COMPILER-LET-CONFUSION
Proposal ELIMINATE passed.
COMPILER-VERBOSITY
Proposal LIKE-LOAD passed.
CONSTANT-CIRCULAR-COMPILATION
Proposal YES passed.
CONSTANT-COLLAPSING
Proposal GENERALIZE passed.
CONSTANT-COMPILABLE-TYPES
Proposal SPECIFY passed with amendment.
CONSTANT-FUNCTION-COMPILATION
Tabled so we can produce new proposals.
DEFINE-OPTIMIZER
Proposal NEW-FACILITY failed.
DEFINING-MACROS-NON-TOP-LEVEL
Proposal ALLOW passed.
EVAL-WHEN-NON-TOP-LEVEL
Proposal GENERALIZE-EVAL-NEW-KEYWORDS passed.
LOAD-TIME-EVAL
Proposal R**3-NEW-SPECIAL-FORM passed.
MACRO-CACHING
Tabled so we can simplify the writeup.
MACRO-ENVIRONMENT-EXTENT
Proposal DYNAMIC passed.
PROCLAIM-ETC-IN-COMPILE-FILE
Proposals YES and NO were eliminated. Proposal NEW-MACRO was tabled
for discussion of alternate names for the macro.
QUOTE-SEMANTICS
Proposal NO-COPYING passed.
SYNTACTIC-ENVIRONMENT-ACCESS
Tabled for further review.
WITH-COMPILATION-UNIT
Proposal NEW-MACRO passed with amendment.
-------
∂06-Apr-89 1220 X3J13-mailer June 26 - 28 meeting, Palo Alto, CA
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Apr 89 12:20:27 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01519g; Thu, 6 Apr 89 12:14:36 PDT
Received: by challenger id AA04159g; Thu, 6 Apr 89 12:09:45 PDT
Date: Thu, 6 Apr 89 12:09:45 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8904061909.AA04159@challenger>
To: x3j13@sail.stanford.edu
Subject: June 26 - 28 meeting, Palo Alto, CA
SUBCOMMITTEE MEETINGS:
DATE: 6/25
PLACE: TBA IF NECESSARY
COMMITTEE MEETING:
DATES: 6/26 - 6/28
TIME: 9:00 - 5:00
CITY: Palo Alto
PLACE: Rickey's Hyatt
ROOM: Executive Conference Room
ADDRESS: 4219 El Camino Real, Palo Alto, CA 94306
REGISTRATION FEE: $80 Payable to: LUCID, Inc.
HOTEL ACCOMODATIONS:
HOTEL: Rickey's Hyatt
ADDRESS: 4219 El Camino Real, Palo Alto, CA 94306
PHONE: 800/228-9000 or 415/493-8000
RATE: $110/night
MENTION: "X3J13" for rate
DIRECTIONS from airport:
From SFO: Take 101 south to San Antonio Road (about 25 minutes in non-rush
hour traffic). Take San Antonio Road exit marked Los Altos, heading toward the
hills. Turn right on El Camino Real. The hotel is on the right at 4219 El
Camino Real.
From San Jose: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real.
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13 June 1989 Meeting Registration Form
Please include check for $80.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Phone: ____________________________________________________________
Lunch 6/26: _________ yes _______ no
Lunch 6/27: _________ yes _______ no
Lunch 6/28: _________ yes _______ no
If Subcommitte Room is Needed:
Subcommittee Name? ___________________________
How many people will attend? __________
Meeting time? __________
Length of meeting? __________
∂06-Apr-89 1256 X3J13-mailer editorial issues summary
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Apr 89 12:55:56 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA17046; Thu, 6 Apr 89 12:56:48 PDT
Message-Id: <8904061956.AA17046@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17046; Thu, 6 Apr 89 12:56:48 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Apr 89 15:54
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: editorial issues summary
Editorial issues summary as of 4/6/89:
CUT-OFF-DATES - passed (amended)
FONTS - passed
TOC - passed (amended)
ERROR-TERMINOLOGY - passed (amended)
CONFORMANCE-POSITION - tabled (I'm rewriting)
SUBSETTING-POSITION - passed v.5
EXTENSIONS-POSITION - passed v.7
EXTRA-SYNTAX - failed
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS - failed
EXTRA-RETURN-VALUES - tabled (Pierson is adding list of functions?)
UNSPECIFIED-DATATYPES - failed
UNSOLICITED-MESSAGES - passed (amended)
MACRO-AS-FUNCTION:DISALLOW - passed v.2
Sections that "passed": 1.2, 1.3, 1.4, 2.1, 2.3, 2.4, 2.5, 5.2, 5.3, 5.4
∂06-Apr-89 1307 X3J13-mailer addition to editorial issues summary
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Apr 89 13:07:30 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA18241; Thu, 6 Apr 89 13:08:20 PDT
Message-Id: <8904062008.AA18241@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA18241; Thu, 6 Apr 89 13:08:20 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Apr 89 16:05
To: x3j13@sail.stanford.edu, @SKONA@decwrl.dec.com
Subject: addition to editorial issues summary
EXTENSIONS-POSITION:DOCUMENTATION passed (last message didn't give the
proposal that passed).
∂06-Apr-89 1305 X3J13-mailer Issue: ERROR-TERMINOLOGY (Version 8)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Apr 89 13:05:40 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA18113; Thu, 6 Apr 89 13:06:32 PDT
Message-Id: <8904062006.AA18113@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA18113; Thu, 6 Apr 89 13:06:32 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Apr 89 16:00
To: x3j13@sail.stanford.edu, @SKONA@decwrl.dec.com
Subject: Issue: ERROR-TERMINOLOGY (Version 8)
Version 7 as amended was accepted by X3J13 on 3/30/89.
Following is the amended version.
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
21-FEB-89, Version 5 by Chapman, added van Roggen, RPG comments
8-MAR-89, Version 6 by Gabriel, Moon, Pitman
21-MAR-89, Version 7 by Chapman (added another caveat to
definiton of Conforming Code)
6-APR-89, Version 8 by Chapman (added changes from 3/89 mtg)
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code does not use any constructions
that are prohibited by the standard.
(2) Conforming code does not depend on extensions
included in an implementation.
(3) Conforming code does not depend on the results of
undefined or unspecified situations.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necessarily code that does
not do error checking: Implementations are
permitted to treat all code as safe code all the time.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not
accessible in the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might be signalled in unsafe code.
Conforming code may rely on the fact that the error
will be signalled in safe code.
Every implementation is required to detect the error
at least in safe code. When the error is not
signalled, the "consequences are undefined"
(see below). For example, "+ should signal TYPE-ERROR
if any argument is not type NUMBER."
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the
results and effects of this situation as unpredictable
but harmless.
For example, "if the second argument
to SHARED-INITIALIZE specifies a name that does
not correspond to any slots accessible in the
instance, the results are unspecified."
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The
consequences may range from harmless to fatal. No
conforming code can depend on the results or
effects. Conforming code must treat the results and
effects as unpredictable. In places where the
words "must", "must not" or "may not" are used,
then "the consequences are undefined" if the stated
requirement is not met, and no specific consequence
is explicitly stated. It is permissible for an
error to be signalled in this case. For example: "Once
a name has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable has undefined consequences."
MIGHT SIGNAL AN ERROR The situation might have undefined consequences,
and a particular condition might be signalled.
For example, "OPEN might signal a condition of
type FILE-ERROR."
RETURN VALUES ARE UNSPECIFIED Only the number and nature of the return values
of a construct are not well specified but any
side-effect and transfer-of-control behavior is well
specified. For example, if the return values of some
function F are unspecified, then an expression such as
(length (list (F))) is still well-specified because it
does not rely on any particular aspect of the value or
values returned by F.
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
situation in ANY ONE of the following ways: (1)
When the situation occurs, an error should be
signalled at least in safe code, OR (2) When the
situation occurs, the "consequences are undefined",
OR (3) When the situation occurs, the consequences are
defined. Also, no conforming code can depend on
the results or effects of this situation, and all
conforming code must treat the results and effects
of the situation as undefined.
Implementations are required to document how the
situation is treated.
For example, "implementations may be extended to
define other type specifiers to have a corresponding
class."
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension.
Implementations are required to document each such
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
***************************************************************************
WARNING IS ISSUED A warning is issued, as described in WARN, in
both safe and unsafe code when the situation
is detected. Conforming code may rely on the
fact that a warning will be issued in both
safe and unsafe code when the situation is
detected. Every implementation is required to
detect this situation in both safe and unsafe
code when the situation is detected. The
presence of a warning will in no way alter the
value returned by the form which caused the
situation to occur. For example, "a warning is
issued if a declaration specifier is not one
of those defined in Chapter 9 of CLtL and has
not been declared in a DECLARATION
declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may
not rely on the fact that a warning will be
issued. If the situation is detected, a
warning may or may not be issued, depending on
the implementation. The presence of a warning
will in no way alter the value returned by the
form which caused the situation to occur. For
example, "a warning should be issued if a
variable declared to be ignored is referenced
or is also declared special, or if a variable
is lexical, never referenced, and not declared
to be ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
Rationale:
For the standard to be an exact specification, error terminology must be
defined and agreed upon.
Current Practice:
CLtL uses "is signalled", "should be signalled", "is an error",
"a warning is issued", and "a warning should be issued".
It also uses "is not permitted", "is desireable that", "is not legitimate",
"is illegal", and "should be" (not associated with "signalled"),
"must be", "must not", as well as other such terms.
The definition of "is an error" in CLtL has come to mean "is
allowed" in places where implementations typically extend the language.
CLOS and the Condition System use "is undefined" "is unspecified",
"may be extended", "free to extend the syntax", and "return values are
undefined".
Adoption Cost:
The cost of adopting this terminology will be mostly associated with the
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").
Benefits:
Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
Barmar comments:
"... I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue."
RPG responds:
"This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.
I doubt we will be able to settle this without fine tuning as we see
the effects in the document."
RPG also says:
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
To be more explicit, it is valid to specify what can happen if an illegal
operation is performed. If we are not able to list all such effects, users
can have two questions: Do *I* have to worry about detecting that my
program is about to perform this action because my run will be trashed, or
can I simply let it happen without worry? ``Undefined'' and
``unspecified'' are the terms that anwer these questions.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified. Second, the other clauses in the
definition must be read at the same time as you read the one about
harmless effects: programs that depend on the effects are not conforming.
Because *read-base* is something explicitly to depend upon, any change to
it behind your back is not harmless.
Certainly in the definition of harmless effects we can explicitly
rule out unspecified changes to things like *read-base* (we can enumerate
them if you like).
People seem to feel that if we cannot with mathematical precision define a
term we should not use it. The attitude to head in that direction is good,
but if you want to go all the way, we are sadly many years away from a
suitable draft. When I read the current draft (and CLtL for that matter) I
find that almost every paragraph requires my detailed knowledge of Lisp
(and sometimes Lisp implementation technology) to understand. Therefore,
we cannot hope for a self-contained document.
∂06-Apr-89 1316 X3J13-mailer UNSOLICITED-MESSAGES (version 6)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Apr 89 13:16:31 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA18854; Thu, 6 Apr 89 13:17:21 PDT
Message-Id: <8904062017.AA18854@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA18854; Thu, 6 Apr 89 13:17:21 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Apr 89 16:09
To: x3j13@sail.stanford.edu, @SKONA@decwrl.dec.com
Subject: UNSOLICITED-MESSAGES (version 6)
Version 5 as amended was passed by X3J13 on 3/30/89.
Following is the amended version.
Issue: UNSOLICITED-MESSAGES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
6-FEB-89, Version 2 by Chapman
10-MAR-89, Version 3 by Chapman (added discussion)
21-MAR-89, Version 4 by Chapman
24-MAR-89, Version 5 by Chapman
6-APR-89, Version 6 by Chapman (added amendment from 3/89 mtg)
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?
Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
No output may be produced
by functions other than that specified in the standard or due to the
signalling of conditions detected by the function.
Unsolicited output, such as GC notifications and autoload heralds,
should not go directly to the stream held by any
Common Lisp stream variable but can go indirectly to
*TERMINAL-IO* by using a synonym stream to that variable.
Output such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.
Rationale:
The intent of the proposal is stated informally as follows:
if a file is written to, no implementation-generated output should
end up in the file except as stated above.
The intent of paragraph 2 of the proposal is that
implementations are forced to make such streams possible to
redirect without redirecting the Common Lisp stream itself.
Current Practice:
Adoption Cost:
Small. Implementations and their documentation may have to change slightly.
Benefits:
Portability.
This proposal has very little impact on implementations, but helps the
user by explicitly stating the disposition of unsolicited output.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂07-Apr-89 1102 X3J13-mailer Did you blow it?
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Apr 89 10:59:26 PDT
Received: from fafnir.think.com by Think.COM; Fri, 7 Apr 89 13:23:25 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 7 Apr 89 13:23:54 EDT
Received: by verdi.think.com; Fri, 7 Apr 89 13:20:57 EDT
Date: Fri, 7 Apr 89 13:20:57 EDT
From: Guy Steele <gls@Think.COM>
Message-Id: <8904071720.AA18178@verdi.think.com>
To: rpg@lucid.com
Cc: gls@Think.COM, x3j13@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Thu, 6 Apr 89 15:19:42 PDT <8904062219.AA00440@challenger>
Subject: Did you blow it?
Date: Thu, 6 Apr 89 15:19:42 PDT
From: Richard P. Gabriel <rpg@lucid.com>
When I read the effect of Issue: DECLARE-TYPE-FREE on page 223, I
completely flipped. I think you might have gotten it wrong.
You say that in this code:
(defun f (x)
(declare (type float x))
(let ((x 'a)) ...)
...)
The declaration affects both bindings of x. This cannot make any sense
at all. I don't have marked which version of this issue passed, but I
think neither implies this. The most that is implied is that if you
say this:
(defun f (x)
...
(let ((y 'a))
(declare (type float x))
...)
...)
then the declaration applies to variable references within the let-y
and not to within some larger scope.
I hope you are wedged, because otherwise the proposal is wedged.
I also hope I am wedged. I am taking the liberty of cc'ing this
to X3J13 so that others can let me know what they think.
I believe I was confused by this paragraph from proposal
DECLARE-TYPE-FREE:LEXICAL, passed January 1989:
This proposal is equivalent to saying that the meaning of a type declaration
is equivalent to changing each reference to <var> within the scope of the
declaration to (THE <type> <var>), changing each expression assigned to the
variable within the scope of the declaration to (THE <type> <new-value>),
and executing (THE <type> <var>) at the moment the scope of the declaration
is entered.
The ambiguity concerns whether in
(defun f (x)
(declare (type float x))
x ;reference 1
(let ((x 'a)) ...)
x ;reference 2
...)
the two references are construed to be to the same *variable*.
(I readily grant that they refer to different *bindings*.)
I assumed that they were contrued to be the same variable,
in which case I believe that what I wrote on page 223 of the
CLtL II draft is a correct conclusion.
Now that you have pointed it out, I agree that a more likely
and more desirable interpretation is that the references are
considered to be to different variables. Question: what if x
had been proclaimed SPECIAL? Then what would the interpretation be?
--Guy
∂07-Apr-89 1420 X3J13-mailer Did you blow it?
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Apr 89 14:20:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 573609; Fri 7-Apr-89 17:19:10 EDT
Date: Fri, 7 Apr 89 17:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Did you blow it?
To: Guy Steele <gls@Think.COM>, rpg@lucid.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8904071720.AA18178@verdi.think.com>
Message-ID: <19890407211851.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 7 Apr 89 13:20:57 EDT
From: Guy Steele <gls@Think.COM>
Date: Thu, 6 Apr 89 15:19:42 PDT
From: Richard P. Gabriel <rpg@lucid.com>
When I read the effect of Issue: DECLARE-TYPE-FREE on page 223, I
completely flipped. I think you might have gotten it wrong.
He did.
You say that in this code:
(defun f (x)
(declare (type float x))
(let ((x 'a)) ...)
...)
The declaration affects both bindings of x. This cannot make any sense
at all. I don't have marked which version of this issue passed, but I
think neither implies this. The most that is implied is that if you
say this:
(defun f (x)
...
(let ((y 'a))
(declare (type float x))
...)
...)
then the declaration applies to variable references within the let-y
and not to within some larger scope.
I hope you are wedged, because otherwise the proposal is wedged.
I also hope I am wedged. I am taking the liberty of cc'ing this
to X3J13 so that others can let me know what they think.
I believe I was confused by this paragraph from proposal
DECLARE-TYPE-FREE:LEXICAL, passed January 1989:
This proposal is equivalent to saying that the meaning of a type declaration
is equivalent to changing each reference to <var> within the scope of the
declaration to (THE <type> <var>), changing each expression assigned to the
variable within the scope of the declaration to (THE <type> <new-value>),
and executing (THE <type> <var>) at the moment the scope of the declaration
is entered.
The ambiguity concerns whether in
(defun f (x)
(declare (type float x))
x ;reference 1
(let ((x 'a)) ...)
x ;reference 2
...)
the two references are construed to be to the same *variable*.
(I readily grant that they refer to different *bindings*.)
I assumed that they were contrued to be the same variable,
in which case I believe that what I wrote on page 223 of the
CLtL II draft is a correct conclusion.
The phrase "within the scope of the declaration" quoted above is
supposed to be a precisely defined phrase. The passed cleanup
issue DECLARATION-SCOPE was supposed to define that phrase.
Unfortunately, there is a problem: the precise language in version
2 of the proposal was replaced with much less precise language
in version 4, which was the version that was voted upon.
The version 2 language was:
The scope of a `bound' declaration is exactly the scope of the
associated lexical variable or function. If the declaration is
associated with a special variable, the scope is the scope the variable
would have had if it had not been special.
`Free' declarations are scoped as if they appeared in a new LOCALLY form
which surrounded the entire special form at the beginning of whose body
the declaration appears. This is the same as what CLtL p.155 defines to
be the scope of `pervasive' declarations.
This answers your question about special variables. I think that
for declarations that concern variable or function bindings, but are
not actually attached to a binding (i.e. are used free), the correct
scope is the same as the scope of a non-special binding of that name
surrounding the form to which the binding is attached; the language
about LOCALLY quoted above is out of date.
Gurg. Your example above is misindented. If you meant
(defun f (x)
(declare (type float x))
x ;reference 1
(let ((x 'a))
x ;reference 2
...)
then the scope of the declaration does not include (let ((x 'a)) x ...)
because type declarations are not "pervasive". Thus what you wrote
on p.223 of CLtL is wrong.
But if you meant
(defun f (x)
(declare (type float x))
x ;reference 1
(let ((x 'a)) ...)
x ;reference 2
...)
then the example does not address the question since reference 1
and reference 2 are clearly both in the scope of the type declaration.
Now that you have pointed it out, I agree that a more likely
and more desirable interpretation is that the references are
considered to be to different variables. Question: what if x
had been proclaimed SPECIAL? Then what would the interpretation be?
A special declaration should not affect the scope of a type declaration.
Now, the version of DECLARATION-SCOPING that actually passed does not
actually say that. But I don't think any other position is arguable.
∂08-Apr-89 1627 X3J13-mailer Did you blow it?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Apr 89 16:27:13 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA01867g; Sat, 8 Apr 89 16:21:16 PDT
Received: by bhopal id AA09518g; Sat, 8 Apr 89 16:27:49 PDT
Date: Sat, 8 Apr 89 16:27:49 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904082327.AA09518@bhopal>
To: gls@Think.COM
Cc: rpg@lucid.com, x3j13@sail.stanford.edu
In-Reply-To: Guy Steele's message of Fri, 7 Apr 89 13:20:57 EDT <8904071720.AA18178@verdi.think.com>
Subject: Did you blow it?
re:
I believe I was confused by this paragraph from proposal
DECLARE-TYPE-FREE:LEXICAL, passed January 1989:
This proposal is equivalent to saying that the meaning of a type
declaration is equivalent to changing each reference to <var> within
the scope of the declaration to (THE <type> <var>), changing each
expression assigned to the variable within the scope of the declaration
to (THE <type> <new-value>), and executing (THE <type> <var>) at the
moment the scope of the declaration is entered.
I don't have a copy of the proposal in front of me right now, but I
remember explicitly adding other paragraphs to this proposal which stress
that LET and LAMBDA bindings establish "new variables" which are "shielded"
from the outter scope's declarations.
Indeed, Maclisp had the "inheritance" behaviour which you are describing,
but CLtL is quite explicit about not doing that; and I'm sure that at
one time the proposal had wording in it to the effect that this wasn't
being changed.
-- JonL --
∂09-Apr-89 2059 X3J13-mailer Issue: DEFMACRO-LAMBDA-LIST, v3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 20:59:22 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 20:59:21 PDT
Date: 9 Apr 89 20:58 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DEFMACRO-LAMBDA-LIST, v3
To: X3J13@sail.stanford.edu
reply-to: Masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <890409-205921-3400@Xerox>
This is my rendition of this issue as passed at the Mar 89 X3J13; in fact, version 2, circulated in hardcopy, got amended at the meeting.
I have no record of any version of this being mailed to this distribution
list, so I'm circulating it now.
!
Status: Passed, as amended, Mar 89 X3J13
Issue: DEFMACRO-LAMBDA-LIST
Forum: Cleanup
References: 8.1 Macro Definition (CLtL pp144-151),
Issue DESTRUCTURING-BIND
Category: CLARIFICATION/CHANGE
Edit history: 30-Jan-89, Version 1 by Pitman
17-Mar-89, Version 2 by Masinter
9-Apr-89, Version 3 by Masinter
Incorporate amendments as per Mar 89 X3J13
Problem Description:
The description of the DEFMACRO lambda list currently contains some
mis-statements and leaves some ambiguities:
1. Can &BODY, &WHOLE, and &ENVIRONMENT appear at recursive levels of the
DEFMACRO lambda list?
The description of &WHOLE (p145) specifies that &WHOLE must occur ``first
in the lambda list,'' but the description of a lambda list says that
``a lambda may [recursively] appear in place of the parameter name.''
Consequently, the question arises whether &WHOLE should be permitted to
be a synonym for &REST at inner levels of a DEFMACRO lambda list.
The descriptions of &BODY and &ENVIRONMENT do not contain syntactic
restrictions on where they may appear.
2. Does using &WHOLE affect the pattern of arguments permitted by DEFMACRO.
Proposal (DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION):
1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.
b. Specify that &WHOLE may appear at any level of a DEFMACRO
lambda list. At inner levels, the &WHOLE variable is bound to
the corresponding part of the argument, as with &REST, but
unlike &REST, other arguments are also allowed.
c. Specify that &ENVIRONMENT may only appear at the top level of a
DEFMACRO lambda list.
2. Clarify that using &WHOLE does not affect the pattern of arguments
specified by DEFMACRO.
3. Clarify that &ENVIRONMENT may appear anywhere in the top level
of a DEFMACRO lambda list, as in the following examples:
(&whole W &environment E A B) ``After &Whole''
(&environment E &whole W A B) ``Before &Whole''
(&whole W A B &environment E) ``Last''
(&whole W A &environment E B) ``Middle''
Examples:
1. (DEFMACRO DM1A (&WHOLE FORM A B) ...) is defined.
(DEFMACRO DM1B (A (&WHOLE B C &OPTIONAL D) E) ...) is defined.
It allows simultaneousaccess to the THIRD of the whole
form as B and to the destructuring of that list into
C and D.
(DEFMACRO DM1C (A B &ENVIRONMENT ENV) ...) is defined.
(DEFMACRO DM1D (A (B &ENVIRONMENT ENV) C) ...) is undefined.
(DEFMACRO DM1E (A B &BODY X) ...) is defined.
(DEFMACRO DM1F (A (B &BODY X) C) ...) is defined.
2. (DEFMACRO DM2A (&WHOLE X) `',X)
(MACROEXPAND '(DM2A)) => (QUOTE (DM2A))
(MACROEXPAND '(DM2A A)) is an error.
(DEFMACRO DM2B (&WHOLE X A &OPTIONAL B) `'(,X ,A ,B))
(MACROEXPAND '(DM2B)) is an error.
(MACROEXPAND '(DM2B Q)) => (QUOTE ((DM2B Q) Q NIL))
(MACROEXPAND '(DM2B Q R)) => (QUOTE ((DM2B Q R) Q R))
(MACROEXPAND '(DM2B Q R S)) is an error.
Rationale:
1. a. An example on p151 makes it clear that this was the intent.
b. There's no cogent reason to forbid &WHOLE at inner levels.
The example on p.150 uses &WHOLE in a non-top-level position.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
c. The environment is never different at top level than embedded.
Permitting &ENVIRONMENT to occur embedded would only encourage
the misconception that there was a potential difference.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
2. This allows useful syntax checking.
One can always trivially write
(DEFMACRO ... (&WHOLE FORM &REST IGNORE) ...)
to get around the error checking this forces.
3. <vote at Mar 89 X3J13>
Current Practice:
1. a. Symbolics Genera permits &BODY at any level. This is compatible.
b. Symbolics Genera seems to permit &WHOLE at any level. When embedded,
it is treated as a synonym for &REST.
c. Symbolics Genera does not permit &ENVIRONMENT except at top level.
This is compatible.
2. Symbolics Genera has this behavior when &WHOLE appears at top level,
but not at recursive levels (where &WHOLE is treated as a synonym for
&REST).
Cost to Implementors:
This seems to be what CLtL intended and what most implementations
perform.
Cost to Users:
We think this is possibly (probably) upward compatible with most
current practice.
Cost of Non-Adoption:
Some fuzzy places in DEFMACRO continue to exist.
It's harder to introduce DESTRUCTURING-BIND because describing its relation
to DEFMACRO is difficult.
Benefits:
The language is a little tighter.
Aesthetics:
Negligible impact.
Discussion:
Part 2 of this issue came up during the discussion of DOTTED-MACRO-FORMS
but was not pursued until now.
Pitman supports these clarifications.
A previous version disallowed &WHOLE at inner levels, because
of the mistaken impression that &WHOLE was equivalent to &REST.
However, additional arguments are not allowed after &REST,
while they are for &WHOLE.
∂12-Apr-89 2156 X3J13-mailer Line Trouble
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Apr 89 21:55:51 PDT
Received: from [128.167.64.2] by RELAY.CS.NET id aa11356; 13 Apr 89 0:55 EDT
Received: from relay.cc.u-tokyo.ac.jp (junet-relay.gw.u-tokyo.ac.jp) by mtfuji.gw.u-tokyo.ac.jp (3.2/WIDE/JUNET-0.9)
id AA01463; Thu, 13 Apr 89 00:55:12 EDT
Received: from ccut.cc.u-tokyo.junet (ccutrd) by relay.cc.u-tokyo.ac.jp (3.2/6.3Junet-1.0/CSNET-JUNET)
id AA12066; Thu, 13 Apr 89 13:54:47 JST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA27277; Thu, 13 Apr 89 13:53:36 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.4J.BETA2-agu4)
id AA03834; Thu, 13 Apr 89 13:17:52 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
id AA03724; Thu, 13 Apr 89 13:18:27 JST
Date: Thu, 13 Apr 89 13:18:27 JST
From: Masayuki Ida <ida%cc.aoyama.junet@relay.cc.u-tokyo.ac.jp>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8904130418.AA03724@kepa.cc.aoyama.junet>
To: x3j13@SAIL.STANFORD.EDU
Cc: ida%cc.aoyama.junet@relay.cc.u-tokyo.ac.jp
Subject: Line Trouble
To whom it may concerned,
The mail link between US and Japan was stopped
from April 9th to April 12th EDT (and recovered).
The reason was on the mailer software at csnet-relay.
If you sent me E-mails during the above period,
please re-send it.
Thank you
Masayuki Ida
∂17-Apr-89 0933 X3J13-mailer Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 17 Apr 89 09:32:50 PDT
Received: by ti.com id AA05521; Mon, 17 Apr 89 11:34:24 CDT
Received: from Kelvin by tilde id AA24909; Mon, 17 Apr 89 11:26:31 CDT
Message-Id: <2817822347-9369097@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 17 Apr 89 11:25:47 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
Subject: Issue STREAM-DEFINITION-BY-USER (V1)
To: X3J13@SAIL.Stanford.edu
Many of you have seen this already, but it seemed time to give this
wider distribution. Having only received two comments on this version,
I've just appended a couple of notes to the end rather than generate a
new version.
Issue: STREAM-DEFINITION-BY-USER
References: CLtL pages 329-332, 378-381, and 384-385.
Related issues: STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
STREAM-CAPABILITIES
Category: ADDITION
Edit history: Version 1, 22-Mar-89 by David N. Gray
Status: For discussion and evaluation; not proposed for
inclusion in the standard at this time.
Problem description:
Common Lisp does not provide a standard way for users to define their
own streams for use by the standard I/O functions. This impedes the
development of window systems for Common Lisp because, while there are
standard Common Lisp I/O functions and there are beginning to be
standard window systems, there is no portable way to connect them
together to make a portable Common Lisp window system.
There are also many applications where users might want to define
their own filter streams for doing things like printer device control,
report formatting, character code translation, or
encryption/decryption.
Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS
Overview:
Define a set of generic functions for performing I/O. These functions
will have methods that specialize on the stream argument; they would
be used by the existing I/O functions. Users could write additional
methods for them in order to support their own stream classes.
Define a set of classes to be used as the superclass of a stream class
in order to provide some default methods.
Classes:
The following classes are to be used as super classes of user-defined
stream classes. They are not intended to be directly instantiated; they
just provide places to hang default methods.
FUNDAMENTAL-STREAM [Class]
This class is a subclass of STREAM and of STANDARD-OBJECT. STREAMP
will return true for an instance of any class that includes this. (It
may return true for some other things also.)
FUNDAMENTAL-INPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes INPUT-STREAM-P
to return true.
FUNDAMENTAL-OUTPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes OUTPUT-STREAM-P
to return true. Bi-direction streams may be formed by including both
FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.
FUNDAMENTAL-CHARACTER-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. It provides a method for
STREAM-ELEMENT-TYPE which returns CHARACTER.
FUNDAMENTAL-BINARY-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Any instantiable class that
includes this needs to define a method for STREAM-ELEMENT-TYPE.
FUNDAMENTAL-CHARACTER-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character input.
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character output.
FUNDAMENTAL-BINARY-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
FUNDAMENTAL-BINARY-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
Character input:
A character input stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
generic functions below.
STREAM-READ-CHAR stream [Generic Function]
This reads one character from the stream. It returns either a
character object, or the symbol :EOF if the stream is at end-of-file.
Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
method for this function.
Note that for all of these generic functions, the stream argument
must be a stream object, not T or NIL.
STREAM-UNREAD-CHAR stream character [Generic Function]
Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR. Returns
NIL. Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
a method for this function.
STREAM-READ-CHAR-NO-HANG stream [Generic Function]
This is used to implement READ-CHAR-NO-HANG. It returns either a
character, or NIL if no input is currently available, or :EOF if
end-of-file is reached. The default method provided by
FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
is sufficient for file streams, but interactive streams should define
their own method.
STREAM-PEEK-CHAR stream [Generic Function]
Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
It returns either a character or :EOF. The default method
calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.
STREAM-LISTEN stream [Generic Function]
Used by LISTEN. Returns true or false. The default method uses
STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR. Most streams should
define their own method since it will usually be trivial and will
always be more efficient than the default method.
STREAM-READ-LINE stream [Generic Function]
Used by READ-LINE. A string is returned as the first value. The
second value is true if the string was terminated by end-of-file
instead of the end of a line. The default method uses repeated
calls to STREAM-READ-CHAR.
STREAM-CLEAR-INPUT stream [Generic Function]
Implements CLEAR-INPUT for the stream, returning NIL. The default
method does nothing.
Character output:
A character output stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
generic functions below.
STREAM-WRITE-CHAR stream character [Generic Function]
Writes character to the stream and returns the character. Every
subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
defined for this function.
STREAM-LINE-COLUMN stream [Generic Function]
This function returns the column number where the next character
will be written, or NIL if that is not meaningful for this stream.
The first column on a line is numbered 0. This function is used in
the implementation of PPRINT and the FORMAT ~T directive. For every
character output stream class that is defined, a method must be
defined for this function, although it is permissible for it to
always return NIL.
STREAM-START-LINE-P stream [Generic Function]
This is a predicate which returns T if the stream is positioned at the
beginning of a line, else NIL. It is permissible to always return
NIL. This is used in the implementation of FRESH-LINE. Note that
while a value of 0 from STREAM-LINE-COLUMN also indicates the
beginning of a line, there are cases where STREAM-START-LINE-P can be
meaningfully implemented although STREAM-LINE-COLUMN can't be. For
example, for a window using variable-width characters, the column
number isn't very meaningful, but the beginning of the line does have
a clear meaning. The default method for STREAM-START-LINE-P on class
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
that is defined to return NIL, then a method should be provided for
either STREAM-START-LINE-P or STREAM-FRESH-LINE.
STREAM-WRITE-STRING stream string &optional start end [Generic Function]
This is used by WRITE-STRING. It writes the string to the stream,
optionally delimited by start and end, which default to 0 and NIL.
The string argument is returned. The default method provided by
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
STREAM-WRITE-CHAR.
STREAM-TERPRI stream [Generic Function]
Writes an end of line, as for TERPRI. Returns NIL. The default
method does (STREAM-WRITE-CHAR stream #\NEWLINE).
STREAM-FRESH-LINE stream [Generic Function]
Used by FRESH-LINE. The default method uses STREAM-START-LINE-P and
STREAM-TERPRI.
STREAM-FINISH-OUTPUT stream [Generic Function]
Implements FINISH-OUTPUT. The default method does nothing.
STREAM-FORCE-OUTPUT stream [Generic Function]
Implements FORCE-OUTPUT. The default method does nothing.
STREAM-CLEAR-OUTPUT stream [Generic Function]
Implements CLEAR-OUTPUT. The default method does nothing.
STREAM-ADVANCE-TO-COLUMN stream column [Generic Function]
Writes enough blank space so that the next character will be written
at the specified column. Returns true if the operation is
successful, or NIL if it is not supported for this stream.
This is intended for use by by PPRINT and FORMAT ~T. The default
method uses STREAM-LINE-COLUMN and repeated calls to
STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
STREAM-LINE-COLUMN returns NIL.
Other functions:
CLOSE stream &key abort [Generic Function]
The existing function CLOSE is redefined to be a generic function, but
otherwise behaves the same. The default method provided by class
FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P. The value returned
by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.
OPEN-STREAM-P stream [Generic Function]
This function [from proposal STREAM-ACCESS] is made generic. A
default method is provided by class FUNDAMENTAL-STREAM which returns
true if CLOSE has not been called on the stream.
STREAMP object [Generic Function]
INPUT-STREAM-P stream [Generic Function]
OUTPUT-STREAM-P stream [Generic Function]
These three existing predicates may optionally be implemented as
generic functions for implementations that want to permit users to
define streams that are not STANDARD-OBJECTs. Normally, the default
methods provided by classes FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM are sufficient. Note that, for example,
(INPUT-STREAM-P x) is not equivalent to (TYPEP x
'FUNDAMENTAL-INPUT-STREAM) because implementations may have
additional ways of defining their own streams even if they don't
make that visible by making these predicates generic.
STREAM-ELEMENT-TYPE stream [Generic Function]
This existing function is made generic, but otherwise behaves the
same. Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
which returns CHARACTER.
PATHNAME and TRUENAME are also permitted to be implemented as generic
functions. There is no default method since these are not valid for
all streams.
Binary streams:
Binary streams can be created by defining a class that includes either
FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
(or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
both of the following generic functions.
STREAM-READ-BYTE stream [Generic Function]
Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
stream is at end-of-file.
STREAM-WRITE-BYTE stream integer [Generic Function]
Implements WRITE-BYTE; writes the integer to the stream and returns
the integer as the result.
Rationale:
The existing I/O functions cannot be made generic because, in nearly
every case, the stream argument is optional, and therefore cannot be
specialized. Therefore, it is necessary to define a lower-level
generic function to be used by the existing function. It also isn't
appropriate to specialize on the second argument of PRINT-OBJECT because
it is a higher-level function -- even when the first argument is a
character or a string, it needs to format it in accordance with
*PRINT-ESCAPE*.
In order to make the meaning as obvious as possible, the names of the
generic functions have been formed by prefixing "STREAM-" to the
corresponding non-generic function.
Having the generic input functions just return :EOF at end-of-file, with
the higher-level functions handling the eof-error-p and eof-value
arguments, simplifies the generic function interface and makes it more
efficient by not needing to pass through those arguments. Note that the
functions that use this convention can only return a character or
integer as a stream element, so there is no possibility of ambiguity.
Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
defeated proposal STREAM-INFO, but the motivation here is different.
This interface needs to be defined if user-defined streams are to be
able to be used by PPRINT and FORMAT ~T, which could be viewed as a
separate question from whether the user can call them on
system-defined streams.
Current practice:
No one currently supports exactly this proposal, but this is very
similar to the stream interface used in CLUE.
On descendants of the MIT Lisp Machine, streams can be implemented
by users as either flavors, with methods to accept the various
messages corresponding to the I/O operations, or as functions, which
take a message keyword as their first argument.
Examples:
;;;; Here is an example of how the default methods could be
;;;; implemented (omitting the most trivial ones):
(defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
(let ((character (stream-read-char stream)))
(unless (eq character :eof)
(stream-unread-char stream character))
character))
(defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
(let ((char (stream-read-char-no-hang stream)))
(and (not (null char))
(not (eq char :eof))
(progn (stream-unread-char stream char) t))))
(defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
(let ((line (make-array 64 :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(loop (let ((character (stream-read-char stream)))
(if (eq character :eof)
(return (values line t))
(if (eql character #\newline)
(return (values line nil))
(vector-push-extend character line)))))))
(defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
(equal (stream-line-column stream) 0))
(defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
string &optional (start 0)
(end (length string)))
(do ((i start (1+ i)))
((>= i end) string)
(stream-write-char stream (char string i))))
(defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
(stream-write-char stream #\newline)
nil)
(defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
(if (stream-start-line-p stream)
nil
(progn (stream-terpri stream) t)))
(defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream)
column)
(let ((current (stream-line-column stream)))
(unless (null current)
(dotimes (i (- current column) t)
(stream-write-char stream #\space)))))
(defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
(defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
;; allow the two classes to be mixed in either order
(typep stream 'fundamental-input-stream))
(defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
(defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
(typep stream 'fundamental-output-stream))
;;;; Following is an example of how the existing I/O functions could
;;;; be implemented using standard Common Lisp and the generic
;;;; functions specified above. The standard functions being defined
;;;; are in upper case.
;; Internal helper functions
(proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
(defun decode-read-arg (arg)
(cond ((null arg) *standard-input*)
((eq arg t) *terminal-io*)
(t arg)))
(defun decode-print-arg (arg)
(cond ((null arg) *standard-output*)
((eq arg t) *terminal-io*)
(t arg)))
(defun check-for-eof (value stream eof-errorp eof-value)
(if (eq value :eof)
(report-eof stream eof-errorp eof-value)
value))
(defun report-eof (stream eof-errorp eof-value)
(if eof-errorp
(error 'end-of-file :stream stream)
eof-value))
;;; Common Lisp input functions
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p)) ; a mistake in CLtL?
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(if (null peek-type)
(check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
(loop
(let ((value (stream-peek-char stream)))
(if (eq value :eof)
(return (report-eof stream eof-errorp eof-value))
(if (if (eq peek-type t)
(not (member value '(#\space #\tab #\newline
#\page #\return #\linefeed)))
(char= peek-type value))
(return value)
(stream-read-char stream))))))))
(defun UNREAD-CHAR (character &optional input-stream)
(stream-unread-char (decode-read-arg input-stream) character))
(defun LISTEN (&optional input-stream)
(stream-listen (decode-read-arg input-stream)))
(defun READ-LINE (&optional input-stream (eof-error-p t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(multiple-value-bind (string eofp)
(stream-read-line stream)
(if eofp
(if (= (length string) 0)
(report-eof stream eof-error-p eof-value)
(values string t))
(values string nil)))))
(defun CLEAR-INPUT (&optional input-stream)
(stream-clear-input (decode-read-arg input-stream)))
(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char-no-hang stream)
stream eof-errorp eof-value)))
;;; Common Lisp output functions
(defun WRITE-CHAR (character &optional output-stream)
(stream-write-char (decode-print-arg output-stream) character))
(defun FRESH-LINE (&optional output-stream)
(stream-fresh-line (decode-print-arg output-stream)))
(defun TERPRI (&optional output-stream)
(stream-terpri (decode-print-arg output-stream)))
(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
(stream-write-string (decode-print-arg output-stream) string start end))
(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
(let ((stream (decode-print-arg output-stream)))
(stream-write-string stream string start end)
(stream-terpri stream)
string))
(defun FORCE-OUTPUT (&optional stream)
(stream-force-output (decode-print-arg stream)))
(defun FINISH-OUTPUT (&optional stream)
(stream-finish-output (decode-print-arg stream)))
(defun CLEAR-OUTPUT (&optional stream)
(stream-clear-output (decode-print-arg stream)))
;;; Binary streams
(defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
(check-for-eof (stream-read-byte binary-input-stream)
binary-input-stream eof-errorp eof-value))
(defun WRITE-BYTE (integer binary-output-stream)
(stream-write-byte binary-output-stream integer))
;;; String streams
(defclass string-input-stream (fundamental-character-input-stream)
((string :initarg :string :type string)
(index :initarg :start :type fixnum)
(end :initarg :end :type fixnum)
))
(defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
(make-instance 'string-input-stream :string string
:start start :end (or end (length string))))
(defmethod stream-read-char ((stream string-input-stream))
(with-slots (index end string) stream
(if (>= index end)
:eof
(prog1 (char string index)
(incf index)))))
(defmethod stream-unread-char ((stream string-input-stream) character)
(with-slots (index end string) stream
(decf index)
(assert (eql (char string index) character))
nil))
(defmethod stream-read-line ((stream string-input-stream))
(with-slots (index end string) stream
(let* ((endline (position #\newline string :start index :end end))
(line (subseq string index endline)))
(if endline
(progn (setq index (1+ endline))
(values line nil))
(progn (setq index end)
(values line t))))))
(defclass string-output-stream (fundamental-character-output-stream)
((string :initform nil :initarg :string)))
(defun MAKE-STRING-OUTPUT-STREAM ()
(make-instance 'string-output-stream))
(defun GET-OUTPUT-STREAM-STRING (stream)
(with-slots (string) stream
(if (null string)
""
(prog1 string (setq string nil)))))
(defmethod stream-write-char ((stream string-output-stream) character)
(with-slots (string) stream
(when (null string)
(setq string (make-array 64. :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(vector-push-extend character string)
character))
(defmethod stream-line-column ((stream string-output-stream))
(with-slots (string) stream
(if (null string)
0
(let ((nx (position #\newline string :from-end t)))
(if (null nx)
(length string)
(- (length string) nx 1))
))))
Cost to Implementors:
Given that CLOS is supported, adding the above generic functions and
methods is easy, since most of the code is included in the examples
above. The hard part would be re-writing existing I/O functionality in
terms of methods on these new generic functions. That could be
simplified if methods can be defined to forward the operations to the
old representation of streams. For a new implementation, the cost could
be zero since an approach similar to this would likely be used anyway.
Cost to Users:
None; this is an upward-compatible addition. Users won't even
need to know anything about this unless they actually need this feature.
Cost of non-adoption:
Development of portable I/O extensions will be discouraged.
Performance impact:
This shouldn't affect performance of new implementations (assuming an
efficient CLOS implementation), but it could slow down I/O if it were
clumsily grafted on top of an existing implementation.
Benefits:
A broader domain of programs that can be written portably.
Esthetics:
This seems to be a simple, straight-forward approach.
Discussion:
This proposal incorporates suggestions made by several people in
response to an earlier outline. So far, no one has expressed opposition
to the concept. There are some differences of opinion about whether
certain operations should have default methods or required methods:
STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
and STREAM-START-LINE-P.
An experimental prototype of this has been successfully implemented on
the Explorer.
This proposal does not provide sufficient capability to implement
forwarding streams such as for MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
MAKE-ECHO-STREAM. The generic function approach does not lend itself as
well to that as a message passing model where the intermediary does not
need to know what all the possible messages are. A possible way of
extending it for that would be to define a class
(defclass stream-generic-function (standard-generic-function) ())
to be used as the :generic-function-class option for all of the I/O
generic functions. This would then permit doing something like
(defmethod no-applicable-method ((gfun stream-generic-function) &rest args)
(if (streamp (first args))
(apply #'stream-operation-not-handled (first args) gfun (rest args))
(call-next-method)))
where stream-operation-not-handled is a generic function whose default
method signals an error, but forwarding streams can define methods that
will create a method to handle the unexpected operation. (Perhaps
NO-APPLICABLE-METHOD should be changed to take two required arguments
since all generic functions need at least one required argument, and
that would make it unnecessary to define a new generic function class
just to be able to write this one method.)
Another thing that is not addressed here is a way to cause an instance
of a user-defined stream class to be created from a call to the OPEN
function. That should be part of a separate issue for generic functions
on pathnames. If that capability were available, then PATHNAME and
TRUENAME should be required to be generic functions.
An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
streams. It isn't clear whether that simple approach is sufficient or
whether the larger set of classes is really needed.
---------
End of version 1.
Additional discussion:
It has been suggested that "FUNDAMENTAL" may be too verbose; might be
better to drop it or perhaps replace with something like "BASIC" or
"SIMPLE".
It should be made clear that implementations don't have to call the
generic functions unless they do not otherwise know what to do.
∂18-Apr-89 2212 X3J13-mailer Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Apr 89 21:30:55 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03079; Tue, 18 Apr 89 10:23:13 PDT
Message-Id: <8904181723.AA03079@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA03079; Tue, 18 Apr 89 10:23:13 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Apr 89 13:19
To: x3j13@sail.stanford.edu
Subject: Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
21-FEB-89, Version 5 by Chapman, added van Roggen, RPG comments
8-MAR-89, Version 6 by Gabriel, Moon, Pitman
21-MAR-89, Version 7 by Chapman (added another caveat to
definiton of Conforming Code)
6-APR-89, Version 8 by Chapman (added changes from 3/89 mtg)
14-APR-89, Version 9 by Chapman (added SAFE-CODE clarification
from RPG
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code does not use any constructions
that are prohibited by the standard.
(2) Conforming code does not depend on extensions
included in an implementation.
(3) Conforming code does not depend on the results of
undefined or unspecified situations.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
Thus the phrase "the function F should signal an
error" means that if F is invoked from code processed
with the highest SAFETY optimization, an error will
be signalled. It is implementation-dependent whether
F or the calling code will signal the error.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necessarily code that does
not do error checking: Implementations are
permitted to treat all code as safe code all the time.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not
accessible in the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might be signalled in unsafe code.
Conforming code may rely on the fact that the error
will be signalled in safe code.
Every implementation is required to detect the error
at least in safe code. When the error is not
signalled, the "consequences are undefined"
(see below). For example, "+ should signal TYPE-ERROR
if any argument is not type NUMBER."
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the
results and effects of this situation as unpredictable
but harmless.
For example, "if the second argument
to SHARED-INITIALIZE specifies a name that does
not correspond to any slots accessible in the
instance, the results are unspecified."
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The
consequences may range from harmless to fatal. No
conforming code can depend on the results or
effects. Conforming code must treat the results and
effects as unpredictable. In places where the
words "must", "must not" or "may not" are used,
then "the consequences are undefined" if the stated
requirement is not met, and no specific consequence
is explicitly stated. It is permissible for an
error to be signalled in this case. For example: "Once
a name has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable has undefined consequences."
MIGHT SIGNAL AN ERROR The situation might have undefined consequences,
and a particular condition might be signalled.
For example, "OPEN might signal a condition of
type FILE-ERROR."
RETURN VALUES ARE UNSPECIFIED Only the number and nature of the return values
of a construct are not well specified but any
side-effect and transfer-of-control behavior is well
specified. For example, if the return values of some
function F are unspecified, then an expression such as
(length (list (F))) is still well-specified because it
does not rely on any particular aspect of the value or
values returned by F.
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
situation in ANY ONE of the following ways: (1)
When the situation occurs, an error should be
signalled at least in safe code, OR (2) When the
situation occurs, the "consequences are undefined",
OR (3) When the situation occurs, the consequences are
defined. Also, no conforming code can depend on
the results or effects of this situation, and all
conforming code must treat the results and effects
of the situation as undefined.
Implementations are required to document how the
situation is treated.
For example, "implementations may be extended to
define other type specifiers to have a corresponding
class."
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension.
Implementations are required to document each such
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
***************************************************************************
WARNING IS ISSUED A warning is issued, as described in WARN, in
both safe and unsafe code when the situation
is detected. Conforming code may rely on the
fact that a warning will be issued in both
safe and unsafe code when the situation is
detected. Every implementation is required to
detect this situation in both safe and unsafe
code when the situation is detected. The
presence of a warning will in no way alter the
value returned by the form which caused the
situation to occur. For example, "a warning is
issued if a declaration specifier is not one
of those defined in Chapter 9 of CLtL and has
not been declared in a DECLARATION
declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may
not rely on the fact that a warning will be
issued. If the situation is detected, a
warning may or may not be issued, depending on
the implementation. The presence of a warning
will in no way alter the value returned by the
form which caused the situation to occur. For
example, "a warning should be issued if a
variable declared to be ignored is referenced
or is also declared special, or if a variable
is lexical, never referenced, and not declared
to be ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
Rationale:
For the standard to be an exact specification, error terminology must be
defined and agreed upon.
Current Practice:
CLtL uses "is signalled", "should be signalled", "is an error",
"a warning is issued", and "a warning should be issued".
It also uses "is not permitted", "is desireable that", "is not legitimate",
"is illegal", and "should be" (not associated with "signalled"),
"must be", "must not", as well as other such terms.
The definition of "is an error" in CLtL has come to mean "is
allowed" in places where implementations typically extend the language.
CLOS and the Condition System use "is undefined" "is unspecified",
"may be extended", "free to extend the syntax", and "return values are
undefined".
Adoption Cost:
The cost of adopting this terminology will be mostly associated with the
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").
Benefits:
Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
Barmar comments:
"... I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue."
RPG responds:
"This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.
I doubt we will be able to settle this without fine tuning as we see
the effects in the document."
RPG also says:
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
To be more explicit, it is valid to specify what can happen if an illegal
operation is performed. If we are not able to list all such effects, users
can have two questions: Do *I* have to worry about detecting that my
program is about to perform this action because my run will be trashed, or
can I simply let it happen without worry? ``Undefined'' and
``unspecified'' are the terms that anwer these questions.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified. Second, the other clauses in the
definition must be read at the same time as you read the one about
harmless effects: programs that depend on the effects are not conforming.
Because *read-base* is something explicitly to depend upon, any change to
it behind your back is not harmless.
Certainly in the definition of harmless effects we can explicitly
rule out unspecified changes to things like *read-base* (we can enumerate
them if you like).
People seem to feel that if we cannot with mathematical precision define a
term we should not use it. The attitude to head in that direction is good,
but if you want to go all the way, we are sadly many years away from a
suitable draft. When I read the current draft (and CLtL for that matter) I
find that almost every paragraph requires my detailed knowledge of Lisp
(and sometimes Lisp implementation technology) to understand. Therefore,
we cannot hope for a self-contained document.
∂25-May-89 0020 X3J13-mailer Letter ballot status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 25 May 89 00:20:45 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA07024; Mon, 22 May 89 03:10:38 PDT
Message-Id: <8905221010.AA07024@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA07024; Mon, 22 May 89 03:10:38 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 22 May 89 05:54
To: x3j13@sail.stanford.edu
Subject: Letter ballot status
Over a month ago (the day the first of the letter ballots was due
to be mailed) I sent a message to X3J13 about the status of the letter
ballots in general since the formation of the drafting committee.
Last week I found out that many people did not receive that message.
Here's a summary of what was said.
The drafting committee members have divided the standard up into
review pieces. The pieces and review dates are similar to the
breakdown in CUT-OFF-DATES. However, the letter ballot procedure has been
modified. It is possible that votes will be taken on certain sections
at the June meeting, but no letter ballots will be sent before then.
Please feel free to request all or part of the standard for review
at any time. Your comments will be taken into account and are greatly
appreciated. Consult CUT-OFF-DATES for section names and order of
reviewing, and let me know what medium is convenient for you.
The current goal of the drafting committee it to have a draft ready
for submission to the ISO committee at the end of July.
Please let me know if there are any questions.
kathy chapman
∂25-May-89 0047 X3J13-mailer CONFORMANCE-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 25 May 89 00:47:42 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06334; Mon, 22 May 89 02:53:29 PDT
Message-Id: <8905220953.AA06334@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06334; Mon, 22 May 89 02:53:29 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 22 May 89 05:51
To: x3j13@sail.stanford.edu
Subject: CONFORMANCE-POSITION
This issue has been heavily revised since the March meeting.
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
6-FEB-89, Version 5 by Chapman
20-FEB-89, Version 6 by Chapman
5-MAY-89, Version 7 by Chapman
22-MAY-89, Version 8 by Chapman (including Moon comments)
Problem Description:
Two ways of defining conformance are in terms of conforming code
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-CODE)
The standard presents the syntax and semantics to be implemented by
a conforming implementation. In addition, it levies requirements on
conforming code and documentation.
Definitions:
Code: One or more Common Lisp forms meant to be evaluated.
Extension: A facility in the implemented language that is not given in this
standard but that does not cause any ambiguity or contradiction when added
to the language standard.
Implementation-defined: Possibly differing between processors, but defined
for any particular processor.
Implementation-dependent: Possibly differing between processors and not
necessarily defined for any particular processor.
Portable code: Required to produce equivalent results and
observable side effects in all conforming implementations.
Portable code is written using only STANDARD-CHAR-P characters.
Processor: A system or mechanism that accepts code as input, prepares
it for execution, and executes the process so defined with data to produce
results.
Conformance:
A processor conforming with the requirements of this standard shall:
1. accept all the features of the language specified in this standard,
with the meanings defined in this standard.
2. not require the inclusion of substitute or additional language elements in
code in order to accomplish a feature of the language that is specified
in this standard.
3. be accompanied by a document that provides a definition of all
implementation-defined features.
4. treat exceptional situations in the manner specified in section 1.4 of
the standard (i.e. the Definitions section. It contains the error terminology.).
5. be accompanied by a document that separately describes any features accepted
by the processor that are prohibited or not specified in this standard.
Such extensions shall be described as being ``extensions to Common Lisp
as specified by ANSI ...''.
6. produce a conformance statement as a consequence of using the processor,
or that statement shall be included in the accompanying documentation.
If the processor conforms in all respects with this standard, the conformance
statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>''
If the processor conforms with some but not all of the requirements of this
standard, then the conformance statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>
with the following exceptions:
<followed by a reference to, or a complete list of, the requirements of
the standard with which the processor does not conform>.
Code conforming with the requirements of this standard shall:
1. use only those features of the language specified in this standard.
2. not rely on any particular interpretation of implementation-dependent
features.
Note that conforming code may rely on particular implementation-defined values
or features. Also note that the requirements for conforming code and
conforming processors do not require that the results produced by conforming
code are always the same when processed by a conforming processor. They may
be, or they may differ, pending on the code.
Informally, the basic rules for conformance are as follows:
1. Conforming code is defined in terms of its structure,
and not in terms of its results and side effects.
2. Conforming code is written using only the syntax specified in the standard.
3. Conforming code is written in only the sequence specified in the standard.
4. Conforming code is written using only the functions, macros,
special forms, variables, and constants specified in the standard.
5. Conforming implementations provide the functionality and behavior
specified in the standard.
The definitions of all names and syntax that aren't specified in the
standard must accompany the code.
6. Conformance is not machine-checkable.
It's possible for a conformal code to
run in all conformal implementations, but to have allowable
implementation-defined behavior that could make it non-portable.
Insofar as we allow options in the standard this will be true.
Rationale:
The standard must contain information about conformance.
Current Practice:
CLtL generally describes things in terms of what correct code can
expect, but the document itself levies the requirement on an implementation
to support all the described functionality.
dpANS C also defined conformance in terms of code.
It has further defined both "conforming" and "strictly conforming" code.
Pascal defines conformance in terms of both, PL/I defines conformance in
terms of conforming code only.
Fortran and Ada say that a conforming implementation correctly processes
conforming code. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both code and implementations.
Adoption Cost:
The use of the words "implementation-defined" and "implementation-dependent"
in CLtL and the standard will have to be checked to make sure the uses
and the definitions given above coincide. Any changes that occur as a
result of this check could potentially affect some user code, but it's
unlikely.
Implementations will have to be checked to make sure they conform with the
rules stated above, and conformance statements will have to be added.
Documentation may have to be updated.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
The information in this issue was derived from three documents:
the C ANSI standard, the "Proposed Draft Techinical Report-Guidelines on the
preparation of conformity clauses in porogramming languages and Letter Ballot"
(CT22/87-094, ISO/TC97/SC22/WG12 N133 Rev 1, October, 1987), and
"Specification for Computer programming language Pascal" (BS 6192:1982,
UDC 681.3.06 Pascal: 519.682).
∂25-May-89 1039 X3J13-mailer Re: CONFORMANCE-POSITION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 89 10:34:18 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09941; Thu, 25 May 89 11:34:38 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09105; Thu, 25 May 89 11:34:36 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905251734.AA09105@defun.utah.edu>
Date: Thu, 25 May 89 11:34:34 MDT
Subject: Re: CONFORMANCE-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com, 22 May 89 05:51
Two comments on terminology:
> Code: One or more Common Lisp forms meant to be evaluated.
Or compiled? Actually, the definition of "form" in the glossary
already includes intention to be evaluated. As you're using it here,
"code" just seems to be a synonym for a collection of forms.
Sometimes in talking about compiler issues, I use "code" to refer to
the representation of a program that includes both source code (forms)
and compiled code, which is distinct from this definition which
includes only source code.
> Processor: A system or mechanism that accepts code as input, prepares
> it for execution, and executes the process so defined with data to produce
> results.
This doesn't make sense. What "process so defined"? Defined where?
Is this referring to the process or algorithm embodied in the code, or
to the process of evaluating the code that is specified in the
standard? If the latter is the intent, I'd suggest some wording like
"executes it as specified in the standard" instead. Where does the
data come from? Finally, some code may have no observable results or
side-effects.
-Sandra
-------
∂25-May-89 1247 X3J13-mailer CONFORMANCE-POSITION
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 May 89 12:47:02 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 25 May 89 10:55:30 EDT
Date: Thu, 25 May 89 10:54 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: CONFORMANCE-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8905220953.AA06334@decwrl.dec.com>
Message-Id: <19890525145454.9.BARMAR@OCCAM.THINK.COM>
Date: 22 May 89 05:51
From: chapman%aitg.DEC@decwrl.dec.com
Issue: CONFORMANCE-POSITION
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
6-FEB-89, Version 5 by Chapman
20-FEB-89, Version 6 by Chapman
5-MAY-89, Version 7 by Chapman
22-MAY-89, Version 8 by Chapman (including Moon comments)
A processor conforming with the requirements of this standard shall:
...
5. be accompanied by a document that separately describes any features accepted
by the processor that are prohibited or not specified in this standard.
Such extensions shall be described as being ``extensions to Common Lisp
as specified by ANSI ...''.
...
Informally, the basic rules for conformance are as follows:
...
5. Conforming implementations provide the functionality and behavior
specified in the standard.
The definitions of all names and syntax that aren't specified in the
standard must accompany the code.
I think these clauses need to be worked on. They were presumably lifted
from the C standard, but they don't make as much sense in Lisp as they
do there, at least the way they are currently worded. In C, they are
talking primarily about reserved words that are used by a particular
implementation.
The problem is that the above specifies that ALL names defined by an
implementation be documented. In most Lisp implementations there are
many internal functions and variables that are accessible to user code,
not all of which should be documented (on Lisp Machines, there are
thousands of them, since this includes the entire operating system). The
package system allows applications to be insulated from these additional
names; I believe we've already approved an issue that disallows
implementations to add symbols to the LISP and USER packages, so this
insulation is guaranteed.
These conformance clauses should be specified so that they only apply to
additional syntax and behavior of standard-defined operators. They
should also be required to document the names of all the packages
defined by the implementation, so that the user will be able to avoid
(or at least recognize) conflicts.
barmar
∂26-May-89 0901 X3J13-mailer Windows Standards Discussion at 6/26 Palo Alto Meeting
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 26 May 89 09:00:16 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA26192; Fri, 26 May 89 09:00:13 PDT
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA29780; Fri, 26 May 89 08:58:46 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA06166; Fri, 26 May 89 09:00:11 PDT
Message-Id: <8905261600.AA06166@suntana.sun.com>
To: mathis@ctc.contel.com
Cc: x3j13@sail.stanford.edu, rao.pa@xerox.com, york@symbolics.com,
kempf@Sun.COM
Subject: Windows Standards Discussion at 6/26 Palo Alto Meeting
Date: Fri, 26 May 89 09:00:08 PDT
From: kempf@Sun.COM
Bob:
There has recently been a surge of interest in a standardized application
programmer's interface (API) for windows in Common Lisp. I would like to
reserve some time at the June meeting for a discussion of critera for
a standardized Common Lisp window system API. If possible, I suggest that
we reserve two hours in the afternoon on June 26, perhaps 3-5. We have three
individuals who are interested in giving 15-20 minute presentations.
They are myself, representing Sun, Ramana Rao, representing Xerox Parc, and
Bill York, representing International Lisp Associates. If anyone else is
interested, they can contact me and we can extend the time to accomodate them.
After the presentations, we will have a discussion on whether and how to proceed
in developing a standardized Common Lisp window system API.
Could you pencil this into the agenda?
jak
∂26-May-89 1058 X3J13-mailer CONFORMANCE-POSITION
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 May 89 10:58:43 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA07061g; Fri, 26 May 89 10:57:22 PDT
Received: by bhopal id AA17543g; Fri, 26 May 89 10:56:56 PDT
Date: Fri, 26 May 89 10:56:56 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905261756.AA17543@bhopal>
To: barmar@Think.COM
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Thu, 25 May 89 10:54 EDT <19890525145454.9.BARMAR@OCCAM.THINK.COM>
Subject: CONFORMANCE-POSITION
re: I believe we've already approved an issue that disallows
implementations to add symbols to the LISP and USER packages, so this
insulation is guaranteed.
Uh, which proposal is it that forbids the user from using the USER package?
-- JonL --
∂26-May-89 1418 X3J13-mailer Re: CONFORMANCE-POSITION
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 26 May 89 14:18:08 PDT
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA21288; Fri, 26 May 89 14:19:39 PDT
Date: Fri, 26 May 1989 14:19:38 PDT
From: Tim Koschmann <tdk@sumex-aim.stanford.edu>
To: chapman%aitg.dec@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
Subject: Re: CONFORMANCE-POSITION
Message-Id: <CMM.0.88.612220778.tdk@sumex-aim.stanford.edu>
I think maybe the proposal would be clearer if the definitions were
restricted to simply definitions and did not contain implicit constraints on
conforming processors and code. I think the clause in the definition of
"Extension" pertaining to ambiguity and contradiction should be moved into
item # 5 of the requirements for a conforming processor. Similarly, the
sentence requiring that portable code be written using STANDARD-CHAR-P
characters seems to me to be out of place. Wouldn't it be more appropriate
to put this sentence in the description of STANDARD-CHAR-P?
Tim
∂29-May-89 1324 X3J13-mailer two things
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 29 May 89 13:24:04 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa10179; 29 May 89 21:09 BST
Date: Mon, 29 May 89 21:14:26 BST
Message-Id: <11215.8905292014@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: two things
To: x3j13@sail.stanford.edu
Cc: chapman <@decwrl.dec.com:chapman@aitg.dec>
Um, when and where is the next meeting. I've completely lost
track of it.
The other thing:
Since we have now appointed some people to help bash the standard
into shape, I'm not sure how much value comments about the current
version have. Nonetheless, I find that I don't much like the use
of only alphabetical order to order the descriptions of all of
the builtin functions. I would much rather have them grouped
by topic (numeric, i/o, clos, etc.) and leave alphabetical order
for the index.
∂30-May-89 0821 X3J13-mailer two things
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 30 May 89 08:21:19 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 30 May 89 11:18:47 EDT
Date: Tue, 30 May 89 11:18 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: two things
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Cc: x3j13@sail.stanford.edu, chapman <@decwrl.dec.com:chapman@aitg.dec>
In-Reply-To: <11215.8905292014@subnode.aiai.ed.ac.uk>
Message-Id: <19890530151819.4.BARMAR@OCCAM.THINK.COM>
Date: Mon, 29 May 89 21:14:26 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Um, when and where is the next meeting. I've completely lost
track of it.
June 26-28 in Palo Alto (the Hyatt Rickey's, as usual).
The other thing:
Since we have now appointed some people to help bash the standard
into shape, I'm not sure how much value comments about the current
version have. Nonetheless, I find that I don't much like the use
of only alphabetical order to order the descriptions of all of
the builtin functions. I would much rather have them grouped
by topic (numeric, i/o, clos, etc.) and leave alphabetical order
for the index.
The Editorial subcommittee debated this for hours. The main
justification for using alphabetical order is that many functions fit
into several topics. The descriptive chapters of the standard will be
organized topically, and there will be tables of relevant functions
there.
It was suggested that if we couldn't come up with our own topical
grouping, we could simply use CLtL's. I'd like to point out that it's
somewhat flawed in this respect; for instance, it lists GETF and friends
in the Symbols chapter, and has SYMBOL-PACKAGE and KEYWORDP in the
section on Creating Symbols (as of the last draft I saw, these errors
were also in the tables in the dANS, and Kathy rejected my corrections
because she was just copying the groupings from CLtL).
barmar
∂30-May-89 0913 X3J13-mailer CONFORMANCE-POSITION
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 30 May 89 09:13:32 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 30 May 89 12:12:05 EDT
Date: Tue, 30 May 89 12:11 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: CONFORMANCE-POSITION
To: Jon L White <jonl@lucid.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <8905261756.AA17543@bhopal>
Message-Id: <19890530161143.1.BARMAR@OCCAM.THINK.COM>
Date: Fri, 26 May 89 10:56:56 PDT
From: Jon L White <jonl@lucid.com>
re: I believe we've already approved an issue that disallows
implementations to add symbols to the LISP and USER packages, so this
insulation is guaranteed.
Uh, which proposal is it that forbids the user from using the USER package?
Well, I said "implementations", not "the user". However, I just
reviewed PACKAGE-CLUTTER and I see that I had the sense backward, and
implementations ARE allowed to add symbols to USER.
barmar
∂31-May-89 0703 X3J13-mailer the standard and FTP
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 31 May 89 07:03:11 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA21514; Wed, 31 May 89 07:04:35 PDT
Message-Id: <8905311404.AA21514@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA21514; Wed, 31 May 89 07:04:35 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 31 May 89 09:59
To: x3j13@sail.stanford.edu
Subject: the standard and FTP
It is likely that FTP access to the standard will be going away temporarily
while we switch to a new gateway. This could happen as soon as tomorrow (6/1).
The lastest version of the standard is on hudson.dec.com (ftp_user
merrychristmas) now, if you'd like to access it before the downtime.
I will still be able to electronically mail files that you request, and
will of course be able to send you hardcopies and magnetic media.
Thanks for your patience.
∂31-May-89 1530 X3J13-mailer June meeting registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 May 89 15:30:29 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA09597g; Wed, 31 May 89 15:29:12 PDT
Received: by challenger id AA11214g; Wed, 31 May 89 15:28:26 PDT
Date: Wed, 31 May 89 15:28:26 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8905312228.AA11214@challenger>
To: x3j13@sail.stanford.edu
Subject: June meeting registration form
PLEASE DO NOT mail checks to me. I have moved to Florida and it is easier for
me to collect checks at the meeting. For those of you who need to reach me by
phone, I'm now at: 904/926-8039.
SUBCOMMITTEE MEETINGS:
DATE: 6/25
PLACE: TBA IF NECESSARY
COMMITTEE MEETING:
DATES: 6/26 - 6/28
TIME: 9:00 - 5:00
CITY: Palo Alto
PLACE: Rickey's Hyatt
ROOM: Executive Conference Room
ADDRESS: 4219 El Camino Real, Palo Alto, CA 94306
REGISTRATION FEE: $80 Payable to: LUCID, Inc.
HOTEL ACCOMODATIONS:
HOTEL: Rickey's Hyatt
ADDRESS: 4219 El Camino Real, Palo Alto, CA 94306
PHONE: 800/228-9000 or 415/493-8000
RATE: $110/night
MENTION: "X3J13" for rate
DIRECTIONS from airport:
From SFO: Take 101 south to San Antonio Road (about 25 minutes in non-rush
hour traffic). Take San Antonio Road exit marked Los Altos, heading toward the
hills. Turn right on El Camino Real. The hotel is on the right at 4219 El
Camino Real.
From San Jose: Take 101 north to San Antonio Road (about
15 minutes in non-rushhour traffic). Take San Antonio Road exit marked Los
Altos, heading toward the hills. Turn right on El Camino Real. The hotel
is on the right at 4219 El Camino Real.
For further information contact:
Jan Zubkoff
Lucid, Inc.
Route 5
Box 2834
Crawfordville, FL 32327
jlz@lucid.com
904/926-8039
!
X3J13 June 1989 Meeting Registration Form
Please bring a check for $80.00 payable to Lucid to the meeting.
Name: _____________________________________________________________
Institution: ______________________________________________________
Lunch 6/26: _________ yes _______ no
Lunch 6/27: _________ yes _______ no
Lunch 6/28: _________ yes _______ no
If Subcommitte Room is Needed:
Subcommittee Name? ___________________________
How many people will attend? __________
Meeting time? __________
Length of meeting? __________
∂31-May-89 1533 X3J13-mailer agenda items please
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 May 89 15:33:52 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA09624g; Wed, 31 May 89 15:32:41 PDT
Received: by challenger id AA11219g; Wed, 31 May 89 15:31:50 PDT
Date: Wed, 31 May 89 15:31:50 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8905312231.AA11219@challenger>
To: x3j13@sail.stanford.edu
Subject: agenda items please
If you would like to add something to the agenda, please send me mail with
what it is, the preferred day and how much time you will need.
Please remember the 2 week rule. If you have anything that needs to be voted
on, you'll need to mail it out next week in order to reach folks in time.
---jan---
∂01-Jun-89 1214 X3J13-mailer re: two things
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 1 Jun 89 12:13:52 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa15993; 1 Jun 89 19:54 BST
Date: Thu, 1 Jun 89 20:13:57 BST
Message-Id: <29999.8906011913@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: re: two things
To: chapman <@decwrl.dec.com:chapman@aitg.dec>, barmar@think.com
In-Reply-To: chapman's message of 30 May 89 11:24
Cc: x3j13@sail.stanford.edu
> If you have any comments at all on the standard, please send them on to
> me. They are meaningful at any time.
OK.
> As Barmar said, the groupings topic was one of those things we could
> have spent weeks or months debating and would still not have a more
> technically correct and consistent standard for all that work. I think
> the big thing we decided was to put the grouping discussion on hold until
> we felt the rest of the standard was in good enough shape so we had time
> to spend on other things.
I don't think that decision was wrong. Nonetheless, I do think the
grouping is important. In a document of that length, the reader needs
some help with conceptual organization so as not to be overwhelmed.
-- Jeff
∂02-Jun-89 1725 X3J13-mailer New submission address for LASC
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Jun 89 17:25:43 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA01255g; Fri, 2 Jun 89 16:28:47 PDT
Received: by challenger id AA01058g; Fri, 2 Jun 89 16:26:32 PDT
Date: Fri, 2 Jun 89 16:26:32 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906022326.AA01058@challenger>
To: common-lisp@sail.stanford.edu, x3j13@sail.stanford.edu
Subject: New submission address for LASC
LISP AND SYMBOLIC COMPUTATION Journal questions and submissions should be
sent to the following new address:
Jan Zubkoff
Associate Editor, LASC
Lucid, Inc.
Route 5, Box 2834
Crawfordville, FL 32327
904/926-8039
Please send 5 copies of your paper for review. The final copy should be
submitted in electronic LaTex form, either by netmail or on a 1.2M floppy.
Volume 2 Issue 2 has just been mailed and Issue 3/4 will be another double
issue due to be mailed in about a month.
There have been some changes I thought you'd like to know about.
Guy L. Steele Jr. has taken a one year sabatical to devote his time to other
pressing activities. Carolyn Talcott has graciously stepped in as Acting
Editor-in-Chief and has made short work of every paper.
Mark Wegman and L. Peter Deutsch have both resigned to devote their time to
research.
Bob Kessler and JonL White have joined our Editorial Board and have given a
great deal of their time reviewing papers.
I'd like to thank each member of our Editorial Board for making this journal
possible.
Richard P. Gabriel Carolyn Talcott
Daniel G. Bobrow Kenneth Kahn
Robert S. Cartwright Robert Kessler
Jerome Chailloux John McCarthy
Daniel P. Friedman Larry Masinter
Martin L. Griss Julian Padget
Paul Hudak David S. Touretzky
Masayuki Ida Mitchell Wand
Gilles Kahn John L. White
Thank you to all the authors who have submitted their work to LASC and have
made this an exceptional joural.
---jan---
∂12-Jun-89 0424 X3J13-mailer Issue: CONFORMANCE-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Jun 89 04:24:36 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02395; Mon, 12 Jun 89 04:25:53 PDT
Message-Id: <8906121125.AA02395@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02395; Mon, 12 Jun 89 04:25:53 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Jun 89 07:23
To: x3j13@sail.stanford.edu
Subject: Issue: CONFORMANCE-POSITION
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
6-FEB-89, Version 5 by Chapman
20-FEB-89, Version 6 by Chapman
5-MAY-89, Version 7 by Chapman
22-MAY-89, Version 8 by Chapman (including Moon comments)
12-JUN-89, Version 9 by Chapman (including comments)
Problem Description:
Two ways of defining conformance are in terms of conforming code
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-CODE)
The standard presents the syntax and semantics to be implemented by
a conforming implementation. In addition, it levies requirements on
conforming code and documentation.
Definitions:
Code: A representation of one or more Common Lisp forms
that includes both source forms meant to be evaluated or compiled,
and compiled forms.
Extension: A facility in the implemented language that is not given in this
standard.
Implementation-defined: Possibly differing between processors, but defined
for any particular processor.
Implementation-dependent: Possibly differing between processors and not
necessarily defined for any particular processor.
Portable code: Required to produce equivalent results and
observable side effects in all conforming implementations.
Portable code is written using only STANDARD-CHAR-P characters.
Processor: A system or mechanism that accepts code as input, prepares
it for execution, and executes the process so prepared to produce
results (sometimes not observable).
Conformance:
A processor conforming with the requirements of this standard shall:
1. accept all the features of the language specified in this standard,
with the meanings defined in this standard.
2. not require the inclusion of substitute or additional language elements in
code in order to accomplish a feature of the language that is specified
in this standard.
3. be accompanied by a document that provides a definition of all
implementation-defined features that are related to standard-defined
operators. In addition, the documentation should contain names of all
the packages defined by an implementation.
4. treat exceptional situations in the manner specified in section 1.4 of
the standard (i.e. the Definitions section. It contains the error terminology.).
5. be accompanied by a document that separately describes any features accepted
by the processor that are prohibited or not specified in this standard,
but that do not cause any ambiguity or contradiction when added
to the language standard.
Such extensions shall be described as being ``extensions to Common Lisp
as specified by ANSI ...''.
6. produce a conformance statement as a consequence of using the processor,
or that statement shall be included in the accompanying documentation.
If the processor conforms in all respects with this standard, the conformance
statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>''
If the processor conforms with some but not all of the requirements of this
standard, then the conformance statement shall be
``<This processor> conforms with the requirements of ANSI <standard number>
with the following exceptions:
<followed by a reference to, or a complete list of, the requirements of
the standard with which the processor does not conform>.
Code conforming with the requirements of this standard shall:
1. use only those features of the language specified in this standard.
2. not rely on any particular interpretation of implementation-dependent
features.
Note that conforming code may rely on particular implementation-defined values
or features. Also note that the requirements for conforming code and
conforming processors do not require that the results produced by conforming
code are always the same when processed by a conforming processor. They may
be, or they may differ, pending on the code.
Informally, the basic rules for conformance are as follows:
1. Conforming code is defined in terms of its structure,
and not in terms of its results and side effects.
2. Conforming code is written using only the syntax specified in the standard.
3. Conforming code is written in only the sequence specified in the standard.
4. Conforming code is written using only the functions, macros,
special forms, variables, and constants specified in the standard.
5. Conforming implementations provide the functionality and behavior
specified in the standard.
The definitions of all names and syntax that aren't specified in the
standard and aren't provided by the implementation must accompany the code.
6. Conformance is not machine-checkable.
It's possible for a conforming code to
run in all conforming implementations, but to have allowable
implementation-defined behavior that could make it non-portable.
Insofar as we allow options in the standard this will be true.
Rationale:
The standard must contain information about conformance.
Current Practice:
CLtL generally describes things in terms of what correct code can
expect, but the document itself levies the requirement on an implementation
to support all the described functionality.
dpANS C also defined conformance in terms of code.
It has further defined both "conforming" and "strictly conforming" code.
Pascal defines conformance in terms of both, PL/I defines conformance in
terms of conforming code only.
Fortran and Ada say that a conforming implementation correctly processes
conforming code. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both code and implementations.
Adoption Cost:
The use of the words "implementation-defined" and "implementation-dependent"
in CLtL and the standard will have to be checked to make sure the uses
and the definitions given above coincide. Any changes that occur as a
result of this check could potentially affect some user code, but it's
unlikely.
Implementations will have to be checked to make sure they conform with the
rules stated above, and conformance statements will have to be added.
Documentation may have to be updated.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
The information in this issue was derived from three documents:
the C ANSI standard, the "Proposed Draft Techinical Report-Guidelines on the
preparation of conformity clauses in porogramming languages and Letter Ballot"
(CT22/87-094, ISO/TC97/SC22/WG12 N133 Rev 1, October, 1987), and
"Specification for Computer programming language Pascal" (BS 6192:1982,
UDC 681.3.06 Pascal: 519.682).
∂12-Jun-89 0452 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Jun 89 04:52:38 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03319; Mon, 12 Jun 89 04:53:56 PDT
Message-Id: <8906121153.AA03319@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA03319; Mon, 12 Jun 89 04:53:56 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Jun 89 07:52
To: x3j13@sail.stanford.edu
Subject: Issue: EXTRA-RETURN-VALUES
Issue: EXTRA-RETURN-VALUES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
10-MAR-89, Version 3 by Chapman
30-MAY-89, Version 4 by Pierson
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
A function that is specified by the standard must return EXACTLY the number
of return values specified by the standard.
The following functions are explicited permitted to have additional
return values:
apropos
arithmetic-error-operands
arithmetic-error-operation
break
cell-error-name
cerror
clear-input
clear-output
compile
compile-file
compute-restarts
continue
delete-file
describe
directory-namestring
disassemble
dribble
ed
error
find-restart
finish-output
force-output
fresh-line
inspect
invoke-debugger
invoke-restart
invoke-restart-interactively
load
make-condition
muffle-warning
package-error-package
pprint
prin1
princ
print
restart-name
room
set-dispatch-macro-character
set-macro-character
set-syntax-from-char
signal
simple-condition-format-arguments
simple-condition-format-string
sleep
store-value
terpri
type-error-datum
type-error-expected-type
unread-char
use-value
user-homedir-pathname
warn
write
write-byte
write-char
write-line
Rationale:
The reason is that additional arguments are visible to otherwise
portable programs. For instance, (multiple-value-call #'cons (floor x
y)) looks portable, but it will try to pass the wrong number of
arguments to CONS if FLOOR returns an extra value.
Current Practice:
At least one implementation returns extra values for certain functions
not currently specified to return those values.
Adoption Cost:
Implementations and their associated documentation that now contain
functions that return extra values will have to change.
Benefits:
Programs will potentially become more portable.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂12-Jun-89 0755 X3J13-mailer Agenda item: Series and Generators
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 12 Jun 89 07:55:07 PDT
Received: from fafnir.think.com by Think.COM; Mon, 12 Jun 89 10:54:45 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 12 Jun 89 10:53:35 EDT
Received: from joplin.think.com by verdi.think.com; Mon, 12 Jun 89 10:53:33 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Mon, 12 Jun 89 10:53:30 EDT
Date: Mon, 12 Jun 89 10:53:30 EDT
Message-Id: <8906121453.AA03232@joplin.think.com>
To: x3j13@sail.stanford.edu
Subject: Agenda item: Series and Generators
If I am not mistaken, the series and generators stuff has not been
voted upon by the full X3J13 committee; rather, LOOP was reported
out of subcommittee and eventually accepted, but the subcommittee deemed
the other proposals not ready and did not recommend a proposal to
be voted upon. I think they did the right thing at the time.
Since the disbanding of the subcommittee, Waters and Perdue have produced
reasonably complete proposals for series and generators. While they have
not been distributed as X3J13 documents, every X3J13 member should have a
copy as a result of the mailing-out of my draft of CLTL II.
I would like to see these proposals voted upon by the full committee (if
only for the record, should they be defeated after all). I have requested
a *brief* slot on the agenda for this purpose. My intent is not to reopen
a lengthy debate about series, but only to assess whether there is
consensus, either yea or nay, on these specific proposals. I therefore
intend to offer a motion that these specific proposals be adopted at this
time as part of the current draft Common Lisp standard. Dick Waters may be
there to offer an explanation of what is there, but it's very similar to
what we have seen before and paper copies have been distributed, so I would
much prefer not to consume precious meeting time; please read ahead of time.
If there is too much controversy I will simply withdraw the motion (or take
some similar appropriate action). But it may be that the new proposals
have crystallized the ideas and we are ready to accept it, or it may be
that we just don't want it, at least this time around. I want to find out.
This really shouldn't take more than ten minutes or so.
--Guy
∂13-Jun-89 1559 X3J13-mailer Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 15:58:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610869; 13 Jun 89 19:00:44 EDT
Date: Tue, 13 Jun 89 19:01 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: Moon@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)
To: X3J13@sail.stanford.edu
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, IIM@ECLA.USC.EDU
Message-ID: <19890613230107.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Kim sent us version 8 on floppy disk with a request to redistribute to the
network. I've made a couple of small corrections. The status of this issue
is still labelled as draft, but it is probably really ready for voting.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
CLtL Chapter 9: Declarations,
Issue COMPILE-FILE-ENVIRONMENT,
Issue DEFINING-MACROS-NON-TOP-LEVEL,
Issue DESTRUCTURING-BIND,
Issue EVAL-WHEN-NON-TOP-LEVEL,
Issue GET-SETF-METHOD-ENVIRONMENT,
Issue FUNCTION-NAME,
Issue FUNCTION-TYPE,
Issue MACRO-ENVIRONMENT-EXTENT,
Issue MACRO-FUNCTION-ENVIRONMENT,
Issue PROCLAIM-LEXICAL
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Version 7, 7-Apr-89, Moon & Barrett (more revisions)
Version 8, 9-Jun-89, Kim A. Barrett (add DEFDECLARE)
Version 9, 13-Jun-9, Moon (small corrections)
Status: **DRAFT**
Problem description:
When macro forms are expanded, the expansion function is called with two
arguments: the form to be expanded, and the environment in which the form was
found. The environment argument is of limited utility. The only use
sanctioned currently is as an argument to MACROEXPAND or MACROEXPAND-1 or
passed directly as an argument to another macro expansion function. Recently
passed cleanup issues allow it as an argument to MACRO-FUNCTION and to
GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle local
macro and function definitions, due to insufficient access to the information
contained in environments and the inability to augment environments with local
definitions.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic environment
objects. In all of these functions the argument named ENV is an environment
of the sort received by the &ENVIRONMENT argument to a macro or as the
environment argument for EVALHOOK. (It is not required that implementations
provide a distinguished representation for such objects.) Optional "env"
arguments default to NIL, which represents the local null lexical environment
(containing only global definitions and proclamations that are present in the
runtime environment). All of these functions should signal an error of type
TYPE-ERROR if the value of an environment argument is not a syntactic
environment.
The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION-INFORMATION retrieve information about declarations that are in
effect in the environment. Since implementations are permitted to ignore
declarations (except for SPECIAL declarations and OPTIMIZE SAFETY
declarations if they ever compile unsafe code), these accessors are required
only to return information about declarations that were explicitly added to
the environment using AUGMENT-ENVIRONMENT. They might also return
information about declarations recognized and added to the environment by the
interpreter or the compiler, but that is optional at the discretion of the
implementer. Implementations are also permitted to canonicalize
declarations, so the information returned by the accessors might not be
identical to the information that was passed to AUGMENT-ENVIRONMENT.
VARIABLE-INFORMATION variable &optional env [Function]
This function returns information about the interpretation of the symbol
VARIABLE when it appears as a variable within the lexical environment ENV.
The following three values are returned.
The first value indicates the type of definition or binding which is apparent
in ENV:
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result will also
refer to variables proclaimed lexical.]
The second value indicates whether there is a local binding of the name. If
the name is locally bound, the second value is true. Otherwise, NIL is
returned.
The third value is a property list containing information about declarations
that apply to the apparent binding of the variable. The keys in the property
list are symbols which name declaration-specifiers, and the format of the
corresponding values depends on the particular declaration-specifier
involved. The standard declaration-specifiers that might appear as keys in
this property list are:
DYNAMIC-EXTENT a non-NIL value indicates that the variable has been
declared DYNAMIC-EXTENT. If the value is NIL, the property
might be omitted.
IGNORE a non-NIL value indicates that the variable has been declared
IGNORE. If the value is NIL, the property might be omitted.
TYPE a type specifier associated with the variable by a TYPE
declaration or an abbreviated declaration such as (FIXNUM VAR).
If no explicit association exists, either by PROCLAIM or
DECLARE, then the type specifier is T. It is permissible for
implementations to use a type specifier that is equivalent
to or a supertype of the one appearing in the original
declaration. If the value is T, the property might be
omitted.
If an implementation supports additional declaration-specifiers that apply to
variable bindings, those declaration-specifiers might also appear in the
property list. The property list might contain multiple entries for a given
property. The consequences of destructively modifying the list structure of
this property list or its elements are undefined.
Programmers are reminded that the global binding might differ from the local
one, and can be retrieved by calling VARIABLE-INFORMATION again with a null
lexical environment.
FUNCTION-INFORMATION function &optional env [Function]
This function returns information about the interpretation of the function
name FUNCTION when it in a functional position within lexical environment
ENV. The following three values are returned.
The first value indicates the type of definition or binding of the function
name which is apparent in ENV:
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
Some function names can refer to both a global macro and a global special
form. In such a case, the macro takes precedence, and :MACRO is returned as
the first value.
The second value specifies whether the definition is local or global. If
local, the second value is true, and it is false when the definition is
global.
The third value is a property list containing information about declarations
that apply to the apparent binding of the function. The keys in the property
list are symbols which name declaration-specifiers, and the format of the
corresponding values depends on the particular declaration-specifier
involved. The standard declaration-specifiers that might appear as keys in
this property list are:
INLINE one of the symbols INLINE, NOTINLINE, or NIL to indicate
whether the function name has been declared INLINE, has been
declared NOTINLINE, or neither. If the value is NIL, the
property might be omitted.
FTYPE the type specifier associated with the function name in the
environment, or the symbol FUNCTION if there is no functional
type declaration or proclamation associated with the function
name. This value might not include all the apparent FTYPE
declarations for the function name. It is permissible for
implementations to use a type specifier that is equivalent
to or a supertype of the one that appeared in the original
declaration. If the value is FUNCTION, the property might be
omitted.
If an implementation supports additional declaration-specifiers that apply to
function bindings, those declaration-specifiers might also appear in the
property list. The property list might contain multiple entries for a given
property. In this case the value associated with the first entry has
precedence. The consequences of destructively modifying the list structure
of this property list or its elements are undefined.
[If issue DYNAMIC-EXTENT-FUNCTION passes, the property DYNAMIC-EXTENT will
be added to the above table.]
Programmers are reminded that the global binding might differ from the local
one, and can be retrieved by calling FUNCTION-INFORMATION again with a null
lexical environment.
DECLARATION-INFORMATION decl-name &optional env [Function]
This function returns a list of declaration-specifiers whose CAR is the
symbol DECL-NAME that are in force in the environment ENV, sorted so that the
most recent declaration is first on the list. Only declarations that do not
apply to function or variable bindings (i.e., those that are "pervasive") can
be accessed with this function.
It is required that this function recognize OPTIMIZE and DECLARATION as
DECL-NAMEs. The values returned for these two cases are as follows:
OPTIMIZE a list whose entries are of the form (quality value), where
"quality" is one of the optimization qualities defined by the
standard (SPEED, SAFETY, COMPILATION-SPEED, SPACE, and DEBUG)
or some implementation-specific optimization quality, and
"value" is an integer in the range 0 to 3. The returned list
always contains an entry for each of the standard qualities and
for each of the implementation-specific qualities. In the
absence of any previous declarations, the associated values are
implementation-dependent. The list might contain multiple
entries for a quality, in which case the first such entry
specifies the current value.
DECLARATION a list of the declaration names which have been proclaimed as
valid through the use of the DECLARATION proclamation.
If an implementation has been extended to recognize additional
pervasive declaration specifiers in DECLARE or PROCLAIM, it is required that
either the DECLARATION-INFORMATION function should also recognize those
declarations, or that the implementation provide an accessor that is
specialized for that declaration specifier.
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a new environment containing the information present in
ENV, augmented with the information provided by the keyword arguments. It is
intended to be used by program analyzers that perform a code walk.
The arguments are supplied as follows:
:VARIABLE A list of symbols which shall be visible as bound variables in
the new environment. Whether each binding is to be interpreted
as special or lexical depends on SPECIAL declarations recorded
in the environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, specified as a list of
(name definition) lists (that is, in the same format as the
CADR of a SYMBOL-MACROLET special form). The new environment
will have local symbol-macro bindings of each symbol to the
corresponding expansion, so that MACROEXPAND will be able to
expand them properly. A type declaration in the :DECLARE
argument which refers to a name in this list implicitly
modifies the definition associated with the name. The effect
is to wrap a THE form mentioning the type around the
definition.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, specified as a list of (name
definition) lists. Each definition must be a function of two
arguments (a form and an environment). The new environment
will have local macro bindings of each name to the
corresponding expander function, which will be returned by
MACRO-FUNCTION and used by MACROEXPAND.
:DECLARE A list of decl-specs. Information about these declarations can
be retrieved from the resulting environment using the
VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION-INFORMATION accessors.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list. An error is
signaled if any of the symbols naming macros in the :SYMBOL-MACRO alist are
also included in a SPECIAL decl-spec in the :DECLARE argument. An error is
signalled if any of the names of macros in the :MACRO alist are also included
in the :FUNCTION list. The consequences of destructively modifying the list
structure of any of the arguments to this function are undefined.
The condition type of each of these errors is PROGRAM-ERROR.
The extent of the returned environment is the same as the extent of the
argument environment. The result might share structure with the argument
environment, but the argument environment is not modified.
While an environment argument from EVALHOOK is permitted to be used as the
environment argument for this function, the reverse is not true. If an
attempt is made to use the result of AUGMENT-ENVIRONMENT as the environment
argument for EVALHOOK, the consequences are undefined. The environment
returned by AUGMENT-ENVIRONMENT can only be used for syntactic analysis, ie.
the functions specified by this proposal and functions such as MACROEXPAND.
DEFDECLARE decl-name lambda-list &body body [Macro]
Define a handler for the named declaration. This is the mechanism by which
AUGMENT-ENVIRONMENT is extended to support additional declaration
specifiers. The function defined by this macro will be called with two
arguments, a decl-spec whose CAR is decl-name, and the ENV argument to
AUGMENT-ENVIRONMENT. Two values must be returned by the function. The
first value must be one of the following keywords:
:VARIABLE the declaration applies to variable bindings.
:FUNCTION the declaration applies to function bindings.
:DECLARE the declaration is pervasive, rather than applying to bindings.
For the case where the first value indicates the declaration applies to
bindings, the second value is a list, the elements of which are lists of the
form (binding-name property value). If the corresponding information
function (either VARIABLE-INFORMATION or FUNCTION-INFORMATION) is applied to
the binding name and the augmented environment, the property list which is
the third value returned by the information function will contain the value
under the specified property.
When the first value is :DECLARE, the second value is a cons whose CAR is a
property and whose CDR is the associated value. The function
DECLARATION-INFORMATION, when applied to the property and the augmented
environment, will return the associated value.
PARSE-MACRO name lambda-list body &optional env [Function]
This function is used to process a macro definition in the same way
as DEFMACRO and MACROLET. It returns a lambda-expression that accepts
two arguments (a form and an environment). The "name", "lambda-list",
and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
definition.
The "lambda-list" argument can include &ENVIRONMENT and &WHOLE. The "name"
argument is used to enclose the "body" in an implicit BLOCK, and might also
be used for implementation-dependent purposes (such as including the name of
the macro in error messages if the form does not match the lambda-list).
ENCLOSE lambda-expression &optional env [Function]
This function returns an object of type FUNCTION that is equivalent to what
would be obtained by evaluating `(FUNCTION ,LAMBDA-EXPRESSION) in syntactic
environment ENV. The consequences are undefined if any of the local
variable or function bindings (but not macro definitions) that are visible
in the lexical environment represented by ENV are referenced within the
LAMBDA-EXPRESSION.
Rationale:
This proposal defines a minimal set of accessors (VARIABLE-INFORMATION,
FUNCTION-INFORMATION, and DECLARATION-INFORMATION) and a constructor
(AUGMENT-ENVIRONMENT) for environments.
All of the standard declaration specifiers, with the exception of SPECIAL,
can be defined fairly easily using DEFDECLARE. It also seems to be able
to handle most extended declarations.
The PARSE-MACRO function is provided so that users don't have to write their
own code to destructure macro arguments. With the addition of
DESTRUCTURING-BIND to the language, this function is not entirely necessary.
However, it is probably worth including anyway, since any program-analyzing
program is going to need to define it, and the definition isn't completely
trivial.
ENCLOSE is needed to allow expander functions to be defined in a non-NULL
lexical environment, as required by DEFINING-MACROS-NON-TOP-LEVEL:ALLOW. It
also provides a mechanism by which the forms in an (EVAL-WHEN (COMPILE) ...)
can be executed in the enclosing environment (see Issue
EVAL-WHEN-NON-TOP-LEVEL).
Making declarations from an &ENVIRONMENT or EVALHOOK environment optional
continues to allow implementations the freedom simply to ignore all such
declarations in the compiler or interpreter.
Examples:
#1: This example illustrates the first two values returned by the function
VARIABLE-INFORMATION.
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (KIND BINDINGP)
(VARIABLE-INFORMATION VAR ENV)
`(LIST ',VAR ',KIND ',BINDINGP)))
(DEFVAR A)
(DEFCONSTANT B 43)
(DEFUN TEST ()
(LET (C)
(LET (D)
(DECLARE (SPECIAL D))
(SYMBOL-MACROLET ((E ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E)
(KIND-OF-VARIABLE F))))))
(TEST) -> ((A :SPECIAL NIL)
(B :CONSTANT NIL)
(C :LEXICAL T)
(D :SPECIAL T)
(E :SYMBOL-MACROLET T)
(F NIL NIL))
#2: This example illustrates the first two values returned by the function
FUNCTION-INFORMATION.
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (KIND BINDINGP)
(FUNCTION-INFORMATION FUNCTION-NAME ENV)
`(LIST ',FUNCTION-NAME ',KIND ',BINDING)))
(DEFUN A ())
(DEFUN (SETF A) (V))
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(LIST (KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION (SETF A))
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> ((A :FUNCTION NIL)
(B :MACRO NIL)
(QUOTE :SPECIAL-FORM NIL)
((SETF A) :FUNCTION NIL)
(C :FUNCTION T)
(D :MACRO T)
(E NIL NIL))
#3: This example shows how a code-walker might walk a MACROLET special form.
It assumes that the revised MACROLET semantics described in proposal
DEFINING-MACROS-NON-TOP-LEVEL:ALLOW are in effect.
(DEFUN WALK-MACROLET (FORM ENV)
(LET ((MACROS (MAKE-MACRO-DEFINITIONS (CADR FORM) ENV)))
(MULTIPLE-VALUE-BIND (BODY DECLS) (PARSE-BODY (CDDR FORM))
(WALK-IMPLICIT-PROGN
BODY
(AUGMENT-ENVIRONMENT ENV :MACRO MACROS :DECLARE DECLS)))))
(DEFUN MAKE-MACRO-DEFINITIONS (DEFS ENV)
(MAPCAR #'(LAMBDA (DEF)
(LET ((NAME (CAR DEF)))
(LIST NAME
(ENCLOSE (PARSE-MACRO NAME (CADR DEF) (CDDR DEF) ENV)
ENV))))
DEFS))
Cost to Implementors:
Most implementations already record some of this information in some form.
Providing these functions should not be too difficult, but it is a more than
trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable Common
Loops defines a subset of this functionality for its code walker and
implements it on a number of diffent versions of Common Lisp.
Discussion:
The first version of this proposal expressly did not deal with the objects
which are used as environments by EVALHOOK. This version is extended to
support them in the belief that such environments share a lot of functionality
with the syntactic environments needed by a compiler. While the two types of
environments might have very different implementations, there are many
operations which are reasonable to perform on either type, including all of
the accessor functions described by this proposal.
There has been discussion about a macro called WITH-AUGMENTED-ENVIRONMENT,
either in addition to or instead of AUGMENT-ENVIRONMENT. The point of this
would be to say that the extent of the augmented environment is the dynamic
extent of the WITH-AUGMENTED-ENVIRONMENT form. There was some concern that
there might be cases where the macro was awkward to use. Such a macro is not
included in this proposal. If AUGMENT-ENVIRONMENT is provided, then such a
macro is trivially written in terms of the function. There are places in the
processing of sequential binding forms where using such a macro might be more
difficult than using the specified function.
Some people have indicated they think that the :MACRO argument (and the
:SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an a-list of the
form ((name . definition)...) rather than the form ((name definition)...).
Some people have indicated they think that implementations must never discard
any declarations, even if they are not otherwise used by the interpreter or
compiler. Proposal SMALL is consistent with what CLtL says (implementations
are free to ignore all declarations except SPECIAL declarations), but the
DECLARATION-INFORMATION function might not be particularly useful unless it is
guaranteed to do something. Requiring implementations to keep track of
declarations they'd otherwise ignore would involve some implementation cost
and also might incur a performance penalty.
ENCLOSE happens to subsume the extension to COERCE for converting a lambda
expression into a function (see Issue FUNCTION-TYPE, passed in June 1988).
Perhaps the extension to COERCE should be backed out?
∂13-Jun-89 1615 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89 16:14:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610877; 13 Jun 89 19:16:42 EDT
Date: Tue, 13 Jun 89 19:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: X3J13@sail.stanford.edu
Message-ID: <19890613231714.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Version 5 of this proposal passed with amendments at the January
1989 X3J13 meeting. However, the amendments were found to result
in an inconsistent proposal, and it was also pointed out that some
related problems with simple-arrays were not addressed. Since then
there has been a great deal of private discussion, and review of
various versions of the proposal including ones earlier than 5.
The result is this proposal, which is believed to be acceptable to
everyone and is being offered for a vote in June to replace the
January version that was already voted in.
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289),
simple strings with fill pointers (p299)
Category: CLARIFICATION and CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
6-Jun-89, Version 10, by Moon and Gabriel, do over.
Problem Description:
There are a number of unclear passages in CLtL related to simple arrays
and adjustable arrays. There is disagreement on precisely how these
passages are to be interpreted, and no one is happy with the fact that
ADJUST-ARRAY works only on an implementation-dependent subset of arrays.
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288 says that
``the argument, if specified and not NIL, indicates that it must be
possible to alter the array's size dynamically after it is created. This
argument defaults to NIL.'' The description of the :ADJUSTABLE option
does not say what MAKE-ARRAY will do if the argument is unsupplied or
explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is true ``if
the argument (which must be an array) is adjustable, and otherwise
false.'' However, the description of MAKE-ARRAY makes it clear that this
is not necessarily the same as asking if the array was created with
:ADJUSTABLE T. If ADJUSTABLE-ARRAY-P returns NIL, you know that
:ADJUSTABLE NIL was supplied (or no :ADJUSTABLE option was supplied), but
if ADJUSTABLE-ARRAY-P returns T, then there is no information about
whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is ``not
permitted to call ADJUST-ARRAY on an array that was not created with the
:ADJUSTABLE option.'' This is inconsistent with ADJUSTABLE-ARRAY-P.
The definition of SIMPLE-ARRAY on p.28 says ``an array that is not
displaced to another array, has no fill pointer, and is not to have its
size adjusted dynamically after creation is called a simple array.''
It is left unclear whether this is an implication or an equivalence,
i.e. whether there can be other simple arrays as well.
CLtL p.299 appears to refer to simple strings with fill pointers,
suggesting that it is an implication, but similar language is used for
equivalences in other parts of CLtL.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY)
1. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
2. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
3. It is permitted to call ADJUST-ARRAY on any array. (Remove the
restriction documented at the bottom of p.297.)
4. If ADJUST-ARRAY is applied to an array created with :ADJUSTABLE true,
the array returned is EQ to its first argument. It is not specified
whether ADJUST-ARRAY returns an array EQ to its first argument for any
other arrays. If the array returned by ADJUST-ARRAY is not EQ to its
first argument, the consequences of any reference to the original array
are undefined.
5. The predicate ADJUSTABLE-ARRAY-P is true if and only if ADJUST-ARRAY
will return a value EQ to this array when given this array as its first
argument.
Clarifications and Logical Consequences:
a. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
b. There is no specified way to create an array that is non-simple.
c. The definition of SIMPLE-ARRAY on p.28 is taken to be an implication,
not an equivalence. This is either a clarification or a change depending
on one's prior reading of that definition.
d. The meaning of ADJUSTABLE-ARRAY-P is changed.
e. As with such functions as DELETE and NCONC, textbooks should
instruct programmers to be careful to receive the value returned by
ADJUST-ARRAY, as it might not be EQ to the first argument.
Rationale:
Points 3 and 4 eliminate the problem of ADJUST-ARRAY only working on a
subset of arrays, by changing it to work on all arrays. It remains
implementation-dependent whether the array is modified in place or
copied, i.e. whether the result is EQ to the argument, however many other
functions in Common Lisp have similar implementation-dependent behavior.
Implementation-dependent storage allocation or reuse is considered
more benign than implementation-dependent applicability of an operation.
Point 3 recognizes that ADJUST-ARRAY offers features that are offered by
no other function and which are useful in cases involving non-adjustable
arrays (for what amounts to copying). This change would allow an
expression such as:
(SETQ X (ADJUST-ARRAY X ...))
to work reliably. Those desiring the old behavior could do:
(IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
(NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
(ERROR "Array cannot be adjusted."))
to get the old style error checking.
Point 5 recycles the name ADJUSTABLE-ARRAY-P as a test for whether an
array is adjusted in place or by copying.
Point 2 preserves the raison d'etre of simple arrays, which is to provide
a portable interface to implementation-dependent specialized arrays that
trade decreased functionality for faster access. A proposed alternative
was to specify a way to create an array that is guaranteed not to be
simple. This would have made (typep (make-array ...) 'simple-array)
return the same value in all implementations, but would have required
large changes to some implementations and would be of little benefit to
users. Users need to know that certain arrays are simple, so they can
put in declarations and get higher performance, but users have no need to
be able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable.
Examples:
1. The following program is conforming.
(defun double (a)
(adjust-array a (* (length a) 2)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
3. The following program is non-conforming. The consequences of this
program are undefined because the type declaration is violated in some
implementations.
(let ((a (make-array 100 :adjustable t)))
(declare (simple-array a))
(frob a))
Current Practice:
Every correct CLtL implementation conforms to points 1 and 2. It is
unlikely that any implementation currently exists that conforms to points
3, 4, and 5. Points 3 and 4 involve additions to an implementation to
support the copying form of ADJUST-ARRAY. Point 5 may involve a change
to ADJUSTABLE-ARRAY-P or may be able to use the existing implementation
of the function.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is a SIMPLE-ARRAY.
The arrays that are internally simple in Symbolics Genera are a different
subset of arrays from the type SIMPLE-ARRAY, because simplicity in that
implementation depends on the rank and total-size as well as on the
fill-pointer and displacement, thus Genera does not use the type
SIMPLE-ARRAY for anything.
Lucid, IIM, Ibuki, and Symbolics Cloe make :ADJUSTABLE NIL arrays
non-adjustable in all cases, and make every array non-simple that CLTL
does not require to be simple.
Macintosh Allegro Common Lisp v1.2 makes :ADJUSTABLE NIL arrays
non-adjustable in all cases, makes all arrays of rank other than 1
non-simple (violating point 1), and makes every array non-simple that
CLTL does not require to be simple.
Cost to Implementors:
The change to ADJUSTABLE-ARRAY-P is easy. The change to ADJUST-ARRAY may
involve some complex coding but should not be a large task. No changes
are required to anything connected with SIMPLE-ARRAY.
Cost to Users:
None in code that does not call ADJUSTABLE-ARRAY-P. This is a fully
upward-compatible change from the user's standpoint.
Benefits:
Programs that use simple arrays and/or adjust arrays will be easier
to port, as the language specification for these features will be
clearer. More programs will be able to call ADJUST-ARRAY, as its use
will not be restricted to a subset of arrays.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired signal. A few programs might have
porting problems due to variation among implementations of whether the
result of ADJUST-ARRAY is EQ to the first argument.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language more clearly specified is an aesthetic improvement.
Allowing ADJUST-ARRAY on all arrays is an aesthetic improvement.
Discussion:
There are at least 110 messages of discussion preceding this version of the
proposal. It does not seem feasible to summarize them here.
Dick Gabriel, Dave Moon, and Guy Steele support this proposal.
∂15-Jun-89 0824 X3J13-mailer issue CLOS-MACRO-COMPILATION, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jun 89 08:24:39 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14829; Thu, 15 Jun 89 09:25:02 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA23848; Thu, 15 Jun 89 09:24:59 -0600
Date: Thu, 15 Jun 89 09:24:59 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906151524.AA23848@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue CLOS-MACRO-COMPILATION, version 4
Reply-To: cl-compiler@sail.stanford.edu
This version incorporates Gregor's amendment from the last meeting.
Forum: Compiler
Issue: CLOS-MACRO-COMPILATION
References: CLOS chapters 1 & 2 (88-002R)
CLOS chapter 3 (89-003)
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION
Edit History: V1, 10 Mar 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore
V3, 21 Mar 1989, Sandra Loosemore (fix error language)
V4, 11 Jun 1989, Sandra Loosemore (Gregor's amendment)
Status: Ready for release
Problem Description:
Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?
A part of the problem is that we do not currently have a full
understanding of all the issues involved. In particular, work on
defining the CLOS meta-object protocol is still in progress. The goal
of this proposal is to say enough about the behavior of these macros
in the standard so that users can use them portably in compiled code,
but to leave as much of the behavior as possible unspecified to avoid
placing undue restrictions on the meta-object protocol.
Proposal CLOS-MACRO-COMPILATION:MINIMAL:
State that top-level calls to the CLOS defining macros have the
following compile-time side-effects. Any other compile-time behavior
is explicitly left unspecified.
DEFCLASS:
* The class name may appear in subsequent type declarations.
* The class name can be used as a specializer in subsequent
DEFMETHOD forms.
DEFGENERIC:
* The generic function can be referenced in subsequent DEFMETHOD forms.
* The generic function is not callable at compile-time.
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function.
The error-signalling behavior described in the specification of
DEFMETHOD in CLOS chapter 2 (if the function isn't a generic function
or if the lambda-list is not congruent) happens only when the defining
form is executed, not at compile time.
The forms in EQL specializers are evaluated when the defining form
is executed. The implementation may try to evaluate them at
compile time, but must not depend on being able to do so.
DEFINE-METHOD-COMBINATION:
* The method combination can be used in subsequent DEFGENERIC forms.
The body of a DEFINE-METHOD-COMBINATION form is evaluated no earlier
than when the defining macro is executed and possibly as late as
generic function invocation time. The compiler may attempt to
evaluate these forms at compile time but must not depend on being able
to do so.
Rationale:
The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
DEFTYPE.
DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
function definition to the compile-time environment. Since generic
functions may be freely redefined between compile and run time (just
like any other function), a method may end up "belonging" to a
different generic function at load time than at compile time. This
is why it is inappropriate to signal errors about congruency problems
(etc) until the method is actually added to the generic function at
run time.
Current Practice:
The items listed under DEFCLASS in proposal MINIMAL are fairly standard
programming style.
Flavors does not support compile-time instantiation of classes. It
does not make method combinations available at compile-time either, but
Moon considers that to be a bad design choice.
Cost to implementors:
Unknown.
Cost to users:
Unknown, but probably fairly small.
Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
definitions will make sure they are fully defined at compile-time.
Alternatively, the definitions could be placed in a separate file,
which is loaded before compiling the file that depends on those
definitions.
Benefits:
Programmers can rely on programs that use the CLOS defining macros
being able to compile correctly in all implementations, without having
to wrap explicit EVAL-WHENs around every macro call.
Discussion:
This writeup is based on discussions between Moon, Gray, and
Loosemore, who are mostly in agreement on the things presented in
proposal MINIMAL. We have purposely avoided saying anything about
whether meta-objects representing the classes, methods, etc. get
created at compile-time, or whether such meta-objects are fully or
partially defined. The basic questions addressed by this issue are
what kinds of things can be defined and then used during compilation
of the same file that defines them, and what restrictions might apply.
These proposals are not completely compatible with the meta-object
protocol document (89-003). Gregor Kiczales says:
No one believes that what is written in draft 10 of the MOP is valid.
Sandra Loosemore says:
Although I admit I don't understand all of the issues involved with
the meta-object protocol, I prefer proposal MINIMAL over
NOT-SO-MINIMAL. I don't think leaving the issue of whether or not
classes can be instantiated at compile-time unspecified places an
undue burden on users, and it does leave more freedom for the
meta-object protocol to decide what the right behavior really is.
Dick Gabriel notes:
The question I have about the process going on with respect to the
CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
CLOS under various compilation/evaluation situations is being
over-specified.
At this stage of the game I worry that we might go a little too far in
one direction in specification when we are actually engaged in design
work. This isn't intended to be a criticism of any committees, but I
would feel a lot more comfortable with a conservative specification
that defined well-formed programs being loaded or compiled in fresh
Common Lisps with a pretty simple eval-when model that is easier to
specify and which makes it easy for all but the hairiest
compilation-environment-frobbing programs to be written.
∂15-Jun-89 0908 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jun 89 09:07:53 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15787; Thu, 15 Jun 89 10:08:16 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA23867; Thu, 15 Jun 89 10:08:11 -0600
Date: Thu, 15 Jun 89 10:08:11 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906151608.AA23867@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6
Reply-To: cl-compiler@sail.stanford.edu
This version includes the amendment proposed by Bob Kerns at the last
meeting as a separate proposal; the original proposal is unchanged
from the last distributed version. I have added some discussion on
implications of the amendment at the end of the writeup.
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
V4, 08 Mar 1989, Sandra Loosemore (wording changes)
V5, 22 Mar 1989, Sandra Loosemore (fix error language)
V6, 15 Jun 1989, Sandra Loosemore (Bob Kerns's amendment)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled. At what time (compiletime or runtime) are certain
kinds of definitions "captured"? What happens if these definitions
are not consistent at both compile and run times?
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
The process of compilation causes certain kinds of information present
in the compiletime environment to be captured and incorporated into
the resulting compiled code. Other kinds of information may not be
captured until the compiled code is actually run.
Specifically:
(1) The following information *must* be present in the compiletime
environment for the program to be compiled correctly. This
information need not also be present in the runtime environment.
(a) In conforming code, macros referenced in the code being compiled
must have been previously defined in the compiletime environment.
The compiler must treat any form that is a list beginning with
a symbol that does not name a macro or special form as a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) In conforming code, proclamations for SPECIAL variables must
be made in the compiletime environment before any bindings of
those variables are processed by the compiler. The compiler
must treat any binding of an undeclared variable as a lexical
binding.
(2) The compiler *may* incorporate the following kinds of information
into the code it produces, if the information is present in the
compiletime environment and is referenced within the code being
compiled. Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code. It is also
permissible for implementations to signal an error at runtime to
complain about the discrepancy. In all cases, the absence of the
information at compiletime is not an error, but its presence may
enable the compiler to generate more efficient code.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) The compiler can assume that type definitions made with DEFTYPE
or DEFSTRUCT in the compiletime environment will retain the same
definition in the runtime environment. It may also assume that
a class defined by DEFCLASS in the compiletime environment will
be defined in the runtime environment in such a way as to have
the same superclasses and metaclass. This implies that
subtype/supertype relationships of type specifiers will not
change between compiletime and runtime. (Note that it is not
an error for an unknown type to appear in a declaration at
compiletime, although it is reasonable for the compiler to
emit a warning in such a case.)
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the runtime behavior of the program is
undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime.
Rationale:
This proposal generally reflects current practice.
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:BOBS-AMENDMENT:
This is the same as proposal CLARIFY, except all of item (2g) is replaced
with:
(g) The compiler can assume that type definitions made with
DEFTYPE or DEFSTRUCT in the compiletime environment will
retain the same definition in the runtime environment. This
implies that subtype/supertype relationships of type specifiers
defined by DEFTYPE or DEFSTRUCT will not change between
compiletime and runtime. (Note that it is not an error for an
unknown type to appear in a declaration at compiletime,
although it is reasonable for the compiler to emit a warning
in such a case.)
Rationale:
Users should be free to redefine classes between compile and
run time.
Current Practice:
There don't seem to be any compilers around that do not implement the
provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
Several people have expressed reservations about items 2b and 2c, saying
that self-tail-recursion optimization and block compilation should not
be the default behavior of the compiler. Gail Zacharias responds:
This item [2c] has nothing to do with whether anybody does it by
default. The question is whether an end user can take a Common Lisp
program whose internals he's not familiar with, block-compile it, and
be guaranteed that it will continue to function correctly. This item
says that yes, a correct CL program must explicitly indicate what
functions in the source it will redefine at runtime. I don't think
this places such a great burden on the programmer. Without this
provision, only somebody intimately familiar with a program could know
whether it can be safely block-compiled, making block-compilation
useless in the context of portable CL programs.
This thing about "block compilation shouldn't be the default" seems to
come up every time this item is discussed. That's an environment
question and is not addressed by the proposal. The proposal simply
says that block compilation should be legal.
Sandra Loosemore says:
Proposal BOBS-AMENDMENT may lead to trouble because it implies
restrictions on user programs as well as implementations, and there is
no way for users to determine whether a type specifier involves a
class name or class object. An example of a user program that would
be affected is a macro that calls SUBTYPEP in the process of computing
its expansion. While the results returned by SUBTYPEP will give the
correct relationship between the type specifiers at the time the macro
is expanded, this may well be wrong for the runtime environment if
classes are allowed to move around in the type hierarchy in the
meantime.
It isn't even possible for users to definitely identify type specifiers
that involve class names or class objects, because there is no user
visible function in the language to expand DEFTYPE type specifiers.
If we adopt proposal BOBS-AMENDMENT, I see three possible solutions:
- we could simply document the problem in the standard, warning
users not to make assumptions about the permanence of SUBTYPEP
relationships without further analysis of the type specifiers
involved.
- we could add a TYPE-EXPAND function to expand type specifiers
that have been defined with DEFTYPE, to aid users in performing
their own analysis of type specifiers.
- we could add a function similar to SUBTYPEP (or perhaps an optional
argument to SUBTYPEP that would cause it to have this behavior),
that would always return NIL NIL if any of the type specifiers
involved are permitted to be redefined in a way that would change
their position in the type hierarchy.
There seems to be some general agreement that redefinability of classes
is really a property of the metaclass, but that we can't say anything
more definite until the metaobject protocol is in a more finished state.
I don't necessarily oppose BOBS-AMENDMENT, I just want to make sure that
everyone knows exactly what they're voting for.
∂15-Jun-89 0918 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jun 89 09:18:31 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15901; Thu, 15 Jun 89 10:18:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA23875; Thu, 15 Jun 89 10:18:47 -0600
Date: Thu, 15 Jun 89 10:18:47 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906151618.AA23875@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 6
Reply-To: cl-compiler@sail.stanford.edu
The previous version of this issue was discussed briefly at the last
meeting.
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION (passed)
Issue EVAL-WHEN-NON-TOP-LEVEL (passed)
Issue LOAD-TIME-EVAL (passed)
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Issue COMPILE-ARGUMENT-PROBLEMS (passed)
Category: CLARIFICATION, CHANGE
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
V3, 10 Feb 1989, Sandra Loosemore (new proposal)
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
with other pending proposals)
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
V6, 30 May 1989, Sandra Loosemore (fix proposal TIGHTEN to
apply only to COMPILE-FILE)
Status: Ready for release
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
This proposal presents a simple model of the compilation process. A
minimal compiler could be implemented to perform a code walk to apply
the indicated transformations to the function source code. Of course,
most compilers will perform other transformations as well, such as
translating the Lisp source code into a representation that is more
compact or which can be executed more efficiently.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls appearing lexically within the function have
already been expanded and will not be expanded again when the
function is called. (See CLtL p. 143.) The process of
compilation effectively turns MACROLET and SYMBOL-MACROLET
constructs into PROGNs with all instances of the local macros
in the body fully expanded.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within
the function are to be treated as lexical or special.
- Lexically nested EVAL-WHENs have been processed as stated in
proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
an implicit PROGN or as the constant NIL.
- If the function contains lexically nested LOAD-TIME-VALUE forms,
these have already been pre-evaluated and will not be evaluated
again when the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for functions that are
not COMPILED-FUNCTIONs to satisfy the above criteria.
(3) Clarify when functions are defined in a file which is compiled
with COMPILE-FILE, and the compiled file is subsequently LOADed,
objects of type COMPILED-FUNCTION result.
(4) Clarify that COMPILE may or may not produce an object of type
COMPILED-FUNCTION; if the implementation cannot compile a function,
it may simply do nothing at all. Change the description of
COMPILE (from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY) to state
that the behavior of COMPILE when passed a function that was
defined in a non-null lexical environment is unspecified (rather
than "is an error").
Rationale:
This proposal allows users to count on COMPILE-FILE always producing
objects that are COMPILED-FUNCTION-P. It also allows for the
possibility that COMPILE may not actually do anything interesting
in some implementations.
Some specific properties are assigned to compiled functions. Users
would be able to rely on any function which is of type
COMPILED-FUNCTION having really been (at least partially) compiled.
It also states what many people believe to be the minimum functionality
required of a compiler.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation. It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.
Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
In Utah Common Lisp, COMPILED-FUNCTION-P currently returns true of all
function objects, but there is an internal tag field in the object
which allows real compiled functions to be distinguished from
interpreted functions.
Cost to implementors:
Unknown, but probably not too great. Many implementations will
probably have to make some minor changes to representation of
functions and/or to the definition of COMPILED-FUNCTION-P, but
probably most of those changes are necessary to support the
FUNCTION-TYPE proposal anyway.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
This writeup originally contained two other proposals, FLUSH and
TIGHTEN-COMPILE. A straw vote at the March 1989 meeting indicated
that proposal TIGHTEN had the most support.
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One use of the COMPILED-FUNCTION type is in declarations. A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION. However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION.
Moon says:
I much prefer the option FLUSH...
This type has no portable meaning and never should have existed.
Pierson says:
What I (and believe Kent) want is a guarantee that [COMPILE] won't
signal an error; if nothing else works COMPILE will simply apply
#'IDENTITY to the symbol's function. Specifically, it should be
legal and safe to attempt to speed up my current program(s) by
doing:
(DO-SYMBOLS (SYM <my-package>)
(WHEN (FBOUNDP SYM) (COMPILE SYM)))
∂15-Jun-89 0921 X3J13-mailer issue MACRO-CACHING, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jun 89 09:21:25 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15952; Thu, 15 Jun 89 10:21:37 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA23878; Thu, 15 Jun 89 10:21:35 -0600
Date: Thu, 15 Jun 89 10:21:35 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906151621.AA23878@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue MACRO-CACHING, version 3
Reply-To: cl-compiler@sail.stanford.edu
This issue was distributed prior to the March meeting but was tabled so
that we could produce a simplified writeup. Here it is.
Issue: MACRO-CACHING
Forum: Compiler
References: 8.2 Macro Expansion (CLtL pp151-152),
Issues PACKAGE-CLUTTER, LISP-SYMBOL-REDEFINITION,
CONSTANT-MODIFICATION,
and MACRO-ENVIRONMENT-EXTENT
Category: Clarification
Edit history: 31-Jan-89, Version 1 by Pitman
11-Mar-89, Version 2 by Loosemore (add discussion)
30-May-89, Version 3 by Loosemore (simplify, rewrite)
Status: Ready for release
Problem Description:
The description of *MACROEXPAND-HOOK* in CLtL states that its purpose
is "to facilitate various techniques for improving interpretation
speed by caching macro expansions". However, there is no portable way
to correctly perform such caching.
Caching by displacement won't work because the same (EQ) macro call
form may appear in distinct lexical contexts. In addition, the macro
call form may be a read-only constant.
Caching by table lookup won't work because such a table would have to
be keyed by both the macro call form and the environment, and proposal
MACRO-ENVIRONMENT-EXTENT:DYNAMIC (passed at the March 1989 meeting)
states that macro environments are permitted to have only dynamic
extent.
Caching by storing macro call forms and expansions within the
environment object itself would work, but there are no portable
primitives that would allow users to do this.
Proposal (MACRO-CACHING:DISALLOW):
(1) Remove the suggestion that *MACROEXPAND-HOOK* be used for caching
macroexpansions. Instead, suggest that it might be used for
debugging purposes.
(2) Clarify that although there is no correct portable way to use
*MACROEXPAND-HOOK* to cache macro expansions, there is no
requirement that an implementation call the macro expansion
function more than once for a given form and lexical environment.
Rationale:
Item (1) fixes the description of what *MACROEXPAND-HOOK* is for, from
the point of view of a user. Item (2) allows implementors to use
other, correct but nonportable techniques for caching macro
expansions.
Proposal (MACRO-CACHING:DEPRECATE):
This is the same as DISALLOW, but also deprecate *MACROEXPAND-HOOK*.
Rationale:
Since *MACROEXPAND-HOOK* has now been shown to be unusable for its
original stated purpose, it is of questionable usefulness.
Test Case:
;; #1: File compiling this definition in some implementations will produce
;; a definition that returns read-only list structure. The call to EVAL
;; on the result must not try to modify the read-only structure during
;; macroexpansion. [See issue CONSTANT-MODIFICATION.]
(DEFUN READ-ONLY-FOO () '(MACROLET ((FOO (&WHOLE FORM) (+ 1 1))) (FOO)))
(EVAL (READ-ONLY-FOO))
=> 2
;; #2: This constructs a form and then uses it in two places in another
;; constructed form. Each of the uses is in a different lexical
;; contour, so must be expanded differently.
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO)
(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
;; #3: This is effectively the same thing but involves a MACROLET
;; shadowing a DEFMACRO rather than two MACROLETs, since some
;; implementations might only be caching expansions that come
;; from DEFMACRO.
(DEFMACRO FOO (&WHOLE FORM) '(+ 1 1))
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST ,FOO (MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
Current Practice:
Symbolics Genera does not use displacing or table caching in either
the interpreter or compiler.
Symbolics Cloe, a compiled only implementation, uses table caching
to boost compilation by a little. Running the test cases above turned
up a bug (in test case #3), which is now in the process of being fixed.
[The fact that a bug was turned up in code written by a CL implementor
is an existence proof that the potential for trouble was not imagined.]
The TI Explorer evaluator does displacement of macros, but is careful
to correctly handle the cases exemplified in test cases #1 and #2.
It does not do the right thing for #3, but that is a bug that can
fairly easily be fixed.
Cost to Implementors:
This proposal is upward compatible with correct implementations.
Cost to Users:
There is no cost to users, unless they were using semantically invalid
or nonportable caching techniques. Nonportable caching techniques might
continue to work in some implementations.
Cost of Non-Adoption:
Continued confusion about the purpose of *MACROEXPAND-HOOK* and the
validity of macro caching techniques.
Benefits:
The misleading description of *MACROEXPAND-HOOK*'s purpose is
removed.
Aesthetics:
Most people agree that macro caching techniques are only supposed to
improve speed without affecting semantics. This proposal is only
intended to underscore that necessary truth. Insofar as this is only
a clarification, it presumably has no significant aesthetic impact.
Discussion:
∂15-Jun-89 0913 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jun 89 09:13:39 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15840; Thu, 15 Jun 89 10:13:59 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA23870; Thu, 15 Jun 89 10:13:56 -0600
Date: Thu, 15 Jun 89 10:13:56 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906151613.AA23870@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 4
Reply-To: cl-compiler@sail.stanford.edu
This is a new proposal based on discussion of version 2 at the last
meeting.
Forum: Compiler
Issue: COMPILE-FILE-SYMBOL-HANDLING
References: CLtL p. 182
Issue IN-PACKAGE-FUNCTIONALITY (passed)
Issue CONSTANT-COMPILABLE-TYPES (passed)
Issue DEFPACKAGE (passed)
Category: CHANGE/CLARIFICATION
Edit History: V1, 01 Feb 1989, Sandra Loosemore
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
V3, 18 Apr 1989, Sandra Loosemore (new proposal)
V4, 15 Jun 1989, Sandra Loosemore (minor wording changes)
Status: Ready for release
Problem Description:
It is not clear how COMPILE-FILE is supposed to specify to LOAD how
symbols in the compiled file should be interned. In particular, what
happens if the value of *PACKAGE* is different at load-time than it
was at compile-time, or if any of the packages referenced in the file
are defined differently?
There are two models currently being used to implement this behavior:
(1) Symbols appearing in the output file produced by COMPILE-FILE
are qualified with package prefixes in the same way that PRINT
would qualify them. Symbols that are accessible in *PACKAGE*
at compile-time are looked up in *PACKAGE* at load-time. (This
is the "current-package" model.)
(2) Symbols appearing in the output file produced by COMPILE-FILE
are always qualified with the name of their home package,
regardless of the value of *PACKAGE*. (This is the
"home-package" model.)
Proposal COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:
In order to guarantee that compiled files can be loaded correctly,
users must ensure that the packages referenced in the file are defined
consistently at compile and load time. Conforming Common Lisp programs
must satisfy the following requirements:
(1) The value of *PACKAGE* when a top-level form in the file is processed
by COMPILE-FILE must be the same as the value of *PACKAGE* when the
code corresponding to that top-level form in the compiled file is
executed by the loader. In particular:
(a) Any top-level form in a file which alters the value of *PACKAGE*
must change it to a package of the same name at both compile and
load time.
(b) If the first top-level form in the file is not a call to
IN-PACKAGE, then the value of *PACKAGE* at the time LOAD is
called must be a package with the same name as the package that
was the value of *PACKAGE* at the time COMPILE-FILE was called.
(2) For all symbols appearing lexically within a top-level form that
were accessible in the package that was the value of *PACKAGE*
during processing of that top-level form at compile time, but
whose home package was another package, at load time there must
be a symbol with the same name that is accessible in both the
load-time *PACKAGE* and in the package with the same name as the
compile-time home package.
(3) For all symbols in the compiled file that were external symbols in
their home package at compile time, there must be a symbol with the
same name that is an external symbol in the package with the same name
at load time.
If any of these conditions do not hold, the package in which LOAD looks
for the affected symbols is unspecified. Implementations are permitted
to signal an error or otherwise define this behavior.
If all of these conditions hold, then when a compiled file is
loaded, the interned symbols it references are found as if by calling
INTERN with two arguments, the name of the symbol and the package
with the same name as the compile-time symbol's home package. (Note
that for a symbol that was accessible in *PACKAGE* at compile time,
this must give the same result as passing the load-time value of
*PACKAGE* to INTERN, due to restriction 2.) If no such package exists,
an error is signalled.
Rationale:
This proposal is merely an explicit statement of the status quo,
namely that users cannot depend on any particular behavior if the
package environment at load time is inconsistent with what existed
at compile time.
This proposal supports both the current-package and home-package
models as implementation techniques.
Current Practice:
PSL/PCLS implements the home-package model, as does A-Lisp. Utah
Common Lisp implements the current-package model, but the chief
compiler hacker says he thinks that the home-package model
actually makes more sense, and agrees that any program that behaves
differently under the two proposals is broken.
The TI Explorer currently implements the home-package model, after
trying it both ways.
KCL also implements the home-package model.
Lucid Lisp appears to implement the current-package model.
Symbolics Genera implements the current-package model. Symbolics
Cloe probably does also.
Coral also implements the current-package model.
Cost to implementors:
Proposal NEW-REQUIRE-CONSISTENCY is intended to be compatible with either
of the two models, but it may not be entirely compatible with the
details of current implementations.
In particular, some implementations that use the current-package
model appear to restrict IN-PACKAGE to being the first top-level
form in the file and dump all symbols referenced in the file after
the entire file has been processed (so that the value of *PACKAGE*
used to determine whether to qualify symbols in the output file is
the same for all symbols in the file). Under this proposal, these
implementations would have to note when the value of *PACKAGE*
changes during processing of a top-level form.
Cost to users:
Any user program that would break under proposal NEW-REQUIRE-CONSISTENCY
is probably already nonportable, since this proposal is intended to
leave the behavior unspecified where it would differ under the
two implementation models.
For a discussion of how the two models treat nonportable or erroneous
programs, see the "Analysis" section below.
Benefits:
COMPILE-FILE's treatment of symbols is made explicit in the standard.
Analysis:
The two implementation models differ in the following situations.
Proposal NEW-REQUIRE-CONSISTENCY, in effect, says that valid programs do
not cause any of these situations to occur, and the behavior in such
cases is unspecified (allowing both models to be used as valid
implementation techniques).
(1) The situation where the file does not contain a IN-PACKAGE
and where the compile-time value of *PACKAGE* is a package with a
different name than the load-time value of *PACKAGE*.
The current-package model would intern the names of symbols that
were accessible in *PACKAGE* at compile time in *PACKAGE* at load time.
The home-package model would intern the names of symbols that
were accessible in *PACKAGE* at compile time in the package with
the same name as their compile-time home package.
In general, programs must be compiled in the "right" package, so
that the compiler can find and apply the correct macro expansions,
type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.
As a result of macroexpansion or other transformations applied by
the compiler, the compiled file may contain symbol references that
were not present in the source file. The current-package model may
cause problems because these references may be resolved to be
symbols other than the ones that were intended. The home-package
model is more likely to find the correct symbols at load time.
(2) The situation where there is a symbol accessible in the
compile-time value of *PACKAGE* but with another home package, and
where at load time there is not a symbol with the same name that
is accessible in both packages. This situation might occur, for
example, if at compile time there is a symbol that is external in
its home package and that package is used by *PACKAGE*, but where
there is no such external symbol in that package at load time, or
the load-time *PACKAGE* does not use the other package.
The current-package model would find or create a symbol accessible
in *PACKAGE*.
The home-package model would find or create a symbol accessible in
a package with the same name as the symbol's compile-time home
package.
Some people feel that the behavior of the current-package model is
more intuitive in this situation, and that it is more forgiving of
differences between the compile-time and load-time package
structures. Others feel that the behavior of the home-package
model is more intuitive, and that if there have been significant
changes to the package structures, it is probably an indication
that the file needs to be recompiled anyway, since the compiler
might have picked up macro definitions and the like from the
wrong package.
(3) The situation where a symbol is external in its home package
and where there is no such external symbol in that package at load
time.
The current-package model would quietly find or create the symbol
in *PACKAGE* if the symbol were accessible in *PACKAGE* at compile
time. Otherwise, it will signal an error.
The home-package model would always just quietly find or create the
symbol as internal in its home package.
Not complaining when a symbol that is supposed to be external
isn't can be seen as a violation of modularity. However, it seems
like this argument should apply equally to symbols whose home
package is *PACKAGE* as symbols whose home package is somewhere
else.
Discussion:
There has been some further and lengthy discussion on the question of
whether this proposal overspecifies the behavior of COMPILE-FILE and
LOAD. At least one person would like the standard to say nothing on
this issue beyond a statement of the goal that loading a compiled file
should exhibit the same behavior as loading its source file. We have
also considered another approach to the problem that would place more
stringent requirements on conforming programs and fewer requirements
on implementations. Neither of these alternatives seems to have much
support, though.
∂15-Jun-89 0948 X3J13-mailer cl-compiler issue status
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jun 89 09:48:23 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA16522; Thu, 15 Jun 89 10:48:45 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA23896; Thu, 15 Jun 89 10:48:43 -0600
Date: Thu, 15 Jun 89 10:48:43 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906151648.AA23896@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: cl-compiler issue status
Reply-To: cl-compiler@sail.stanford.edu
Here is the list of the remaining cl-compiler issues. There are no
new issues this time; these are all leftovers from the last meeting.
The writeups on these issues are available via anonymous FTP from
host cs.utah.edu, in directory ~ftp/pub/cl-compiler/pending.
CLOS-MACRO-COMPILATION
V4 mailed on Jun 15.
COMPILE-ENVIRONMENT-CONSISTENCY
V6 mailed on Jun 15.
COMPILE-FILE-SYMBOL-HANDLING
V4 mailed on Jun 15.
COMPILED-FUNCTION-REQUIREMENTS
V6 mailed on Jun 15.
CONSTANT-FUNCTION-COMPILATION
V1 was tabled at the March meeting. We thought we might get another
proposal in the meantime, but it hasn't happened.
MACRO-CACHING
V3 mailed on Jun 15.
PROCLAIM-ETC-IN-COMPILE-FILE
V4 was tabled at the March meeting so that we could come up with a
better name for the new macro. DECLAIM seemed to have a slight edge
in the discussion since then.
SYNTACTIC-ENVIRONMENT-ACCESS
V9 mailed on Jun 13. I think we will probably have to prepare another
version (or some amendments) with some additional clarifications
between now and the meeting.
∂16-Jun-89 2126 X3J13-mailer Issue: PATHNAME-SYSTEM-TYPE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 21:26:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612467; 17 Jun 89 00:27:59 EDT
Date: Sat, 17 Jun 89 00:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: PATHNAME-SYSTEM-TYPE (version 2)
To: X3J13@sail.stanford.edu
Message-ID: <19890617042828.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-SYSTEM-TYPE
References: Internet RFC 1010, pages 24-25
Related issues: PATHNAME-LOGICAL
Category: ADDITION
Edit history: 23-May-89, Version 1 by Moon
17-Jun-89, Version 2 by Moon (add Macintosh, add discussion)
Problem description:
It is sometimes necessary to write nonportable pathname manipulation code
that performs operations specific to individual file systems. Sometimes
this is to get around inadequacies of the Common Lisp pathname model,
sometimes it is to take advantage of idiosyncratic features of a
particular file system. Common Lisp does not provide any way to ask what
file system a pathname is for, so there is no good way for this type of
pathname manipulation code to be sure what file system it is dealing
with. Sometimes it can tell by checking what Lisp implementation it is
running in, but as more and more implementations support network file
access, this is becoming less reliable.
Proposal (PATHNAME-SYSTEM-TYPE:ADD-FUNCTION):
Add the following function:
PATHNAME-SYSTEM-TYPE pathname [Function]
Coerce the pathname argument to a pathname, signalling an error of type
TYPE-ERROR if the argument is not a pathname, string, or file stream.
Return a keyword symbol that identifies the type of file system this
pathname is for. The names of these symbols are derived from the
system type names used by the Internet Domain Name system, listed in
the referenced document. Implementations that use a file system listed
in that document, or superseding documents, should return a symbol in
the keyword package whose name comes from that document. Examples:
:MSDOS MS/DOS or PC/DOS
:TOPS10 TOPS-10
:TOPS20 TOPS-20
:ULTRIX Ultrix
:UNIX Unix with long file names (4.2 or newer)
:VM/370 VM/370
:VMS VAX/VMS with long file names (version 4.4 or newer)
:XENIX Xenix
The following additional symbols are specified by Common Lisp:
:LOGICAL logical pathname (see issue PATHNAME-LOGICAL)
:MACINTOSH MacOS (missing from RFC 1010 for some reason)
:UNIX-14 Unix with 14-character file name limit
:VMS-9 VAX/VMS with 9-character file name limit
NIL system type cannot be determined
For file systems not named in the referenced document, implementations
should make up a name consistent with the spelling conventions defined
in that document.
Examples:
;; On a non-networked IBM PC:
(PATHNAME-SYSTEM-TYPE (USER-HOMEDIR-PATHNAME)) => :MSDOS
Rationale:
PATHNAME-SYSTEM-TYPE gives a nonportable pathname manipulation program
the basic information it needs to interpret namestrings and manipulate
pathname components.
Current practice:
Symbolics Genera has had a similar feature under a different name
for many years. A few of the keyword symbols returned by Genera
are spelled differently, merely for historical reasons.
Cost to Implementors:
Trivial.
Cost to Users:
None.
Cost of non-adoption:
Implementation-dependent kludges will have to be used.
Performance impact:
None.
Benefits:
Improved esthetics.
Esthetics:
Implementation-dependent kludges will not have to be used.
Discussion:
Some people feel that this feature is unnecessary.
∂16-Jun-89 2153 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 21:52:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612480; 17 Jun 89 00:54:54 EDT
Date: Sat, 17 Jun 89 00:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 3)
To: X3J13@sail.stanford.edu
Message-ID: <19890617045523.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-COMPONENT-VALUE
Related Issues:PATHNAME-CANONICAL-TYPE,
PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-UNSPECIFIC-COMPONENT,
PATHNAME-WILD
References: CLtL pp.410-3
Category: CLARIFICATION and CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Version 2, 9-May-89, by Moon (rewrite based on mail)
Version 3, 17-Jun-89, by Moon (add discussion, current practice)
Problem description:
CLtL is overly restrictive on the possible values for pathname components.
These restrictions are described in a funny way that makes it unclear
whether they are requirements, guidelines, or just an example.
The restrictions are not all written down in one place, but they appear
to be as follows:
Host nil, :wild, string, or list of strings
Device nil, :wild, string, or something else ("structured")
Directory nil, :wild, string, or something else ("structured")
Name nil, :wild, string, or something else ("structured")
Type nil, :wild, or string
Version nil, :wild, :newest, positive integer, implementation
dependent symbol, or implementation-dependent integer
less than or equal to zero. Suggestions include :oldest,
:previous, :installed, 0, and -1.
PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
allow any component to be :UNSPECIFIC. This has been voted in.
PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
symbols for the directory component.
PATHNAME-CANONICAL-TYPE proposes some new operations but does not
change the possible values of the type component.
PATHNAME-WILD proposes a portable way to test for implementation
dependent component values that indicate wildcard matching. It
does not change the possible values of any component.
Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):
The points of the proposal have been numbered/lettered to facilitate
discussion of individual points.
0. Pathname component value strings never contain the punctuation
characters that are used to separate pathname fields (e.g. slashes and
dots in Unix). Punctuation characters appear only in namestrings.
Characters used as punctuation can appear in pathname component values
with a non-punctuation meaning if the file system allows it (e.g. a Unix
file name that begins with a dot).
When examining pathname components, conforming programs must be prepared
to encounter any of the following values:
1. Any component can be NIL, which means the component has not
been specified.
2. Any component can be :UNSPECIFIC, which means the component has
no meaning in this particular pathname.
3. The device, directory, name, and type can be strings.
4. The host can be any object, at the discretion of the implementation.
5. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
6. The version can be any symbol or any integer. The symbol :NEWEST
refers to the largest version number that already exists in the file
system when reading, overwriting, appending, superseding, or directory
listing an existing file, and refers to the smallest version number
greater than any existing version number when creating a new file.
Other symbols and integers have implementation-defined meaning.
It is suggested, but not required, that implementations use positive
integers starting at 1 as version numbers, recognize the symbol :OLDEST
to designate the smallest existing version number, and use keyword
symbols for other special versions.
Wildcard pathnames can be used with DIRECTORY but not with OPEN, and
return true from WILD-PATHNAME-P (if issue PATHNAME-WILD passes). When
examining wildcard components of a wildcard pathname, conforming programs
must be prepared to encounter any of the following additional values
in any component or any element of a list that is the directory component:
7. :WILD, which matches anything.
8. A string containing implementation-dependent special wildcard
characters.
9. Any object, representing an implementation-dependent wildcard
pattern.
When constructing a pathname from components, conforming programs
must follow these rules:
a. Any component can be NIL. NIL in the host may mean a default host
rather than an actual NIL in some implementations.
b. The host, device, directory, name, and type can be strings. There
are implementation-dependent limits on the number and type of
characters in these strings.
c. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.) There are
implementation-dependent limits on the list's length and contents.
d. The version can be :NEWEST.
e. Any component can be taken from the corresponding component
of another pathname. When the two pathnames are for different
file systems (in implementations that support multiple file
systems), an appropriate translation occurs. If no meaningful
translation is possible, an error is signalled. The definitions
of "appropriate" and "meaningful" are implementation-dependent.
f. When constructing a wildcard pathname, the name, type, or version
can be :WILD, which matches anything.
g. An implementation might support other values for some components,
but a portable program cannot use those values. A conforming program
can use implementation-dependent values but this can make it
non-portable, for example, it might work only with Unix file systems.
Consequences:
The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
are as follows:
The removal of punctuation characters during parsing is specified.
"Structured" components are disallowed in non-wildcard pathnames,
except for the specific structuring of directories specified
in issue PATHNAME-SUBDIRECTORY-LIST.
"Structured" hosts are allowed, a generalization of CLtL's list
of strings.
The type and version can be "structured" in wildcard pathnames.
The difference between what component values a program can depend
on being able to use, versus what component values a program must
be prepared to encounter, is clarified.
The implementation-dependent variations are identified explicitly.
Rationale:
This should make it easier to write portable programs that deal with
pathnames and make it easier for implementors by clarifying the
framework into which they must fit. Also it should make it easier
to write the Common Lisp language specification by resolving some
things that were unclear about the status quo.
Adding "structured" hosts conforms to current practice.
Substituting a default host for NIL conforms to current practice
in implementations that require all pathnames to have a specific host.
Confining "structured" devices and names to wildcard pathnames, and
replacing "structured" directories with an explicit specification of
the form of the directory value, should improve portability without causing
any harm.
:WILD is only required to be supported in the name, type, or version,
which are the easiest to implement and the most useful in applications.
Current practice:
All versions of Symbolics Genera violate CLtL in the matter of hosts,
since it uses standard-objects as the host component. Genera deviates
slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
PATHNAME-COMPONENT-VALUE:SPECIFY.
Like Genera, the Explorer current practice is to use an object instead of
a string for the host component. The directory component is a list of
strings, not yet supporting the symbols specified in proposal
PATHNAME-SUBDIRECTORY-LIST; other than that, the Explorer conforms to
proposal PATHNAME-COMPONENT-VALUE:SPECIFY.
Macintosh Allegro Common Lisp 1.2.2 uses NIL and "" for :UNSPECIFIC,
and uses a string with punctuation characters instead of a list for
the directory. MAKE-PATHNAME won't set a component to NIL when
:DEFAULTS is used, it merges with the defaults instead.
Otherwise it seems consistent with what is proposed.
Lucid Common Lisp 3.0.1 under Unix uses NIL for :UNSPECIFIC, and uses
a list for directories of somewhat different form from what is proposed
in PATHNAME-SUBDIRECTORY-LIST. Lucid lets you store arbitrary information
in the version field with MAKE-PATHNAME :VERSION and will return it with
PATHNAME-VERSION (as long as it's a symbol or an integer), even though
it's not used. Otherwise it seems consistent with what is proposed.
Ibuki Common Lisp Release 01/01 behaves the same as Lucid, including the
same form of structured directory, except it doesn't have the ability to
store information in the unused pathname version field, and it has the
same bug in MAKE-PATHNAME that the Macintosh has. Otherwise it seems
consistent with what is proposed.
Other implementations were not surveyed.
This proposal assumes that no current or planned implementation
uses "structured" names except possibly for wildcards.
Cost to Implementors:
Most implementations already conform, except for the changes required
by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
the cost of this proposal itself should be minimal. It is conceivable
that an implementation may exist that has to change its pathname
representation, for example one that uses numbers as "structured" devices.
Some implementations may have to change their treatment of punctuation
characters.
Cost to Users:
None.
Cost of non-adoption:
Pathnames will continue to be a poorly specified part of the language.
Performance impact:
None of any significance.
Benefits/Esthetics:
The boundary between the specified behavior of pathnames and the
implementation-dependent behavior of pathnames will be more clear.
Discussion:
Sandra Loosemore comments:
As I've said before, I don't think that trying to construct or pick
apart pathnames by component can be accomplished portably in any case,
because even if you restrict the representation of what can appear in
the various components, the objects you stuff in may or may not make
sense for a particular file system. Instead, I would much prefer to
deprecate MAKE-PATHNAME and the PATHNAME-xxx accessors and leave the
question of representation of components unspecified in the standard.
I realize that this position may be seen as being too extreme. In
that case I'd be willing to shut up and go along with proposal SPECIFY
as long as my position gets noted in the writeup.
Larry Masinter and Dave Moon both feel that we should be able to
prescribe exact pathname component values for popular file systems, so
that multiple implementations will behave the same way when using the
same file system. Obvious candidates as the key file systems are MS/DOS,
Macintosh, Unix, and VAX/VMS. A call for volunteers to write up tables
for any of them produced absolutely no response, however.
∂16-Jun-89 2225 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 22:25:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612487; 17 Jun 89 01:26:52 EDT
Date: Sat, 17 Jun 89 01:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (version 7)
To: X3J13@sail.stanford.edu
Message-ID: <19890617052724.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Related-issues: PATHNAME-COMPONENT-CASE, PATHNAME-COMPONENT-VALUE
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
22-Mar-89, Version 4 by Moon (fix based on discussion)
19-May-89, Version 5 by Moon (improve based on mail)
21-May-89, Version 6 by Moon (final cleanups)
17-Jun-89, Version 7 by Moon (add current practice
and discussion; minor fixes based on discussion)
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of the pathname abstraction.
According to CLtL, only a string is a portable value for the directory
component of a pathname. Thus in order to denote a subdirectory, the use
of punctuation characters (such as dots, slashes, or backslashes) would
be necessary. The very fact that such syntax varies from host to host
means that although the representation might be "portable", the code
using that representation is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus different subdirectory punctuation.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO", while in other implementations it would denote a top-level
directory, because "." is not treated as punctuation. To be safe,
portable programs must avoid all potential punctuation characters.
- Even in implementations where "." is used for subdirectories,
"FOO.BAR" may be recognized by some to mean the "BAR" subdirectory of
"FOO" and by others to mean `a seven character directory name with "."
as the fourth character.'
- In fact, CLtL does not even say whether punctuation characters are
part of the string. eg, is "foo" or "/foo" the directory component for
a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the
directory component for a VMS pathname "[FOO]ME.LSP"?
PATHNAME-COMPONENT-VALUE:SPECIFY says punctuation characters are not
part of the string.
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Remove the "structured" directory feature mentioned on CLtL p.412.
Allow the value of a pathname's directory component to be a list. The
car of the list is one of the symbols :ABSOLUTE or :RELATIVE.
Each remaining element of the list is a string or a symbol (see below).
Each string names a single level of directory structure. The strings
should contain only the directory names themselves -- no punctuation
characters.
A list whose car is the symbol :ABSOLUTE represents a directory path
starting from the root directory. The list (:ABSOLUTE) represents
the root directory. The list (:ABSOLUTE "foo" "bar" "baz") represents
the directory called "/foo/bar/baz" in Unix [except possibly for
alphabetic case -- that is the subject of a separate issue].
A list whose car is the symbol :RELATIVE represents a directory path
starting from a default directory. The list (:RELATIVE) has the same
meaning as NIL and hence is not used. The list (:RELATIVE "foo" "bar")
represents the directory named "bar" in the directory named "foo" in the
default directory.
In place of a string, at any point in the list, symbols may occur to
indicate special file notations. The following symbols have standard
meanings. Implementations are permitted to add additional objects of any
non-string type if necessary to represent features of their file systems
that cannot be represented with the standard strings and symbols.
Supplying any non-string, including any of the symbols listed below, to a
file system for which it does not make sense signals an error of type
FILE-ERROR. For example, Unix does not support :WILD-INFERIORS in
most implementations.
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
:ABSOLUTE or :WILD-INFERIORS immediately followed by :UP or :BACK
signals an error.
"Syntactic" means that the action of :BACK depends only on the pathname
and not on the contents of the file system. "Semantic" means that the
action of :UP depends on the contents of the file system; to resolve
a pathname containing :UP to a pathname whose directory component
contains only :ABSOLUTE and strings requires probing the file system.
:UP differs from :BACK only in file systems that support multiple
names for directories, perhaps via symbolic links. For example,
suppose that there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :BACK "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
If a string is used as the value of the :DIRECTORY argument to
MAKE-PATHNAME, it should be the name of a toplevel directory and should
not contain any punctuation characters. Specifying a string, str, is
equivalent to specifying the list (:ABSOLUTE str). Specifying the symbol
:WILD is equivalent to specifying the list (:ABSOLUTE :WILD-INFERIORS),
or (:ABSOLUTE :WILD) in a file system that does not support :WILD-INFERIORS.
The PATHNAME-DIRECTORY function always returns NIL, :UNSPECIFIC, or a
list, never a string, never :WILD.
In non-hierarchical file systems, the only valid list values for the
directory component of a pathname are (:ABSOLUTE string) and
(:ABSOLUTE :WILD). :RELATIVE directories and the keywords
:WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file
systems.
Pathname merging treats a relative directory specially. Let
<pathname> and <defaults> be the first two arguments to
MERGE-PATHNAMES. If (PATHNAME-DIRECTORY <pathname>) is a list whose
car is :RELATIVE, and (PATHNAME-DIRECTORY <defaults>) is a list, then
the merged directory is the value of
(APPEND (PATHNAME-DIRECTORY <defaults>)
(CDR ;remove :RELATIVE from the front
(PATHNAME-DIRECTORY <pathname>)))
except that if the resulting list contains a string or :WILD immediately
followed by :BACK, both of them are removed. This removal of redundant
:BACKs is repeated as many times as possible.
If (PATHNAME-DIRECTORY <defaults>) is not a list or
(PATHNAME-DIRECTORY <pathname>) is not a list whose car is :RELATIVE, the
merged directory is
(OR (PATHNAME-DIRECTORY <pathname>) (PATHNAME-DIRECTORY <defaults>))
A relative directory in the pathname argument to a function such as
OPEN is merged with *DEFAULT-PATHNAME-DEFAULTS* before accessing the
file system.
Test Cases/Examples:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT passes with a default of
:COMMON, the value is the second one shown.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "../baz.lisp")) ;on Unix
=> (:RELATIVE :UP)
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/../mum/baz")) ;on Unix
=> (:ABSOLUTE "foo" "bar" :UP "mum")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to deal usefully with hierarchical file
systems, which are by far the most common file system type.
This would allow a system construction utility that organizes programs
by subdirectories to be portable to all implementations that have
hierarchical file systems.
Discussion indicated that "Implementations are permitted to add
additional objects of any non-string type if necessary to represent
features of their file systems that cannot be represented with the
standard strings and symbols" is a necessary escape hatch for things like
home directories and fancy pattern matching. Implementations should
limit their use of this loophole and use the standard keyword symbols
whenever that is possible.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera has no separate concepts of :UP and :BACK. Genera
represents Unix ".." as :UP, but deals with :UP syntactically, not
semantically.
On the Explorer, the directory component is a list of strings, not yet
supporting the symbols specified in proposal PATHNAME-SUBDIRECTORY-LIST.
Macintosh Allegro Common Lisp 1.2.2 uses a string with punctuation
characters instead of a list for the directory.
Lucid Common Lisp 3.0.1 under Unix uses a list for directories of
somewhat different form from what is proposed in
PATHNAME-SUBDIRECTORY-LIST. It uses :ROOT instead of :ABSOLUTE and uses
".." instead of :UP. It does use :RELATIVE.
Ibuki Common Lisp Release 01/01 uses a list for directories of somewhat
different form from what is proposed in PATHNAME-SUBDIRECTORY-LIST. It
uses :ROOT instead of :ABSOLUTE, uses :PARENT instead of :UP, and omits
the leading keyword instead of using :RELATIVE.
IIM uses a list for directories of somewhat different form from what is
proposed in PATHNAME-SUBDIRECTORY-LIST. It uses :ABSOLUTE-DIRECTORY
instead of :ABSOLUTE, uses :SUPER-DIRECTORY instead of :BACK, and omits
the leading keyword instead of using :RELATIVE.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory component by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
Implementations such as Genera, Explorer, Lucid, Ibuki, and IIM that
already have hierarchical directory handling will have to make an
incompatible change to switch to what is proposed here.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None for portable programs. This change is upward compatible with CLtL.
Nonportable programs will have to be changed if they use implementation
dependent hierarchical directory handling and the implementation
removes support for that when it adds support for this proposal.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES component to a
pathname, was discarded because it imposed an unnatural distinction
between a toplevel directory and its subdirectories. Pitman's guess is
the the idea was to try to make it a compatible change, but since most
programmers will probably want to change from implementation-specific
primitives to portable ones anyway, that's probably not such a big
deal. Also, there could have been some programs which thought the
change was compatible and ended up ignoring important information (the
:SUBDIRECTORIES component). Pitman thought it would be better if
people just accepted the cost of an incompatible change in order to
get something really pretty as a result.
Some people feel it is unnecessary to standardize the format of
pathname components such as the directory.
Moon doesn't like having both :UP and :BACK, but admits that some
file systems do it one way and some do it the other. He still thinks
it would be simpler if we got rid of :BACK and just had :UP.
To keep it simple, we chose not to add to this issue the functions
DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert
the name of a directory from or to the directory component of a file
inferior to that directory. This conversion is system-dependent, for
example TOPS-20 appends a type field and Unix does not. Also in some
systems the root directory has a name and in others it doesn't. Of
course these functions signal an error in non-hierarchical file
systems. Examples (for Unix, assuming #P print syntax for pathnames):
(directory-pathname-as-file #P"/usr/bin/sh") => #P"/usr/bin"
(pathname-as-directory #P"/usr/bin") => #P"/usr/bin"/
These functions have not been proposed because they are mainly useful
in conjunction with additional functions for manipulating directories
(creating, expunging, setting access control) that have not been made
available in Common Lisp.
∂16-Jun-89 2239 X3J13-mailer Issue: PATHNAME-COMPONENT-CASE (version 5)
Received: from VALLECITO.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89 22:38:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 296248; Sat 17-Jun-89 01:09:50 EDT
Date: Sat, 17 Jun 89 01:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: PATHNAME-COMPONENT-CASE (version 5)
To: X3J13@sail.stanford.edu
Message-ID: <19890617050833.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-COMPONENT-CASE
References: Pathnames (pp410-413),
MAKE-PATHNAME (p416),
PATHNAME-HOST (p417),
PATHNAME-DEVICE (p417),
PATHNAME-DIRECTORY (p417),
PATHNAME-NAME (p417),
PATHNAME-TYPE (p417)
Related-issues: PATHNAME-WILD
Category: CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
22-Mar-89, Version 2 by Moon, update and rewrite
9-May-89, Version 3 by Moon, remove alternate proposals
9-May-89, Version 4 by Moon, respond to discussion with KMP
17-Jun-89, Version 5 by Moon, fix typo, make minor improvements
to the presentation.
Problem Description:
Issues of alphabetic case in pathnames are a major source of problems.
In some file systems, the customary case is lowercase, in some uppercase,
in some mixed. In some file systems, case matters, in others it does
not.
There are two kinds of pathname case portability problems: moving
programs from one Common Lisp to another, and moving pathname component
values from one file system to another. To solve the first problem, all
Common Lisp implementations that support a particular file system must
use compatible representations for pathname component values. To solve
the second problem, there must be a common representation for the least
common denominator pathname component values that exist on all
interesting file systems.
This desire for a common representation directly conflicts with the
desire among programmers who only use one file system to work with the
local conventions and not think about issues of porting to other file
systems. The common representation cannot be the same as every local
convention, since they vary.
In the current anarchy of pathname component case conventions:
(NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
will produce foo.lisp in some Unix Common Lisp implementations
and will produce FOO.LISP in other Unix Common Lisp implementations.
(NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
will produce FOO.LISP in some Tops-20 Common Lisp implementations
and will produce "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"in other Tops-20 Common
Lisp implementations.
Problems like this make it difficult to use MAKE-PATHNAME for much of
anything without corrective (non-portable) code.
Other problems occur in merging because doing
(NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
(PARSE-NAMESTRING "MY-UNIX:x.lisp")))
should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
"MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.
Problems like this make it difficult to use any merging primitives for
much of anything without corrective (non-portable) code.
Proposal (PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT):
Add a keyword argument :CASE to MAKE-PATHNAME, PATHNAME-HOST,
PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, and PATHNAME-TYPE.
The possible values for the argument are :COMMON and :LOCAL.
:LOCAL means strings input to MAKE-PATHNAME or output by PATHNAME-xxx
follow the local file system's conventions for alphabetic case.
Strings given to MAKE-PATHNAME will be used exactly as written if
the file system supports both cases. If the file system only
supports one case, the strings will be translated to that case.
:COMMON means strings input to MAKE-PATHNAME or output by PATHNAME-xxx
follow this common convention:
- all uppercase means to use a file system's customary case.
- all lowercase means to use the opposite of the customary case.
- mixed case represents itself.
The second and third bullets exist so that translation from local to
common and back to local is information-preserving.
The default is :COMMON.
Namestrings always use local file system case conventions.
MERGE-PATHNAMES and TRANSLATE-WILD-PATHNAME map customary case in the
input pathnames into customary case in the output pathname.
Implications of the proposal:
Unix is case-sensitive and prefers lowercase, so it translates between
common and local by inverting the case of non-mixed-case strings.
Tops-20 is case-sensitive and prefers uppercase, so it uses identical
representations for common and local.
VAX/VMS is upper-case-only (that is, the file system translates all file
name arguments to upper case), so it translates common to local by
upcasing, and translates local to common with no change.
Macintosh is case-insensitive and prefers lowercase, so it translates
between common and local by inverting the case of non-mixed-case strings,
and ignores case in EQUAL of two pathnames.
Test Case/Examples:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :LOCAL) => "foo"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :LOCAL) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
:CASE :COMMON) => "TeX"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
:CASE :LOCAL) => "TeX"
(NAMESTRING (MAKE-PATHNAME :HOST "MY-UNIX" :NAME "FOO"
:CASE :COMMON) => "MY-UNIX:foo"
Rationale:
This does not solve the whole pathname problem, but it does improve
the situation for a clearly defined set of very common problems.
Together with the other pathname proposals, the behavior of pathnames
should be sufficiently consistent across Common Lisp implementations
and across file systems to allow portability of pathname-manipulating
programs.
The current situation where different implementations talk about
the *same* file system in different ways will be corrected by this
and some of the other pathname proposals.
Upper case is chosen as the common case for no better reason than
consistency with Lisp symbols.
The :CASE keyword argument provides access to both common and local
conventions without introducing any new functions. The default
convention is the common one, assuming that most programs are fully
portable and therefore :COMMON will be more frequently used.
Current Practice:
There are no known implementations of exactly what is proposed.
Symbolics Genera uses common case normally, and provides a way to
access the local case (called "raw") that in practice is rarely used.
Symbolics Genera's own file system is case-insensitive and uses lower
case as the customary case, but transparent network access is available
to file systems using all known case conventions.
Several Common Lisp implementations behave as if :CASE :LOCAL was
specified (but accept no :CASE argument).
Cost to Implementors:
The :CASE feature is easily added, but some implementations may have
to change the default behavior when :CASE is not specified. No
implementation need change its internal representation, nor the way
pathnames print, just the interface functions listed above.
Cost to Users:
Technically, this change is upward compatible.
In fact, since the existing CLtL spec is so poor, nearly everyone relies
heavily on implementation-specific behavior since there is little other
choice. As such, any change is almost certain to break lots of programs,
in usually superficial but nevertheless important ways. However, if we
really make the pathname facility more portable, the user community may
be willing to bear the consequences of these changes.
Cost of Non-Adoption:
We would be contributing to the perpetuation of the existing fiasco of a
pathname system.
Performance Impact:
None.
Benefits:
One step closer to a usable pathname system.
Aesthetics:
Anything that simplifies the user model of pathnames is an improvement.
Discussion:
Some people would rather use lowercase as the common case. The
decision is essentially arbitrary. Everywhere else in Common Lisp
where case matters, uppercase was chosen.
It has been proposed that the Common Lisp specification should include
specifications of the exact behavior of pathnames for several popular
operating systems, so that multiple implementations for those
operating systems would be compatible with each other. This proposal
does that for alphabetic case.
Some people want the default for :CASE to be :LOCAL instead of :COMMON.
See Rationale.
There should probably be a remark somewhere that says that portable
programs shouldn't expect to be able to create and/or access distinct
files whose pathname components differ only in case.
∂19-Jun-89 0847 X3J13-mailer Issue: DATA-IO (version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 08:47:32 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 612929; 19 Jun 89 11:49:14 EDT
Date: Mon, 19 Jun 89 11:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: DATA-IO (version 7)
To: X3J13@sail.stanford.edu
Message-ID: <19890619154723.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Issue: DATA-IO
References: CLtL pp.360, 370, 382
Related issues: none
Category: ADDITION
Edit history: Version 1, 9-May-89, by Moon
Version 2, 10-May-89, by Moon
(clarify ambiguities, add PRINT-UNREADABLE-OBJECT)
Version 3, 18-May-89, by Moon (respond to KMP's comments)
Version 4, 21-May-89, by Moon (almost-final cleanup)
Version 5, 22-May-89, by Pitman (``never say never'')
Version 6, 23-May-89, by Moon (final cleanup)
Version 7, 18-Jun-89, by Moon (more fixes based on
discussion in the cleanup subcommittee)
Problem description:
Storing data in textual form in files, as Lisp expressions, is common
practice but has some pitfalls. Files can be unreadable if #<...> syntax
is written by the printer, or if the reader syntax or package varies
between writing and reading. Files of data intended to be carried from
one Lisp implementation to another can fail to read correctly if
implementation-dependent syntax extensions get used when not intended.
CLtL p.370 recommends that unreadable objects be printed with #<...>
syntax including implementation-dependent information. Now that users
can write their own PRINT-OBJECT methods, a way is needed for such
methods to print this syntax without any implementation-dependent coding.
Proposal (DATA-IO:ADD-SUPPORT):
1a. Add a new variable *PRINT-READABLY*. Add a corresponding keyword
argument :READABLY to WRITE. The default value of *PRINT-READABLY* is
NIL. If *PRINT-READABLY* is true, then printing any object produces a
printed representation that the reader will accept. If this is not
possible, the printer signals an error of type PRINT-NOT-READABLE rather
than using an unreadable syntax such as #<...>. The printed
representation produced when *PRINT-READABLY* is true might or might not
be the same as the printed representation produced when *PRINT-READABLY*
is false.
1b. All methods for PRINT-OBJECT must obey *PRINT-READABLY*. This
includes both user-defined methods and implementation-defined methods.
1c. If *PRINT-LENGTH* (or *PRINT-LEVEL*) and *PRINT-READABLY* are both
true, and a list longer (deeper) than *PRINT-LENGTH* (*PRINT-LEVEL*) is
printed, the printer might ignore *PRINT-LENGTH* (or *PRINT-LEVEL*) or it
might signal PRINT-NOT-READABLE, but it will not print an abbreviated
list.
1d. Printed representations produced when *PRINT-READABLY* is true and
*PRINT-ESCAPE* is false might or might not be readable.
1e. Setting *PRINT-READABLY* to true and *PRINT-ESCAPE* to false might or
might not prevent errors of type PRINT-NOT-READABLE from being signalled.
2. Add a new reader control variable, *READ-EVAL*, whose default value is
T. If *READ-EVAL* is NIL, the #. reader macro signals an error. If
*READ-EVAL* is false and *PRINT-READABLY* is true, any PRINT-OBJECT
method that would output a #. reader macro either outputs something
different or signals an error of type PRINT-NOT-READABLE.
3. Add a new macro:
WITH-STANDARD-IO-SYNTAX &body body [Macro]
Within the dynamic extent of <body>, all reader/printer control
variables, including any implementation-defined ones not specified by
Common Lisp, are bound to values that produce standard read/print
behavior. The values for Common Lisp specified variables are:
*PACKAGE* The USER package
*PRINT-ARRAY* T
*PRINT-BASE* 10
*PRINT-CASE* :UPCASE
*PRINT-CIRCLE* NIL
*PRINT-ESCAPE* T
*PRINT-GENSYM* T
*PRINT-LENGTH* NIL
*PRINT-LEVEL* NIL
*PRINT-PRETTY* NIL
*PRINT-RADIX* NIL
*PRINT-READABLY* T
*READ-BASE* 10
*READ-DEFAULT-FLOAT-FORMAT* SINGLE-FLOAT
*READ-EVAL* T
*READ-SUPPRESS* NIL
*READTABLE* The standard readtable
The values returned by WITH-STANDARD-IO-SYNTAX are the values
of the last body form, or NIL if there are no body forms.
4. Add a new macro:
PRINT-UNREADABLE-OBJECT (object stream &key type identity) [Macro]
&body body
Output a printed representation of <object> on <stream>, beginning with
"#<" and ending with ">". Everything output to <stream> by the <body>
forms is enclosed in the angle brackets. If :type is true, the body
output is preceded by a brief description of the object's type and a
space character. If :identity is true, the body output is followed by
a space character and a representation of the object's identity,
typically a storage address.
If *PRINT-READABLY* is true, PRINT-UNREADABLE-OBJECT signals an error
of type PRINT-NOT-READABLE without printing anything.
The <object>, <stream>, :type, and :identity arguments are all evaluated
normally. :type and :identity default to false. It is valid to omit
the <body> forms. If :type and :identity are both true and there are no
<body> forms, only one space character separates the type and the identity.
The value returned by PRINT-UNREADABLE-OBJECT is NIL.
5. Add a new condition type:
PRINT-NOT-READABLE [Type]
Errors which occur during output while *PRINT-READABLY* is true, as a
result of attempting to output a printed representation that cannot be
read back, should inherit from this type. This is a subtype of ERROR.
The init keyword :OBJECT is supported to initialize the slot containing
the object being printed, which can be accessed using
PRINT-NOT-READABLE-OBJECT.
Examples:
;; Example #1: Reliable Write-Read
(WITH-OPEN-FILE (FILE pathname :DIRECTION :OUTPUT)
(WITH-STANDARD-IO-SYNTAX
(PRINT DATA FILE)))
; ... Later, in another Lisp:
(WITH-OPEN-FILE (FILE pathname :DIRECTION :INPUT)
(WITH-STANDARD-IO-SYNTAX
(SETQ DATA (READ FILE))))
;; Example #2: Use of PRINT-UNREADABLE-OBJECT
;; Note that in this example, the precise form of the output
;; is really implementation-dependent.
(DEFMETHOD PRINT-OBJECT ((OBJ AIRPLANE) STREAM)
(PRINT-UNREADABLE-OBJECT (OBJ STREAM :TYPE T :IDENTITY T)
(PRINC (TAIL-NUMBER OBJ) STREAM)))
(PRINT MY-AIRPLANE)
#<Airplane NW0773 36000123135> ;in Implementation A
;or
#<FAA:AIRPLANE NW0773 17> ;in Implementation B
Rationale:
1. *PRINT-READABLY* is important so that errors involving data with no
readable printed representation are detected when writing the file, not
later on when the file is read.
*PRINT-READABLY* is different from *PRINT-ESCAPE* because output printed
with escapes only has to be generally recognizable by humans, whereas
output printed readably has to be reliably recognizable by computers.
2. Binding *READ-EVAL* to NIL is useful when reading data that came from
an untrusted source, such as a network or a user-supplied data file, to
prevent the #. reader macro from being exploited as a "Trojan horse" to
cause arbitrary forms to be evaluated.
3. Providing the WITH-STANDARD-IO-SYNTAX macro to bind all the variables,
instead of using LET and explicit bindings of the existing variables,
ensures that nothing is overlooked and avoids problems with
implementation-defined reader/printer control variables.
If the user wishes to use a non-standard value for some variable, such as
*PACKAGE* or *READ-EVAL*, it can be bound by LET inside the body of
WITH-STANDARD-IO-SYNTAX. Similarly, if the user dislikes the somewhat
arbitrary choices of values for *PRINT-CIRCLE* and *PRINT-PRETTY*, they
can be bound to the preferred values inside the body.
4. PRINT-UNREADABLE-OBJECT allows user-written PRINT-OBEJCT methods to
adhere to implementation-specific style without requiring users to write
implementation-dependent code.
5. Defining a specific condition type associated with *PRINT-READABLY*
makes it possible for programs to handle the condition and recognize
the offending object.
Current practice:
Symbolics Genera has had these features for many years, except with
different names. For instance, WITH-STANDARD-IO-SYNTAX is named
WITH-STANDARD-IO-ENVIRONMENT and binds *PACKAGE* to a non-standard
package. The proposed new names are better than the Genera names.
Genera's WITH-STANDARD-IO-ENVIRONMENT also disables #., to prevent trojan
horses, since #. could evaluate an arbitrary form. This is particularly
important for network protocols. WITH-STANDARD-IO-SYNTAX does not bind
*READ-EVAL* to NIL, because that would prevent using #. in the printer
for common datatypes, which is current practice in some implementations
for printing PATHNAMEs or RANDOM-STATEs.
In Genera, PRINT-UNREADABLE-OBJECT is called SYS:PRINTING-RANDOM-OBJECT
and takes slightly different arguments. In PCL, PRINT-UNREADABLE-OBJECT
is called PCL:PRINTING-RANDOM-THING.
Cost to Implementors:
Very small, these features are all easy to add. If #. is output by any
system-supplied print methods, they might want to invent a different
syntax, however that is not required by this proposal.
Cost to Users:
None if they don't use the feature. Otherwise just the cost of
supporting *PRINT-READABLY* or using PRINT-UNREADABLE-OBJECT in their
PRINT-OBJECT methods.
Cost of non-adoption:
There will be no reliable, standard way to write data into a file.
Performance impact:
Negligible. Entering WRITE may be slightly slower since there is
one more keyword argument to parse and one more special variable
to bind before calling PRINT-OBJECT.
Benefits:
Data can be written into files reliably without resorting to
implementation-specific programming.
Esthetics:
Mildly improved.
Discussion:
Pitman and Moon support this proposal.
∂19-Jun-89 0851 X3J13-mailer Issue: FLOAT-UNDERFLOW (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 08:51:26 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 612931; 19 Jun 89 11:53:09 EDT
Date: Mon, 19 Jun 89 11:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: FLOAT-UNDERFLOW (version 3)
To: X3J13@sail.stanford.edu
Message-ID: <19890619155127.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Issue: FLOAT-UNDERFLOW
References: CLtL p.231
Related issues:LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION (not written up),
ERROR-CHECKING-IN-NUMBERS-CHAPTER
Category: ADDITION and CLARIFICATION
Edit history: Version 1, 9-May-89, by Moon (suggested in January, but
the writeup was late)
Version 2, 23-May-89, by Moon (final cleanup for post-CLtL
changes to Common Lisp)
Version 3, 18-Jun-89, by Moon (update based on discussion
within the cleanup subcommittee)
Problem description:
In implementations with denormalized floating point numbers (as in IEEE
floating point), which are closer to zero than any non-zero normalized
floating point numbers, should the LEAST-POSITIVE- and
MOST-POSITIVE-XXX-FLOAT constants be the normalized or denormalized
values? Which is preferred depends on the application. Note that in
IEEE floating point, denormalized results are normally only produced
as a result of underflow.
Also, there is no portable way to control what happens when a floating
point number underflows. Sometimes this is an error, sometimes not.
Indeed there is no mention at all of underflow or overflow in CLtL.
Pending issue ERROR-CHECKING-IN-NUMBERS-CHAPTER does not mention floating
point overflow or underflow. Draft ANSI Common Lisp specifies error
conditions named FLOATING-POINT-OVERFLOW and FLOATING-POINT-UNDERFLOW
but does not specify the circumstances in which they are signalled and
does not provide any way to suppress underflow checking.
Proposal (FLOAT-UNDERFLOW:ADD-CONTROLS):
1. Clarify that the existing LEAST-POSITIVE-XXX-FLOAT and
LEAST-NEGATIVE-XXX-FLOAT constants are literally as defined, and
therefore can be denormalized numbers in implementations that have
denormalized numbers.
2. Add the following constants, whose values are the normalized floating
point numbers closest in value to (but not equal to) zero. In
implementations that don't have denormalized numbers, the values of these
constants are the same as the values of the other constants.
LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT [Constant]
LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT [Constant]
LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-LONG-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT [Constant]
LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT [Constant]
3. Add the following macro:
WITHOUT-FLOATING-UNDERFLOW-TRAPS &body body [Macro]
Within the dynamic extent of the body, the result of a floating point
computation which would otherwise underflow is a denormalized number
(if they are supported in the implementation) or zero, whichever is
closest to the mathematical result.
The values of WITHOUT-FLOATING-UNDERFLOW-TRAPS are the values of the
last body form, or NIL if there are no body forms.
4. Clarify that outside the dynamic extent of
WITHOUT-FLOATING-UNDERFLOW-TRAPS, a floating point computation that
underflows should signal an error of type FLOATING-POINT-UNDERFLOW. A
result that can only be represented in denormalized form is considered an
underflow in implementations that support denormalized floating point
numbers.
5. Clarify that a floating point computation that overflows should signal
an error of type FLOATING-POINT-OVERFLOW.
Example: (not portable of course)
(expt 0.1 40) => FLOATING-POINT-UNDERFLOW error
(describe (without-floating-underflow-traps (expt 0.1 40))) =>
1.0e-40 is a single-precision floating-point number.
Sign 0, exponent 0, 23-bit fraction 213302 (denormalized)
Rationale:
The ANSI Common Lisp standard should be compatible with the widely used
IEEE Floating Point standard.
WITHOUT-FLOATING-UNDERFLOW-TRAPS is provided as a macro to allow
implementation flexibility. It could expand into HANDLER-BIND for
FLOATING-POINT-UNDERFLOW, but in most implementations it will probably
expand into implementation-dependent code that sets a hardware mode bit.
Specifying "should signal" rather than "signals" or "might signal" for
floating-point overflows and underflows seems the best balance between
safety and implementation freedom. It wouldn't harm the proposal to
change it to one of the other two phrases.
Current practice:
The proposal exactly matches Symbolics Genera release 7 except for
the names of the conditions.
Lucid Common Lisp 3.0 implements parts 1, 2, 4, and 5 of the proposal.
Instead of point 3 of the proposal, Lucid Common Lisp 3.0 has a macro
(WITH-FLOATING-POINT-TRAPS enable-condition-list disable-condition-list
&body body) that enables and disables a variety of floating-point-related
conditions, a function ENABLED-FLOATING-POINT-TRAPS that returns a list
of condition names, a constant SUPPORTED-FLOATING-POINT-CONDITIONS whose
value is a list of condition names, and several additional condition
names (the exact set of condition names varies, depending on the
hardware).
Cost to Implementors:
Adding the constants and the macro is easy. Since it was never clarified
that floating point underflow is to be detected in safe code, implementors
who had not already implemented that might have to go to some expense.
In the laissez-faire spirit of floating point in Common Lisp, we could
relax the specification and say only that underflow might signal rather
than should signal.
Cost to Users:
None.
Cost of non-adoption:
Each Common Lisp implementation that uses IEEE Floating Point will have
to invent its own way to deal with underflow and denormalized numbers.
Performance impact:
No effect on code optimized for speed rather than safety.
Benefits:
Increased portability and correctness of floating point code.
Esthetics:
Neutral.
Discussion:
Maybe point 3 of the proposal should be replaced by the more complex
feature from Lucid. This would allow re-enabling underflow checking
after it had been disabled, and would allow control over other traps such
as overflow and inexact result. Moon would prefer to keep it simple,
but if others support the more general mechanism, he can accept it.
If the group cannot agree on this, Moon suggests dropping point 3 from
the proposal and passing points 1, 2, 4, and 5.
∂19-Jun-89 0914 X3J13-mailer Issue: MAP-INTO (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 09:14:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612957; 19 Jun 89 12:15:55 EDT
Date: Mon, 19 Jun 89 12:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: MAP-INTO (version 2)
To: X3J13@sail.stanford.edu
Message-ID: <19890619161633.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Issue: MAP-INTO
References: none
Related issues: BIT-ARRAY-FUNCTIONS
Category: ADDITION
Edit history: 23-May-89, version 1 by Moon
19-Jun-89, version 2 by Moon (fix arglist)
Problem description:
The function MAP is very useful but can be a source of inefficiency
because it conses the result. Sometimes the user has storage
already allocated in which the result could be stored.
Proposal (MAP-INTO:ADD-FUNCTION):
Add the following function:
MAP-INTO result-sequence function sequence &rest more-sequences [Function]
Destructively modifies the result-sequence to contain the results of
applying function to each element in the argument sequences in turn.
Returns result-sequence.
MAP-INTO differs from MAP in that it modifies an existing sequence
rather than creating a new one.
The arguments result-sequence and each element of sequences can each be
either a list or a vector (one-dimensional array). Note that nil is
considered to be a sequence, of length zero. If result-sequence and
each element of sequences are not all the same length, the iteration
terminates when the shortest sequence is exhausted.
If BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS passes, then MAP-INTO will
allow result-sequence and each element of sequences to be mappables
all of the same rank.
The function must take at least as many arguments as there are
sequences provided, and at least one sequence must be provided.
If function has side effects, it can count on being called first on all
of the elements with index 0, then on all of those numbered 1, and so
on.
Examples:
(map-into x #'+ x y)
(map-into q #'cons keys vals)
Rationale:
MAP-INTO is a simple way to express reuse of storage that is
stylistically consistent with the rest of Common Lisp.
Current practice:
Symbolics Genera 7.2 implements the proposal.
Cost to Implementors:
Small.
Cost to Users:
None.
Cost of non-adoption:
Small.
Performance impact:
None.
Benefits:
More expressive language.
Esthetics:
User programs won't have to write the above examples as
(loop for xx on x and yy in y do
(setf (car xx) (+ (car xx) yy)))
or something else about equally horrible.
Discussion:
None.
∂19-Jun-89 0911 X3J13-mailer Issue: BIT-ARRAY-FUNCTIONS (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 09:11:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612952; 19 Jun 89 12:13:02 EDT
Date: Mon, 19 Jun 89 12:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 6)
To: X3J13@sail.stanford.edu
Message-ID: <19890619161334.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
If the discussion gets lengthy, indicating that it actually is
controversial, then we should just drop it, rather than letting it
take up too much time.
Issue: BIT-ARRAY-FUNCTIONS
References: The binary bit-array functions BIT-AND, BIT-IOR, BIT-XOR,
BIT-EQV, BIT-NAND, BIT-NOR, BIT-ANDC1, BIT-ANDC2, BIT-ORC1,
and BIT-ORC2 (CLtL p.294).
The unary bit-array function BIT-NOT (CLtL p.295).
The mapping functions EVERY, MAP, NOTANY, NOTEVERY, and SOME
(CLtL pp.249-250).
The functions COUNT and POSITION (CLtL p.257).
Related issues: none
Category: ADDITION
Edit history: Version 1, 9-May-89, by Moon
Version 2, 10-May-89, by Moon (add second proposal)
Version 3, 12-May-89, by Moon (small wording improvements)
Version 4, 13-May-89, by Moon (make more understandable)
Version 5, 23-May-89, by Moon (fix -p naming convention)
Version 6, 19-Jun-89, by Moon (small fixes based on comments
from Kim Barrett)
Problem description:
Logical operations on bit vectors have been found to be useful in such
programs as compiler flow analysis. They are easy to implement in
straight Common Lisp, but such an implementation is many times slower
than an optimized implementation on most machines. This is partly
because many machines have instructions to perform these operations or
inner kernels of them, and partly because Common Lisp is not a good
language for implementing this type of low-level bit-oriented operation.
Common Lisp provides some logical operations on bit arrays, but the
provided set is incomplete. Furthermore, the operations that are
provided are only defined for arrays of identical dimensions, making them
less useful for bit vectors that represent sets, where trailing zero
elements are often omitted. Some of the sequence functions are useful
for bit vectors, but users (correctly) fear that their implementation may
be optimized for general sequences, not for bit vectors.
CLtL does not specify whether BIT-AND and related functions respect the
fill-pointer, however the description of fill-pointers on p.295 implies
that they should.
This issue contains two alternative proposals.
Proposal (BIT-ARRAY-FUNCTIONS:ADD):
1. Allow the binary bit-array functions referenced above to accept
arguments of identical rank but unequal dimensions. Nonexistent elements
of bit-array-1 or bit-array-2 are assumed to be zero. If the third
argument is T or a bit-array, result elements outside the bounds of the
array must be zero or an error should be signalled. If the third
argument is NIL or omitted, each dimension of the result array is equal
to either the corresponding dimension of bit-array-1 or the corresponding
dimension of bit-array-2. The larger of the two dimensions is used when
necessary to hold all the nonzero elements of the result, otherwise
either the larger or the smaller of the two dimensions is used.
2. Allow BIT-NOT with a bit array as the second argument to accept
arguments of identical rank but unequal dimensions. Result elements
outside the bounds of the array must be zero or an error should be
signalled.
3. Add the following functions:
BIT-SUBSETP bit-array-1 bit-array-2
Returns true if for every element of bit-array-1 that is 1, the
element with the same subscripts exists in bit-array-2 and is 1.
Bit-array-1 and bit-array-2 must have identical rank but need not
have identical dimensions.
BIT-DISJOINTP bit-array-1 bit-array-2
Returns true if for every element of one bit-array that is 1, the
element with the same subscripts either does not exist in the other
bit-array or is 0. Bit-array-1 and bit-array-2 must have identical
rank but need not have identical dimensions.
BIT-EQUAL bit-array-1 bit-array-2
Returns true if for every element of one bit-array that is 1, the
element with the same subscripts exists in the other bit-array and
is 1. Bit-array-1 and bit-array-2 must have identical rank but need
not have identical dimensions.
4. Specify that the binary bit-array functions referenced above, the
unary bit-array function referenced above, and the three bit-array
functions referenced in point 3 respect the fill-pointer of any argument
that is one-dimensional and has a fill-pointer.
5. Suggest in the language specification document that compilers should
optimize the following functions when the sequence argument is declared
to be a bit-vector, taking advantage of any relevant special machine
instructions.
COUNT
POSITION
6. Suggest in the language specification document that compilers should
optimize the following functions when there are two arguments, the second
argument is declared to be a bit-vector, and the predicate argument is
#'ZEROP, taking advantage of any relevant special machine instructions.
EVERY
NOTANY
NOTEVERY
SOME
Proposal (BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS):
Points 1, 2, 4, 5, and 6 are the same as BIT-ARRAY-FUNCTIONS:ADD.
Substitute for point 3:
3. Do not add the three new functions. Instead, generalize the mapping
functions referenced above (EVERY, MAP, NOTANY, NOTEVERY, and SOME) so
that they operate on "mappables" rather than just sequences. Define a
mappable to be an array or a list. Specify that the mappable arguments
to a mapping function, and the result in the case of MAP with a non-NIL
first argument, must all be of the same rank (the rank of a list is
considered to be 1). Mapping accesses array elements in row-major order.
Generalize the existing specification that a mapping function uses the
length of the shortest sequence, to say that a mapping function uses on
each axis the minimum of the dimensions on that axis of the mappable
arguments.
Additional point 7:
7. Suggest in the language specification document that compilers should
optimize the functions EVERY, NOTANY, NOTEVERY, and SOME when there are
two arguments, the second argument is declared to be a bit-array, and the
predicate argument is #'ZEROP, taking advantage of any relevant special
machine instructions. In addition compilers should optimize when the
second argument is a call with two arguments to one of the binary
bit-array functions referenced above, to avoid consing an intermediate
result.
Examples:
The equivalents of UNION and INTERSECTION for sets represented
as bit vectors, with 1's in positions where set elements are
present, are BIT-IOR and BIT-AND respectively.
(COUNT 1 (THE BIT-VECTOR BV)) computes the cardinality of a bit
vector (called the population on some computers). This is
analogous to LOGCOUNT of an integer.
(POSITION BIT (THE BIT-VECTOR BV)) scans for a 1 or 0 bit, but
can likely be implemented using a word-at-a-time scan.
(EVERY #'ZEROP (THE BIT-VECTOR BV)) tests whether a bit vector
is entirely zero.
(BIT-SUBSETP bit-array-1 bit-array-2) is equivalent to
(EVERY #'ZEROP (BIT-ANDC2 bit-array-1 bit-array-2)) [under
the first proposal, only when the arguments are of rank 1.]
(BIT-DISJOINTP bit-array-1 bit-array-2) is equivalent to
(EVERY #'ZEROP (BIT-AND bit-array-1 bit-array-2)) [under
the first proposal, only when the arguments are of rank 1.]
This is analogous to NOT of LOGTEST of two integers.
(BIT-EQUAL bit-array-1 bit-array-2) is equivalent to
(EVERY #'ZEROP (BIT-XOR bit-array-1 bit-array-2)) [under
the first proposal, only when the arguments are of rank 1.]
BIT-EQUAL differs from EQUAL only when the arguments are of
unequal dimensions.
Rationale:
1,2. Relaxing the requirement that bit arrays must have equal dimensions
was requested by users who had tried to use these operations on sets.
3. Three new functions are added by BIT-ARRAY-FUNCTIONS:ADD because EVERY
only works on vectors, since issue SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS was
rejected. BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS includes the minimal
portion of that proposal needed to avoid adding any new functions, while
omitting all the controversial parts.
4. Respecting the fill-pointer of vectors makes the BIT-xxx functions
more consistent with the rest of the language. They can be thought of as
sequence functions for bit-vectors (and sequence functions always respect
the fill-pointer) that have been generalized to work on multidimensional
bit-arrays as well.
5,6,7. The suggestion for compiler optimization is to give users the
confidence that they will get good results when using sequence and
mapping operations on bit vectors. Otherwise we would feel the need to
add additional bit-vector-specific functions to perform these operations
in a way that is optimized and specialized for bit-vectors. Recommending
optimization of a particular way of performing these operations avoids
the problem of each implementation choosing a different idiom to
optimize, resulting in performance problems when porting.
Current practice:
Symbolics Genera 7.2 has something like the first proposal, but only for
bit vectors, not generalized for bit arrays. Genera has some additional
functions (BIT-VECTOR-POSITION, BIT-VECTOR-CARDINALITY, and
BIT-VECTOR-ZERO-P) that aren't really necessary since they are equivalent
to POSITION, COUNT, or EVERY plus a type declaration. The proposal seems
to fit into the rest of Common Lisp better than Genera's current practice.
Symbolics Genera 7.2 does not respect the fill-pointer in BIT-AND.
Cost to Implementors:
Implementing these very efficiently may require some clever hand coding.
Of course the standard cannot mandate any particular level of efficiency
and a simple, low-cost implementation is permissible. Implementing the
compiler suggestions requires keeping track of type declarations in the
compiler, but most compilers already do that. The second proposal
requires slightly more compiler analysis than the first proposal.
A run-time type test and dispatch to code specialized for bit-arrays
could be used instead of compiler analysis, at a small efficiency cost.
Cost to Users:
None, unless some implementation currently violates point 4 and user
programs currently depend on that. It seems quite unlikely that anyone
would depend on BIT-xxx functions to access past the fill-pointer.
Cost of non-adoption:
Less featureful language. Some bit array manipulation will have to be
written in nonportable Lisp code or in C or assembly language.
Performance impact:
None on programs that don't use these features. Negligibly small on
the binary bit-array functions referenced above when array dimensions
are equal. Large improvement for programs that can take advantage of
these features when running in an implementation that optimizes them.
Benefits:
More featureful language.
Esthetics:
More featureful language.
Discussion:
This functionality was suggested on the Common Lisp mailing list
12-Jan-89. The detailed design has evolved from what was suggested and
is greatly simplified.
The loose specification of the result dimensions in points 1 and 2 is to
allow maximum implementation freedom. This is not essential to the
proposal and could be changed to require that the result have the same
dimension as the larger of the two arguments.
It has been suggested that points 6 and 7 should specify some other
predicates to optimize, such as #'PLUSP or (COMPLEMENT #'ZEROP). Moon
doesn't think this is important enough to be worth adding.
∂19-Jun-89 0916 X3J13-mailer Issue: STRING-COERCION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 09:16:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612963; 19 Jun 89 12:17:44 EDT
Date: Mon, 19 Jun 89 12:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: STRING-COERCION (Version 2)
To: X3J13@sail.stanford.edu
Message-ID: <19890619161822.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a new issue. It comes from an analysis of ambiguities in CLtL
that had not already been resolved. This issue seems sufficiently
simple and noncontroversial that I would like to see it on the agenda
for the June X3J13 meeting.
Issue: STRING-COERCION
References: Strings (pp299-304),
STRING= (p300), STRING-EQUAL (p301), STRING< (p301),
STRING> (p301), STRING<= (p301), STRING>= (p301),
STRING/= (p301), STRING-LESSP (p302), STRING-GREATERP (p302),
STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
STRING-NOT-EQUAL (p302), STRING-TRIM (p302), STRING-LEFT-TRIM (p302),
STRING-RIGHT-TRIM (p302), STRING-UPCASE (p303), STRING-DOWNCASE (p303),
and STRING-CAPITALIZE (p303).
Related issues: none
Category: CLARIFICATION
Edit history: Version 1, 9-May-89 by Moon
Version 2, 9-May-89 by Pitman (editorial changes)
Problem description:
CLtL is inconsistent about the argument coercion performed by the
referenced functions. Page 299 says that the <string> argument can
be either a symbol or a string. Page 304 says that these functions
effectively call the STRING function, thus accepting a symbol,
a string, or a character.
Neither page lists the set of affected functions explicitly.
Page 304 says that if any other data type is used, an error is
signalled. But some implementations allow other types, such as
pathnames, to be coerced to strings, which page 299 appears to allow
but page 304 appears to forbid. In some implementations these
coercions are under user control via methods for a generic function.
Proposal (STRING-COERCION:MAKE-CONSISTENT):
Specify that the referenced functions perform coercion identical to
the action of the STRING function.
Specify that the STRING function can perform additional implementation
dependent coercions. In all cases the returned value is of type STRING.
Only in the case where no coercion is defined is the STRING function
required to signal an error; in that case, the error is of type TYPE-ERROR.
Examples:
(string-lessp #\a "B") => T
Rationale:
Our choices are to make the coercion identical to the STRING function,
identical to the COERCE function, or different from both of them. The
COERCE function won't coerce non-null symbols to strings, so it is out.
Being consistent with the STRING function seems better than inventing
yet another set of string coercion rules. Removing the ability for the
STRING function to coerce characters to strings would be an incompatible
change, so instead we clarify that the other functions have that ability.
Allowing additional coercions is harmless and consistent with current
practice.
Current practice:
Symbolics Genera follows page 304 except for allowing additional
coercions. Symbolics Cloe follows page 299 except for not allowing
additional coercions.
Cost to Implementors:
Small changes to eighteen functions.
Cost to Users:
None, this is upward-compatible.
Cost of non-adoption:
Inconsistency and confusion about what coercions are allowed.
Performance impact:
None. If these things have to accept symbols, accepting characters
too can't make much difference. The implementation of character
arguments to string functions might cons a string, but this has no
performance impact on programs that don't use the feature.
Benefits:
Consistency.
Esthetics:
Consistency.
Discussion:
None.
∂19-Jun-89 0922 X3J13-mailer Issue: STREAM-CAPABILITIES (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 09:21:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612966; 19 Jun 89 12:23:35 EDT
Date: Mon, 19 Jun 89 12:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: STREAM-CAPABILITIES (version 3)
To: X3J13@sail.stanford.edu
Message-ID: <19890619162413.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is an old issue. KMP and I have prepared a revised writeup which
we think is ready for release.
Issue: STREAM-CAPABILITIES
References: Standard streams (pp. 327-329)
Category: ADDITION
Edit history: Version 1 by Pierson 5-Jul-88, add redesign per Pitman
Version 2 by Moon, 10-May-89, remove controversial parts
Version 3 by Moon, 12-May-89, improve wording and examples
Problem description:
Programs cannot currently distinguish between interactive use and batch
(or background) use without using implementation-dependent extensions.
For example, there is currently no way to tell whether it is useful to
ask a question when an unexpected situation is encountered.
Note: earlier versions of this issue tried to solve another problem
as well. See discussion section.
Proposal (STREAM-CAPABILITIES:INTERACTIVE-STREAM-P):
Add the following function:
INTERACTIVE-STREAM-P stream
Returns T if the stream is interactive, otherwise NIL. Signals
an error of type TYPE-ERROR if the argument is not a stream.
The precise meaning of INTERACTIVE-STREAM-P is implementation
dependent, and may depend on the underlying operating system. However
the general intent is to distinguish between interactive and batch (or
background or command-file) operations.
Some examples of the things that might identify a stream as interactive
include:
1. The stream is connected to a person (or equivalent) in
such a way that the program can prompt for information and
expect to receive different input depending on the prompt.
2. The program is expected to prompt for input and support
"normal input editing".
3. READ-CHAR might hang waiting for the user to type something
instead of quickly returning a character or EOF.
*TERMINAL-IO* might or might not be interactive.
Examples:
(when (> measured limit)
(let ((error (round (* (- measured limit) 100)
limit)))
(unless (if (interactive-stream-p *query-io*)
(yes-or-no-p "The frammis is out of tolerance by ~D%.~@
Is it safe to proceed? " error)
(< error 15)) ;15% is acceptable
(error "The frammis is out of tolerance by ~D%." error))))
Rationale:
INTERACTIVE-STREAM-P has been proposed several times and is clearly
needed by any program that alters its behavior depending on whether
it is interacting with a user or running in a "batch" mode.
Current practice:
Most implementations have this feature already, often under a
different name.
Cost to Implementors:
Implementations will have to support this new function. Correct support
will require some thought for each operating system supported.
Cost to Users:
None, this is an upward-compatible extension.
Cost of non-adoption:
Less featureful language.
Performance impact:
None.
Benefits:
More featureful language.
Esthetics:
More featureful language.
Discussion:
It's not possible to make a specific definition of "interactive" that
applies to all operating systems, we concluded from earlier discussion.
However, "everyone knows" appoximately what it means. Hence the idea
of describing it by example rather than defining it.
Note that some proposed features for telling whether two streams are
connected to the same source or sink of information have been removed
from this version of the proposal. These were the functions
STREAM-SAME-SOURCE-P, STREAM-SAME-DESTINATION-P, STREAM-SOURCE-ID-LIST,
and STREAM-DESTINATION-ID-LIST. These could be revived in another
proposal if desired, but Moon thought INTERACTIVE-STREAM-P was
important and didn't want it to be lost due to controversy over these
unrelated functions.
∂19-Jun-89 1055 X3J13-mailer Issue: CONFORMANCE-POSITION (version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 10:55:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613124; 19 Jun 89 13:57:34 EDT
Date: Mon, 19 Jun 89 13:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONFORMANCE-POSITION (version 9)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8906121125.AA02395@decwrl.dec.com>
Message-ID: <19890619175806.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 12 Jun 89 07:23
From: chapman%aitg.DEC@decwrl.dec.com
One small comment on the informal rules for conforming programs. This
is a repeat of a comment I made in May, which must have gotten lost.
2. Conforming code is written using only the syntax specified in the standard.
or syntax defined using the syntax extension mechanisms (macros and
reader macros) specified in the standard.
∂19-Jun-89 1546 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 15:45:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613340; 19 Jun 89 18:36:05 EDT
Date: Mon, 19 Jun 89 18:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8906121153.AA03319@decwrl.dec.com>
Message-ID: <19890619223643.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This would be acceptable if the following functions were added
to the list of exceptions. Does anyone object to these additions?
gethash
remhash
get-macro-character
get-dispatch-macro-character
read
read-preserving-whitespace
read-delimited-list
read-line
read-char
unread-char
peek-char
listen
read-char-no-hang
read-from-string
parse-integer
read-byte
write-to-string
prin1-to-string
princ-to-string
write-string
format
y-or-n-p
yes-or-no-p
open
rename-file
probe-file
directory
trace
untrace
apropos-list
The order of the above list is by page number in CLtL.
The ones that I care the most about are gethash and read-line.
If there is a design criterion that includes all the functions
listed in the proposal and excludes any of the functions I've
listed above, I for one can't figure out what it is. Nothing
was listed in the rationale section.
I reviewed the list for things I felt should be deleted, and did
not find any except for:
directory-namestring
describe
Could we get a version of the proposal with these changes, or
are they controversial in any way?
∂19-Jun-89 1545 X3J13-mailer Issue: PATHNAME-WILD (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89 15:45:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613310; 19 Jun 89 17:41:50 EDT
Date: Mon, 19 Jun 89 17:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: PATHNAME-WILD (version 6)
To: X3J13@sail.stanford.edu
Message-ID: <19890619214210.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue is on the agenda for the June X3J13 meeting. KMP and I
have prepared a revised writeup which we think is ready for release.
Issue: PATHNAME-WILD
Forum: Cleanup
References: Pathnames (pp410-413)
Related issues: PATHNAME-COMPONENT-VALUE, PATHNAME-LOGICAL
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
9-May-89, Version 3 by Moon (small fixes)
10-May-89, Version 4 by Moon (add two more functions)
13-May-89, Version 5 by Moon (minor cleanups, add clarification)
19-Jun-89, Version 6 by Moon (revise based on extensive
discussion in the cleanup subcommittee; rewrite
the description of TRANSLATE-PATHNAME so it is
possible to understand it)
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards (:WILD). For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
Some file systems support even more complex wildcards, for example
regular expressions.
The CL pathname model does not specify a way to represent complex
wildcards, which means, for example, that (MAKE-PATHNAME :NAME "F*O")
cannot be recognized by portable code as containing a wildcard.
Common Lisp provides only the first of these four common operations
on wildcard pathnames:
(1) Enumerate the set of existing files that match the pathname;
this is provided by the DIRECTORY function.
(2) Test whether a pathname contains wildcards.
(3) Test whether a pathname matches a wildcard pathname.
(4) Translate one pathname into another according to a mapping specified
by a pair of wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTIONS):
Introduce the following three functions:
1. WILD-PATHNAME-P pathname &optional field-key
Tests a pathname for the presence of wildcard components. If the first
argument is not a pathname, string, or file stream an error of type
TYPE-ERROR is signalled.
If no <field-key> is provided, or the <field-key> is NIL, the result is
T if <pathname> has any wildcard components, NIL if <pathname> has none.
If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, the result is T
if the indicated component of <pathname> is a wildcard, NIL if the
component is not a wildcard. Note that not all implementations
support wildcards in all fields, according to PATHNAME-COMPONENT-VALUE.
2. PATHNAME-MATCH-P pathname wildcard
T if <pathname> matches <wildcard>, otherwise NIL. The matching rules
are implementation-defined but should be consistent with the
DIRECTORY function. Missing components of <wildcard> default to :WILD.
If either argument is not a pathname, string, or file stream an error
of type TYPE-ERROR is signalled. It is valid for <pathname> to be a
wild pathname; a wildcard field in <pathname> will only match a
wildcard field in <wildcard>, i.e. the function is not commutative.
It is valid for <wildcard> to be a non-wild pathname.
3. TRANSLATE-PATHNAME source from-wildcard to-wildcard &optional reversible
Translates the pathname <source>, which matches <from-wildcard>, into
a corresponding pathname <result>, which matches <to-wildcard>, and
returns <result>.
The pathname <result> is <to-wildcard> with each wildcard or missing
field replaced by a portion of <source>. A "wildcard field" is a
pathname component with a value of :WILD, a :WILD element of a
list-valued directory component, or an implementation-defined portion
of a component, such as the "*" in the complex wildcard string
"foo*bar" that some implementations support. An implementation that
adds other wildcard features, such as regular expressions, must define
how TRANSLATE-PATHNAME extends to those features. A "missing field" is
a pathname component with a value of NIL.
The portion of <source> that is copied into <result> is implementation
defined. Typically it is determined by the user interface conventions
of the file systems involved. Usually it is the portion of <source>
that matches a wildcard field of <from-wildcard> that is in the same
position as the wildcard or missing field of <to-wildcard>. If there
is no wildcard field in <from-wildcard> at that position, then usually
it is the entire corresponding pathname component of <source>, or in
the case of a list-valued directory component, the entire corresponding
list element. For example, if the name components of <source>,
<from-wildcard>, and <to-wildcard> are "gazonk", "gaz*", and "h*"
respectively, then in most file systems, the wildcard fields of the
name component of <from-wildcard> and <to-wildcard> are each "*", the
matching portion of <source> is "onk", and the name component of
<result> is "honk". However, the exact behavior of TRANSLATE-PATHNAME
cannot be dictated by the Common Lisp language and must be allowed to
vary, depending on the user interface conventions of the file systems
involved.
During the copying of a portion of <source> into <result>, additional
implementation-defined translations of alphabetic case or file naming
conventions might occur, especially when <from-wildcard> and
<to-wildcard> are for different hosts.
If <reversible> is true, the translation must be reversible, that is,
the following identity must hold for all cases where no error is
signalled:
(equal (translate-pathname (translate-pathname pathname from to t)
to from t)
pathname)
In some file systems the above identity is true only when
(member (pathname-version pathname) '(:newest :unspecific)).
This is considered valid, as Common Lisp cannot force all the
file systems in the world to implement versions.
If <reversible> is false (which is the default), the translation is
determined by the user interface conventions of the file systems
involved and is not necessarily reversible. In some file systems the
<reversible> argument is ignored because the user interface conventions
are reversible anyway.
If any of the first three arguments is not a pathname, string, or file
stream an error of type TYPE-ERROR is signalled. It is valid for
<source> to be a wild pathname; in general this will produce a wild
result. It is valid for <from-wildcard> and/or <to-wildcard> to be
non-wild pathnames. (PATHNAME-MATCH-P <source> <from-wildcard>) must
be true or an error is signalled.
Implementation guideline: one file system performs this operation by
examining each piece of the three pathnames in turn, where a piece is a
pathname component or a list element of a structured component such as
a hierarchical directory. Hierarchical directory elements in
<from-wildcard> and <to-wildcard> are matched by whether they are
wildcards, not by depth in the directory hierarchy. If the piece in
<to-wildcard> is present and not wild, it is copied into the result.
If the piece in <to-wildcard> is :WILD or NIL, and either <reversible>
is false or the piece in <from-wildcard> is not a complex wildcard, the
piece in <source> is copied into the result. Otherwise, the piece in
<to-wildcard> might be a complex wildcard such as "foo*bar" and the
piece in <from-wildcard> should be wild; the portion of the piece in
<source> that matches the wildcard portion of the piece in
<from-wildcard> replaces the wildcard portion of the piece in
<to-wildcard> and the value produced is used in the result.
4. Clarify that the functions OPEN (and WITH-OPEN-FILE), PROBE-FILE,
FILE-WRITE-DATE, FILE-AUTHOR, and TRUENAME only accept non-wildcard
pathnames and signal an error if given a pathname for which
WILD-PATHNAME-P returns true.
5. Clarify that the functions RENAME-FILE, DELETE-FILE, LOAD, and
COMPILE-FILE have implementation-defined consequences when given a
wildcard pathname. Each function might signal an error or might operate
on all files that match the wildcard pathname.
Examples:
;The following examples are not portable. They are written to run
;with particular file systems and particular wildcard conventions.
;Other implementations will behave differently. These examples are
;intended to be illustrative, not to be prescriptive.
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
(WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
(WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
;This example assumes one particular set of wildcard conventions
;Not all file systems will run this example exactly as written
(DEFUN RENAME-FILES (FROM TO)
(DOLIST (FILE (DIRECTORY FROM))
(RENAME-FILE FILE (TRANSLATE-PATHNAME FILE FROM TO))))
(RENAME-FILES "/usr/me/*.lisp" "/dev/her/*.l")
;Renames /usr/me/init.lisp to /dev/her/init.l
(RENAME-FILES "/usr/me/pcl*/*" "/sys/pcl/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp
;In some file systems the result might be /sys/pcl/5-may/low.lisp
(RENAME-FILES "/usr/me/pcl*/*" "/sys/library/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp
;In some file systems the result might be /sys/library/5-may/low.lisp
(RENAME-FILES "/usr/me/foo.bar" "/usr/me2/")
;Renames /usr/me/foo.bar to /usr/me2/foo.bar
(RENAME-FILES "/usr/joe/*-recipes.text" "/usr/jim/cookbook/joe's-*-rec.text")
;Renames /usr/joe/lamb-recipes.text to /usr/jim/cookbook/joe's-lamb-rec.text
;Renames /usr/joe/pork-recipes.text to /usr/jim/cookbook/joe's-pork-rec.text
;Renames /usr/joe/veg-recipes.text to /usr/jim/cookbook/joe's-veg-rec.text
;This example assumes one particular set of wildcard conventions and
;illustrates how and why reversible translation uses different rules
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" NIL)) => "barbaz"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" T)) => "barbaz"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*" NIL)) => "foobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*" T)) => "bar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*" "foo*" NIL)) => "foofoobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*" "foo*" T)) => "foofoobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "bar" "*" "foo*" NIL)) => "foobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "bar" "*" "foo*" T)) => "foobar"
;Using Unix syntax and the wildcard conventions used by the
;particular version of Unix on which I tried this:
(NAMESTRING
(TRANSLATE-PATHNAME "/usr/dmr/hacks/frob.l"
"/usr/d*/hacks/*.l"
"/usr/d*/backup/hacks/backup-*.*"))
=> "/usr/dmr/backup/hacks/backup-frob.l"
(NAMESTRING
(TRANSLATE-PATHNAME "/usr/dmr/hacks/frob.l"
"/usr/d*/hacks/fr*.l"
"/usr/d*/backup/hacks/backup-*.*"))
=> "/usr/dmr/backup/hacks/backup-ob.l"
;This is similar to the above example but uses two different hosts,
;U: which is a Unix and V: which is a VMS. Note the translation
;of file type and alphabetic case conventions.
(NAMESTRING
(TRANSLATE-PATHNAME "U:/usr/dmr/hacks/frob.l"
"U:/usr/d*/hacks/*.l"
"V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
=> "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-FROB.LSP"
(NAMESTRING
(TRANSLATE-PATHNAME "U:/usr/dmr/hacks/frob.l"
"U:/usr/d*/hacks/fr*.l"
"V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
=> "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-OB.LSP"
;This example presumes background information described in PATHNAME-LOGICAL
(DEFUN TRANSLATE-LOGICAL-PATHNAME-1 (PATHNAME RULES)
(LET ((RULE (ASSOC PATHNAME RULES :TEST #'PATHNAME-MATCH-P)))
(UNLESS RULE (ERROR "No translation rule for ~A" PATHNAME))
(TRANSLATE-PATHNAME PATHNAME (FIRST RULE) (SECOND RULE) T)))
(TRANSLATE-LOGICAL-PATHNAME-1 "FOO:CODE;BASIC.LISP"
'(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")
("FOO:CODE;" "MY-UNIX:/lib/foo/")
("FOO:PATCHES;*;" "MY-UNIX:/lib/foo/patch/*/")))
=> the pathname MY-UNIX:/lib/foo/basic.l
Rationale:
1,2,3. These three functions provide a standardized interface to the
idiosyncratic wildcard functionality of each host file system.
1. WILD-PATHNAME-P makes it possible to detect wild pathnames reliably and
do something useful (give up, merge out the bothersome components, call
DIRECTORY for a list of matching pathnames, etc.)
2,3. TRANSLATE-PATHNAME is needed by many application programs that deal with
wildcard pathnames. PATHNAME-MATCH-P and TRANSLATE-PATHNAME are needed
by logical pathnames. The reversible feature is needed by logical
pathnames. The PATHNAME-LOGICAL proposal cannot be implemented without
these features.
4. Since these functions return a value connected with one file, there
is no meaningful way to extend them to work on wildcard pathnames. It
seems best to specify that they signal an error, rather than leaving
the consequences undefined.
5. The consequences are proposed to be implementation-defined because
current practice varies and no one wants to change.
Current Practice:
Presumably no implementation supports the proposal exactly as stated.
Symbolics Genera has had similar features under different names for many
years:
(SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
etc., indicating the first wild field.
(SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
etc. test individual fields.
The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
:PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
PATHNAME-MATCH-P.
The Explorer also supports the messages :WILD-P (although it only
returns NIL or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and
:PATHNAME-MATCH.
Points 4 and 5 are current practice as far as the authors are aware.
The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
all files that match.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcards to write it.
Since the detailed behavior is at the implementor's discretion, the cost
is unlikely to be large. Some file systems will do all the work and the
implementor need only provide an interface to the file system or to a
standard library routine. For other file systems the implementor has to
write the actual matching and translation algorithms.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
many situations. User programs that deal with wildcard pathnames would
have to operate on implementation-dependent representations and hence
would not be easily portable.
The biggest cost is that the logical pathnames proposal would be stymied.
Performance Impact:
None.
Benefits:
A more complete set of wildcard pathname operations. Portable user
programs that deal with wildcard pathnames will be more consistent
and reliable. A portable system construction tool can be written
and the foundations are laid for a `logical pathname' facility
(proposed separately in PATHNAME-LOGICAL).
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
There was some question about the name. The name PATHNAME-WILD-P
suggests a ``slot'' of a pathname (like PATHNAME-HOST),
while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
The committee was split on what to call it. Since it is more
like a type than a slot, the name WILD-PATHNAME-P was chosen.
It's been suggested that WILD-PATHNAME-P and PATHNAME-MATCH-P be allowed
to return a value other than T to represent "truth", which would
somehow encode some additional information.
∂19-Jun-89 1721 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89 17:21:23 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA25917; Mon, 19 Jun 89 18:21:35 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00204; Mon, 19 Jun 89 18:21:32 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906200021.AA00204@defun.utah.edu>
Date: Mon, 19 Jun 89 18:21:31 MDT
Subject: Re: Issue: EXTRA-RETURN-VALUES
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 19 Jun 89 18:36 EDT
> If there is a design criterion that includes all the functions
> listed in the proposal and excludes any of the functions I've
> listed above, I for one can't figure out what it is. Nothing
> was listed in the rationale section.
Repeating what I already said in an earlier message to cl-editorial....
Rather than arbitrarily adding more functions to this list, I would
much prefer to *remove* things from it. As it is, I do not understand
what the motivation is for permitting extra return values from many of
the functions that are already on the list. Since these are
exceptions to a general rule, our goal ought to be to keep the list as
small as possible, and there ought to be some specific justification
provided for each exception that is on the list.
I cannot vote for this proposal in its current form, unless we are
willing to take the time to consider each of the proposed exceptions
individually at the meeting.
-Sandra
-------
∂19-Jun-89 1845 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 19 Jun 89 18:45:13 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 19 Jun 89 19:49:04 EDT
Date: Mon, 19 Jun 89 19:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: EXTRA-RETURN-VALUES
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <19890619223643.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890619234721.3.BARMAR@OCCAM.THINK.COM>
Date: Mon, 19 Jun 89 18:36 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I reviewed the list for things I felt should be deleted, and did
not find any except for:
...
describe
Since Genera DOES return an extra value from DESCRIBE, I'm surprised you
think this one should be deleted. I happen to like Genera's behavior.
Is anyone keeping a count of the number of functions being proposed to
allow extra return values? Pretty soon we might want to change the
sense of the proposal....
barmar
∂19-Jun-89 2112 X3J13-mailer June Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Jun 89 21:12:09 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA00872g; Mon, 19 Jun 89 21:10:17 PDT
Received: by challenger id AA12775g; Mon, 19 Jun 89 21:09:18 PDT
Date: Mon, 19 Jun 89 21:09:18 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906200409.AA12775@challenger>
To: x3j13@sail.stanford.edu
Subject: June Agenda DRAFT
Looks pretty sparse.
X3J13 Committee Meeting Agenda DRAFT
June 26 - 29, 1989
1 Call to Order, Monday, June 26, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Waters/Perdue series and generated proposals vote, Guy Steele
7 Coffee Break 10:30
8
9 LUNCH 12:00
10 Window System Standard, Jim Kempf (2 hours)
11 Break
12
13 Recess, 5:00pm
14 Call to Order, Tuesday, June 27 9:00am
15 Compiler Subcommittee Report, Sandra Loosemore (4 hours)
16 Coffee Break 10:30am
17 Compiler Subcommittee Report continuation
18 Lunch 12:00
19 Break 3:00
20
21 Recess 5:00
22 Call to Order, Wednesday, 6/28, 9:00am
23 Drafting Committee Report, Kathy Chapman (4 hours)
24 Coffee Break 10:30
25 Drafting Committee Report Continuation
26 Lunch 12:00
27 Drafting Committee Report Continuation
28 Characters Proposal, Thom Linden (2 hours)
29 Break 3:00
30 Characters Proposal continuation
31 Adjournment 5:00pm
∂19-Jun-89 2113 X3J13-mailer registration list
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Jun 89 21:13:10 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA00885g; Mon, 19 Jun 89 21:11:24 PDT
Received: by challenger id AA12778g; Mon, 19 Jun 89 21:10:27 PDT
Date: Mon, 19 Jun 89 21:10:27 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906200410.AA12778@challenger>
To: x3j13@sail.stanford.edu
Subject: registration list
X3J13 Attendee Information
06/19/89
Name Institute Paid L1 L2 L3
Kim Barrett -0- -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Kathy Chapman DEC -0- - - -
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI -0- y y y
Jim Kempf Sun MicroSystems -0- y y y
Gregor Kiczales Xerox Corp. -0- y y y
Kerry Kimbrough -0- -0- - - -
Timothy Koschmann Southern Illinois -0- y y y
Aaron Larson Honeywell 80.00 y y y
Ray Lim NASA Ames -0- - - -
David Loeffler MCC 80.00 y y y
Sandra Loosemore University of Utah -0- y y y
Robert Mathis CONTEL -0- y y y
Dan Pierson Encore Computer -0- y y y
Guy Steele Thinking Machines -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂20-Jun-89 0753 X3J13-mailer June Agenda DRAFT
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 20 Jun 89 07:53:31 PDT
Received: from fafnir.think.com by Think.COM; Tue, 20 Jun 89 10:54:07 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 20 Jun 89 10:52:33 EDT
Received: from joplin.think.com by verdi.think.com; Tue, 20 Jun 89 10:52:27 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Tue, 20 Jun 89 10:52:24 EDT
Date: Tue, 20 Jun 89 10:52:24 EDT
Message-Id: <8906201452.AA09127@joplin.think.com>
To: jlz@lucid.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Mon, 19 Jun 89 21:09:18 PDT <8906200409.AA12775@challenger>
Subject: June Agenda DRAFT
I guess I am a bit startled not to see on the agenda some time
to consider the cleanup issues that were explicitly deferred in March
for resolution in June.
--Guy
∂20-Jun-89 0845 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Jun 89 08:45:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613697; 20 Jun 89 11:47:33 EDT
Date: Tue, 20 Jun 89 11:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES
To: Barry Margolin <barmar@Think.COM>
cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <19890619234721.3.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890620154813.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 19 Jun 89 19:47 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 19 Jun 89 18:36 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I reviewed the list for things I felt should be deleted, and did
not find any except for:
...
describe
Since Genera DOES return an extra value from DESCRIBE, I'm surprised you
think this one should be deleted. I happen to like Genera's behavior.
You're right, I made a mistake listing DESCRIBE for deletion.
Is anyone keeping a count of the number of functions being proposed to
allow extra return values? Pretty soon we might want to change the
sense of the proposal....
I think if you looked at the total number of functions, macros, and
special forms in ANSI CL, you wouldn't say that.
∂20-Jun-89 0901 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from pineapple.bbn.com by SAIL.Stanford.EDU with TCP; 20 Jun 89 09:01:42 PDT
Received: by pineapple.bbn.com
id <AA01749@pineapple.bbn.com>; Tue, 20 Jun 89 11:17:35 -0400
Date: Tue, 20 Jun 89 11:17:35 -0400
From: Hunter Barr <barr@bbn.com>
Message-Id: <8906201517.AA01749@pineapple.bbn.com>
To: x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Mon, 19 Jun 89 19:47 EDT <19890619234721.3.BARMAR@OCCAM.THINK.COM>
Subject: Issue: EXTRA-RETURN-VALUES
I agree with Barry about DESCRIBE. Whenever I start work with a
non-Symbolics Lisp compiler, the first thing I put in my lisp-init
file is (DEFUN D (X) (DESCRIBE X) X). I need it more than ever when I
don't have Genera, since then I cannot mouse on the object in question.
______
HUNTER
∂20-Jun-89 1252 X3J13-mailer EXTRA-RETURN-VALUES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Jun 89 12:52:13 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA04447; Tue, 20 Jun 89 12:53:45 PDT
Message-Id: <8906201953.AA04447@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA04447; Tue, 20 Jun 89 12:53:45 PDT
From: chapman@aitg.enet.dec.com
Date: 20 Jun 89 15:51
To: x3j13@sail.stanford.edu
Subject: EXTRA-RETURN-VALUES
Issue: EXTRA-RETURN-VALUES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
10-MAR-89, Version 3 by Chapman
30-MAY-89, Version 4 by Pierson
20-JUN-89, Version 5 by Chapman
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
A function that is specified by the standard must return EXACTLY the number
of return values specified by the standard.
The following functions are explicited permitted to have additional
return values:
gethash
remhash
get-macro-character
get-dispatch-macro-character
read
read-preserving-whitespace
read-delimited-list
read-line
read-char
unread-char
peek-char
listen
read-char-no-hang
read-from-string
parse-integer
read-byte
write-to-string
prin1-to-string
princ-to-string
write-string
format
y-or-n-p
yes-or-no-p
open
rename-file
probe-file
directory
trace
untrace
apropos-list
describe
Rationale:
The reason is that additional arguments are visible to otherwise
portable programs. For instance, (multiple-value-call #'cons (floor x
y)) looks portable, but it will try to pass the wrong number of
arguments to CONS if FLOOR returns an extra value.
The order of the above list is by page number in CLtL.
Current Practice:
At least one implementation returns extra values for certain functions
not currently specified to return those values.
Adoption Cost:
Implementations and their associated documentation that now contain
functions that return extra values will have to change.
Benefits:
Programs will potentially become more portable.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
Pierson created the original list, Moon revised the list.
Moon says:
"The ones that I care the most about are gethash and read-line."
∂20-Jun-89 1307 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Jun 89 13:07:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613889; 20 Jun 89 15:00:07 EDT
Date: Tue, 20 Jun 89 15:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <19890619223643.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890620190039.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a revision of the message I sent yesterday. Sorry about all
the traffic on the big X3J13 list.
This would be acceptable if the following functions were added
to the list of exceptions. Does anyone object to these additions?
gethash
remhash
get-macro-character
get-dispatch-macro-character
read
read-preserving-whitespace
read-delimited-list
read-line
read-char
peek-char
listen
read-char-no-hang
read-from-string
parse-integer
read-byte
write-to-string
prin1-to-string
princ-to-string
write-string
format
y-or-n-p
yes-or-no-p
open
rename-file
probe-file
directory
trace
untrace
apropos-list
The order of the above list is by page number in CLtL. The criterion I
used in constructing this list was to add the hash table functions that
might do special things with keys and the functions that were
"obviously" missing from your list, namely the rest of the I/O functions
and the rest of the environment functions, omitting the ones that
clearly had no possible use for extra values.
The ones that I care the most about are gethash and read-line.
I know of real genuine, important uses for extra values in those.
If there is a design criterion that includes all the functions
listed in the proposal and excludes any of the functions I've
listed above, I for one can't figure out what it is. Nothing
was listed in the rationale section. Here is the rough criterion
that I proposed in March; the list in your proposal seems to bear
a faint resemblance to this, while not corresponding closely to
it. What was the criterion you derived from mine?
As a suggested rough cut at such a list, how about all the functions
described in chapters 16, 21, 22, 23, 24, and 25 of CLtL? These are
the functions that I would call "environment" rather than "language".
I reviewed the list for things I felt should be deleted, and found
these. The criterion for deleting these is that they are accessors
(which inherently return one value), restart functions (which don't
return at all, or return NIL), invoke-debugger (which never returns),
or setting functions, which return T and don't seem to need to return
anything else.
arithmetic-error-operands
arithmetic-error-operation
cell-error-name
continue
directory-namestring
invoke-debugger
invoke-restart
invoke-restart-interactively
muffle-warning
package-error-package
restart-name
set-dispatch-macro-character
set-macro-character
set-syntax-from-char
simple-condition-format-arguments
simple-condition-format-string
store-value
type-error-datum
type-error-expected-type
use-value
For extra clarity, here is my proposed revised list of operators that
can return extra values, which has 65 entries.
apropos
apropos-list
break
cerror
clear-input
clear-output
compile
compile-file
compute-restarts
delete-file
describe
directory
disassemble
dribble
ed
error
find-restart
finish-output
force-output
format
fresh-line
get-dispatch-macro-character
get-macro-character
gethash
inspect
listen
load
make-condition
open
parse-integer
peek-char
pprint
prin1
prin1-to-string
princ
princ-to-string
print
probe-file
read
read-byte
read-char
read-char-no-hang
read-delimited-list
read-from-string
read-line
read-preserving-whitespace
remhash
rename-file
room
signal
sleep
terpri
trace
unread-char
untrace
user-homedir-pathname
warn
write
write-byte
write-char
write-line
write-string
write-to-string
y-or-n-p
yes-or-no-p
Could we get a version of the proposal with these changes, or
are they controversial in any way?
∂20-Jun-89 1336 X3J13-mailer Issue: EXTRA-RETURN-VALUES (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Jun 89 13:36:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614033; 20 Jun 89 16:37:59 EDT
Date: Tue, 20 Jun 89 16:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES (version 5)
To: chapman@aitg.enet.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8906201953.AA04447@decwrl.dec.com>
Message-ID: <19890620203836.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 20 Jun 89 15:51
From: chapman@aitg.enet.dec.com
....
The following functions are explicited permitted to have additional
return values:
....
Discussion:
Pierson created the original list, Moon revised the list.
This is not the revised list that I suggested. What's the rationale
for the differences? I couldn't figure out how you decided, for
example, to include apropos-list but not apropos, trace but not ed,
write-string but not write.
∂20-Jun-89 1823 X3J13-mailer June Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Jun 89 18:23:20 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA03900g; Tue, 20 Jun 89 18:21:32 PDT
Received: by challenger id AA14563g; Tue, 20 Jun 89 18:20:34 PDT
Date: Tue, 20 Jun 89 18:20:34 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906210120.AA14563@challenger>
To: gls@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: Guy Steele's message of Tue, 20 Jun 89 10:52:24 EDT <8906201452.AA09127@joplin.think.com>
Subject: June Agenda DRAFT
I haven't heard that the clean-up committe yet.
---jan---
∂20-Jun-89 2235 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Jun 89 22:35:11 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05498g; Tue, 20 Jun 89 22:33:25 PDT
Received: by bhopal id AA04536g; Tue, 20 Jun 89 22:35:42 PDT
Date: Tue, 20 Jun 89 22:35:42 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8906210535.AA04536@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: X3J13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 13 Jun 89 19:17 EDT <19890613231714.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
re: Clarifications and Logical Consequences:
. . .
b. There is no specified way to create an array that is non-simple.
c. The definition of SIMPLE-ARRAY on p.28 is taken to be an implication,
not an equivalence. This is either a clarification or a change
depending on one's prior reading of that definition.
This is exactly the same flaw (and the only one!) that I've been pointing
out every time someone has tried to rewrite this proposal. Namely, what
is alleged to be a proposal to fix a minor annoyance about the function
ADJUST-ARRAY turns out to be a proposal that removes the portability of
the type SIMPLE-ARRAY.
Throughout all the thousands and thousands of lines of commentary on this
topic, I've yet to see one that justified breaking the portability of
SIMPLE-ARRAY. Fixing ADJUST-ARRAY as outlined in the proposal is an OK
thing to do, but it doesn't by itself require breaking types [In fact, I
supported Kent's long-lost proposal that called for ADJUST-ARRAY to work
like DELETE, returning a copy when it couldn't alter the array "in
place". I had hoped that the :adjustable option to MAKE-ARRAY would
thus acquire the meaning "adjustable in place".]
Since it is so critically important for stock hardware implementations
to have some way to DECLARE implementational properties about subclasses
of arrays, in order to do optimizations on AREF etc based on the morphology
of the object, then I doubt that any such vendor will give up use of the
type SIMPLE-ARRAY, merely to mimic a deficiency in one of the special-purpose
vendor's implementations. [Sure there could have been other ways to achieve
this end -- other than special-purpose hardware -- but the type system is the
one that CLtL chose, and the *** definition *** of that type on page 28 is
the important one.]
Rather, the consequence of this proposal is merely to make that very
common, standard practice be "non standard" -- that is, it is no longer
guaranteed that programs which depend on the type SIMPLE-ARRAY will work
the same when moved from one implementation to another. Note: this *isn't*
saying that all such programs will break -- only that some reasonable ones
will either break or work differently. Consider for example the trivial:
(typep (make-array 5 :adjustable t) 'simple-array)
If I read the proposal correctly, it would explicitly permit this
to return true, instead of false.
Such a change isn't mitigated by the fact that some types have always
been non-portable -- e.g. FIXNUM -- but we have generally acted to
reduce the variations rather than increase them. Consider why, for
example, the types NUMBER and CHARACTER are portable:
(typep (int-char 100) 'number)
(typep (char-int #\A) 'character)
are false in every implementation (and CLtL guarantees this by the
clear proscription on page 33.)
But CLtL permits READTABLEs to be implemented as simple general vectors;
so the type READTABLE wasn't portable until after passing the CLOS-inspired
resolution that guaranteed a lot more pairwise disjointness. This, I
believe, is the better direction in which to move -- reducing non-
portability rather than increasing it.
-- JonL --
∂21-Jun-89 1035 X3J13-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 10:35:19 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 JUN 89 10:30:47 PDT
Date: 21 Jun 89 10:30 PDT
From: masinter.pa@Xerox.COM
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
to: x3J13@sail.stanford.edu
Message-ID: <890621-103047-17283@Xerox>
I don't yet even have an estimate of how much cleanup material
there is for this meeting.
We passed version 4 of SUBTYPEP-TOO-VAGUE at the January meeting, Guy
produced version 5 in March, but that we didn't discuss version 5, postpone
version 5, or otherwise deal with version 5 at the March meeting. I think
this one fell between the cracks...
David Moon says:
"I never studied this issue really
carefully but version 5 was okay with me, more or less. It's still a bit
bogus because an implementation could define all type specifiers as
expansions into SATISFIES, in which case SUBTYPEP could return NIL NIL
always. I suspect the proposal was intended to rule that out, but the
actual words that it says fail to rule that out.
"
!
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Version 5, 15-Mar-89 Steele
Problem Description:
[From version 4]
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
[Addition for version 5]
There are two problems with version 4. First is that of the first three
bulleted points in the version 4 proposal:
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.
Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP. These are cases that returning NIL NIL
was supposed to cover.
This version replaces the three bulleted points above with a single point
and some observations about its consequences. This version eliminates
the requirement to signal an error.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP is permitted to return NIL NIL only when
at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
VALUES, or the list form of FUNCTION.
Note that one consequence of this is that if neither argument
involves any of these type specifiers, then SUBTYPEP is obliged
to determine the relationship accurately. In particular, SUBTYPEP
must return T T if the arguments are EQUAL and do not involve
any of the above-stated type specifiers.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
----- End Forwarded Messages -----
∂21-Jun-89 1042 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 10:42:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUN 89 10:37:57 PDT
Date: 21 Jun 89 10:37 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
To: x3J13@sail.stanford.edu
Message-ID: <890621-103757-17307@Xerox>
This issue was deferred from March. Kent Pitman and David Moon
have prepared this revised writeup. Additional comments are
at the end...
!
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Related-issues: PATHNAME-COMPONENT-CASE, PATHNAME-COMPONENT-VALUE
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
22-Mar-89, Version 4 by Moon (fix based on discussion)
19-May-89, Version 5 by Moon (improve based on mail)
21-May-89, Version 6 by Moon (final cleanups)
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of the pathname abstraction.
According to CLtL, only a string is a portable value for the directory
component of a pathname. Thus in order to denote a subdirectory, the use
of punctuation characters (such as dots, slashes, or backslashes) would
be necessary. The very fact that such syntax varies from host to host
means that although the representation might be "portable", the code
using that representation is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus different subdirectory punctuation.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO", while in other implementations it would denote a top-level
directory, because "." is not treated as punctuation. To be safe,
portable programs must avoid all potential punctuation characters.
- Even in implementations where "." is used for subdirectories,
"FOO.BAR" may be recognized by some to mean the "BAR" subdirectory of
"FOO" and by others to mean `a seven character directory name with "."
as the fourth character.'
- In fact, CLtL does not even say whether punctuation characters are
part of the string. eg, is "foo" or "/foo" the directory component for
a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the
directory component for a VMS pathname "[FOO]ME.LSP"?
PATHNAME-COMPONENT-VALUE:SPECIFY says punctuation characters are not
part of the string.
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Remove the "structured" directory feature mentioned on CLtL p.412.
Allow the value of a pathname's directory component to be a list. The
car of the list is one of the symbols :ABSOLUTE or :RELATIVE.
Each remaining element of the list is a string or a symbol (see below).
Each string names a single level of directory structure. The strings
should contain only the directory names themselves -- no punctuation
characters.
A list whose car is the symbol :ABSOLUTE represents a directory path
starting from the root directory. The list (:ABSOLUTE) represents
the root directory. The list (:ABSOLUTE "foo" "bar" "baz") represents
the directory called "/foo/bar/baz" in Unix [except possibly for
alphabetic case -- that is the subject of a separate issue].
A list whose car is the symbol :RELATIVE represents a directory path
starting from a default directory. The list (:RELATIVE) has the same
meaning as NIL and hence is not used. The list (:RELATIVE "foo" "bar")
represents the directory named "bar" in the directory named "foo" in the
default directory.
In place of a string, at any point in the list, symbols may occur to
indicate special file notations. The following symbols have standard
meanings. Implementations are permitted to add additional objects of any
non-string type if necessary to represent features of their file systems
that cannot be represented with the standard strings and symbols.
Supplying any non-string, including any of the symbols listed below, to a
file system for which it does not make sense signals an error of type
FILE-ERROR. For example, Unix does not support :WILD-INFERIORS.
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
"Syntactic" means that the action of :BACK depends only on the pathname
and not on the contents of the file system. "Semantic" means that the
action of :UP depends on the contents of the file system; to resolve
a pathname containing :UP to a pathname whose directory component
contains only :ABSOLUTE and strings requires probing the file system.
:UP differs from :BACK only in file systems that support multiple
names for directories, perhaps via symbolic links. For example,
suppose that there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :BACK "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
If a string is used as the value of the :DIRECTORY argument to
MAKE-PATHNAME, it should be the name of a toplevel directory and should
not contain any punctuation characters. Specifying a string, str, is
equivalent to specifying the list (:ABSOLUTE str). Specifying the symbol
:WILD is equivalent to specifying the list (:ABSOLUTE :WILD-INFERIORS),
or (:ABSOLUTE :WILD) in a file system that does not support :WILD-INFERIORS.
The PATHNAME-DIRECTORY function always returns NIL, :UNSPECIFIC, or a
list, never a string, never :WILD.
In non-hierarchical file systems, the only valid list values for the
directory component of a pathname are (:ABSOLUTE string) and
(:ABSOLUTE :WILD). :RELATIVE directories and the keywords
:WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file
systems.
Pathname merging treats a relative directory specially. Let
<pathname> and <defaults> be the first two arguments to
MERGE-PATHNAMES. If (PATHNAME-DIRECTORY <pathname>) is a list whose
car is :RELATIVE, and (PATHNAME-DIRECTORY <defaults>) is a list, then
the merged directory is the value of
(APPEND (PATHNAME-DIRECTORY <defaults>)
(CDR ;remove :RELATIVE from the front
(PATHNAME-DIRECTORY <pathname>)))
except that if the resulting list contains a string or :WILD immediately
followed by :BACK, both of them are removed. This removal of redundant
:BACKs is repeated as many times as possible.
If (PATHNAME-DIRECTORY <defaults>) is not a list or
(PATHNAME-DIRECTORY <pathname>) is not a list whose car is :RELATIVE, the
merged directory is
(OR (PATHNAME-DIRECTORY <pathname>) (PATHNAME-DIRECTORY <defaults>))
A relative directory in the pathname argument to a function such as
OPEN is merged with *DEFAULT-PATHNAME-DEFAULTS* before accessing the
file system.
Test Cases/Examples:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT passes with a default of
:COMMON, the value is the second one shown.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "../baz.lisp")) ;on Unix
=> (:RELATIVE :UP)
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/../mum/baz")) ;on Unix
=> (:ABSOLUTE "foo" "bar" :UP "mum")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file
systems, which are by far the most common file system type.
This would allow a system construction utility that organizes programs
by subdirectories to be portable to all implementations that have
hierarchical file systems.
Discussion indicated that "Implementations are permitted to add
additional objects of any non-string type if necessary to represent
features of their file systems that cannot be represented with the
standard strings and symbols" is a necessary escape hatch for things like
home directories and fancy pattern matching. Implementations should
limit their use of this loophole and use the standard keyword symbols
whenever that is possible.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera has no separate concepts of :UP and :BACK. Genera
represents Unix ".." as :UP, but deals with :UP syntactically, not
semantically.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory component by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
Implementations such as Genera that already have hierarchical directory
handling will have to make an incompatible change to switch to what
is proposed here.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None for portable programs. This change is upward compatible with CLtL.
Nonportable programs will have to be changed if they use implementation
dependent hierarchical directory handling and the implementation
removes support for that when it adds support for this proposal.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES component to a
pathname, was discarded because it imposed an unnatural distinction
between a toplevel directory and its subdirectories. Pitman's guess is
the the idea was to try to make it a compatible change, but since most
programmers will probably want to change from implementation-specific
primitives to portable ones anyway, that's probably not such a big
deal. Also, there could have been some programs which thought the
change was compatible and ended up ignoring important information (the
:SUBDIRECTORIES component). Pitman thought it would be better if
people just accepted the cost of an incompatible change in order to
get something really pretty as a result.
Moon doesn't like having both :UP and :BACK, but admits that some
file systems do it one way and some do it the other. He still thinks
it would be simpler not to have both.
To keep it simple, we chose not to add to this issue the functions
DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert
the name of a directory from or to the directory component of a file
inferior to that directory. This conversion is system-dependent, for
example TOPS-20 appends a type field and Unix does not. Also in some
systems the root directory has a name and in others it doesn't. Of
course these functions signal an error in non-hierarchical file
systems. Examples (for Unix, assuming #P print syntax for pathnames):
(directory-pathname-as-file #P"/usr/bin/sh") => #P"/usr/bin"
(pathname-as-directory #P"/usr/bin") => #P"/usr/bin"/
These functions have not been proposed because they are mainly useful
in conjunction with additional functions for manipulating directories
(creating, expunging, setting access control) that have not been made
available in Common Lisp.
!
Additional Comments
"The comments I made on issue PATHNAME-COMPONENT-VALUE also apply here.
In particular, I'm not personally motivated to add such a feature
because I've never had any need to manipulate hierarchical directories
from within a Common Lisp program. Any program that does so is
necessarily nonportable."
"I'm sorry, but I disagree with your last sentence. A program that
*insists* on using hierarchical directories may be nonportable,
but a program that is *prepared* to deal with them if the local
file system happens to contain them is not necessarily nonportable,
and indeed may me more portable than a program thast insists on
dealing with directories in a nonhierarchical manner."
"Yes. For current practice, IIM does something similar. The keywords are
different, and only :BACK supported. I believe the keyword mapping is
:ABSOLUTE :ABSOLUTE-DIRECTORY
:RELATIVE (no leading keyword)
:BACK :SUPER-DIRECTORY
The addition of the :RELATIVE keyword is probably cleaner, since it means that
there is always a keyword at the head of the list, and a test for a relative
directory is (eq (car directory) :relative) rather than something like
(and directory (not (symbolp (car directory)))).
The interaction between :BACK and :WILD-INFERIORS doesn't seem clear. I
believe this is a case where :BACK and the thing preceding it cannot be
spliced out (you can end up with (... :WILD-INFERIORS :BACK ...). Also,
(:ABSOLUTE :BACK ...) should probably signal an error."
∂21-Jun-89 1059 X3J13-mailer Issue: PATHNAME-WILD (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 10:59:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 JUN 89 10:51:15 PDT
Date: 21 Jun 89 10:50 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-WILD (version 5)
To: x3j13@sail.stanford.edu
Message-ID: <890621-105115-17348@Xerox>
This issue was deferred from the last meeting. There has been quite
a bit of discussion on this proposal, especially about what
TRANSLATE-PATHNAME does and is why, and some comments on whether
DELETE-FILE might accept wildcard pathnames.
(Discussion not summarized.)
!
Issue: PATHNAME-WILD
References: Pathnames (pp410-413)
Related issues: PATHNAME-LOGICAL
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
9-May-89, Version 3 by Moon (small fixes)
10-May-89, Version 4 by Moon (add two more functions)
13-May-89, Version 5 by Moon (minor cleanups, add clarification)
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards (:WILD). For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
Some file systems support even more complex wildcards, for example
regular expressions.
The CL pathname model does not specify a way to represent complex
wildcards, which means, for example, that (MAKE-PATHNAME :NAME "F*O")
cannot be recognized by portable code as containing a wildcard.
Common Lisp provides only the first of these four common operations
on wildcard pathnames:
(1) Enumerate the set of existing files that match the pathname;
this is provided by the DIRECTORY function.
(2) Test whether a pathname contains wildcards.
(3) Test whether a pathname matches a wildcard pathname.
(4) Translate one pathname into another according to a mapping specified
by a pair of wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTIONS):
Introduce the following three functions:
WILD-PATHNAME-P pathname &optional field-key
Tests a pathname for the presence of wildcard components. If the first
argument is not a pathname, string, or file stream an error of type
TYPE-ERROR is signalled.
If no <field-key> is provided, or the <field-key> is NIL, the result is
T if <pathname> has any wildcard components, NIL if <pathname> has none.
If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, the result is T
if the indicated component of <pathname> is a wildcard, NIL if the
component is not a wildcard.
PATHNAME-MATCH-P pathname wildcard
T if <pathname> matches <wildcard>, otherwise NIL. The matching rules
are implementation-dependent but should be consistent with the
DIRECTORY function. Missing components of <wildcard> default to :WILD.
If either argument is not a pathname, string, or file stream an error
of type TYPE-ERROR is signalled. It is valid for <pathname> to be a
wild pathname. It is valid for <wildcard> to be a non-wild pathname.
TRANSLATE-PATHNAME source from-wildcard to-wildcard &optional reversible
Translate the pathname <source> according to the correspondence between
the two wildcard pathnames. This translation is implementation
dependent. The result is <to-wildcard> with each missing or wildcard
field replaced by the portion of <source> that matches the corresponding
field (usually a wildcard) in <from-wildcard>. Additional translations
of alphabetic case or file naming conventions might also occur,
especially when from-wildcard and to-wildcard are for different hosts.
If <reversible> is false, the translation is determined by the user
interface conventions of the file systems involved. If <reversible> is
true, the translation must instead be reversible, that is, the
following identity must hold for all cases where no error is signalled:
(equal (translate-pathname (translate-pathname pathname from to t)
to from t)
pathname)
In some file systems the above identity is true only when
(member (pathname-version pathname) '(:newest :unspecific)).
This is considered valid, as Common Lisp cannot force all the
file systems in the world to implement versions.
In some file systems the <reversible> argument is ignored because the
user interface conventions are reversible anyway.
If any of the first three arguments is not a pathname, string, or file
stream an error of type TYPE-ERROR is signalled. It is valid for
<source> to be a wild pathname; in general this will produce a wild
result. It is valid for <from-wildcard> and/or <to-wildcard> to be
non-wild pathnames. (PATHNAME-MATCH-P <source> <from-wildcard>) must
be true or an error is signalled.
Implementation guideline: one typical file system performs this
operation by examining each field of the pathnames in turn, where a
field is a component or an element of a structured component such as a
hierarchical directory. Hierarchical directory elements in
<from-wildcard> and <to-wildcard> are matched by whether they are
wildcards, not by depth in the directory hierarchy. If the field in
<from-wildcard> does not match the field in <source>, an error is
signalled. If the field in <to-wildcard> is present and not wild, it
is copied into the result. If the field in <to-wildcard> is :WILD or
NIL, and either <reversible> is false or the field in <from-wildcard>
is not a complex wildcard, the field in <source> is copied into the
result. Otherwise, the field in <to-wildcard> might be a complex
wildcard such as "foo*bar" and the field in <from-wildcard> should be
wild; the portion of the field in <source> that matches the wildcard
portion of the field in <from-wildcard> fills in the wildcard portion
of the field in <to-wildcard> and the field value produced is used in
the result.
Clarify that the functions OPEN (and WITH-OPEN-FILE), RENAME-FILE,
DELETE-FILE, PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD,
COMPILE-FILE, and TRUENAME only accept non-wildcard pathnames and signal
an error if given a pathname for which WILD-PATHNAME-P returns true.
Examples:
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
(WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
(WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
;This example assumes one particular set of wildcard conventions
;Not all file systems will run this example exactly as written
(DEFUN RENAME-FILES (FROM TO)
(DOLIST (FILE (DIRECTORY FROM))
(RENAME-FILE FILE (TRANSLATE-PATHNAME FILE FROM TO))))
(RENAME-FILES "/usr/me/*.lisp" "/dev/her/*.l")
;Renames /usr/me/init.lisp to /dev/her/init.l
(RENAME-FILES "/usr/me/pcl*/*" "/sys/pcl/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp
;In some file systems the result might be /sys/pcl/5-may/low.lisp
(RENAME-FILES "/usr/me/pcl*/*" "/sys/library/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp
;In some file systems the result might be /sys/library/5-may/low.lisp
(RENAME-FILES "/usr/me/foo.bar" "/usr/me2/")
;Renames /usr/me/foo.bar to /usr/me2/foo.bar
;This example assumes one particular set of wildcard conventions and
;illustrates how and why reversible translation uses different rules
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" NIL)) => "barbaz"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" T)) => "barbaz"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*" NIL)) => "foobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*" T)) => "bar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*" "foo*" NIL)) => "foofoobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*" "foo*" T)) => "foofoobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "bar" "*" "foo*" NIL)) => "foobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "bar" "*" "foo*" T)) => "foobar"
;This example presumes background information described in PATHNAME-LOGICAL
(DEFUN TRANSLATE-LOGICAL-PATHNAME-1 (PATHNAME RULES)
(LET ((RULE (ASSOC PATHNAME RULES :TEST #'PATHNAME-MATCH-P)))
(UNLESS RULE (ERROR "No translation rule for ~A" PATHNAME))
(TRANSLATE-PATHNAME PATHNAME (FIRST RULE) (SECOND RULE) T)))
(TRANSLATE-LOGICAL-PATHNAME-1 "FOO:CODE;BASIC.LISP"
'(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")
("FOO:CODE;" "MY-UNIX:/lib/foo/")
("FOO:PATCHES;*;" "MY-UNIX:/lib/foo/patch/*/")))
=> the pathname MY-UNIX:/lib/foo/basic.l
Rationale:
These three functions provide a standardized interface to the
idiosyncratic wildcard functionality of each host file system.
WILD-PATHNAME-P makes it possible to detect wild pathnames reliably and
do something useful (give up, merge out the bothersome components, call
DIRECTORY for a list of matching pathnames, etc.)
TRANSLATE-PATHNAME is needed by many application programs that deal with
wildcard pathnames. PATHNAME-MATCH-P and TRANSLATE-PATHNAME are needed
by logical pathnames. The reversible feature is needed by logical
pathnames.
Current Practice:
Presumably no implementation supports the proposal exactly as stated.
Symbolics Genera has had similar features under different names for many
years:
(SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
etc., indicating the first wild field.
(SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
etc. test individual fields.
The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
:PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
PATHNAME-MATCH-P.
The clarification is current practice as far as the authors are aware.
If some implementations are found that specify a meaning for wildcard
pathnames as arguments to these functions, this proposal should be changed
to say that the consequences are unspecified rather than signalling an error.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcards to write it.
Since the detailed behavior is at the implementor's discretion, the cost
is unlikely to be large. Some file systems will do all the work and the
implementor need only provide an interface to the file system or to a
standard library routine. For other file systems the implementor has to
write the actual matching and translation algorithms.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
many situations. User programs that deal with wildcard pathnames would
have to operate on implementation-dependent representations and hence
would not be easily portable.
The biggest cost is that any logical pathnames proposal would be stymied.
Performance Impact:
None.
Benefits:
A more complete set of wildcard pathname operations. Portable user
programs that deal with wildcard pathnames will be more consistent
and reliable. A portable system construction tool can be written
and the foundations are laid for a `logical pathname' facility
(proposed separately in PATHNAME-LOGICAL).
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
There was some question about the name. The name PATHNAME-WILD-P
suggests a ``slot'' of a pathname (like PATHNAME-HOST),
while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
The committee was split on what to call it. Since it is more
like a type than a slot, the name WILD-PATHNAME-P was chosen.
∂21-Jun-89 1129 X3J13-mailer issue DYNAMIC-EXTENT-FUNCTION, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 11:29:47 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 JUN 89 11:23:58 PDT
Date: 21 Jun 89 11:23 PDT
From: masinter.pa@Xerox.COM
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 2
To: x3j13@sail.stanford.edu
Message-ID: <890621-112358-17463@Xerox>
This issue was postponed from the last meeting...
!
Forum: CLEANUP
Issue: DYNAMIC-EXTENT-FUNCTION
References: Scope and Extent
Issue DYNAMIC-EXTENT
Category: ADDITION
Edit history: 04-Apr-89, Version 1 by Loosemore
11-Jun-89, Version 2 by Loosemore
Problem Description:
Proposal DYNAMIC-EXTENT:NEW-DECLARATION, passed at the March 89
meeting, provides a mechanism for declaring that the values of
variables have only dynamic (rather than indefinite) extent. It
would be useful to have similar functionality to indicate that
functional bindings may have only dynamic extent. (For example,
this would permit compilers to stack-allocate closures.)
Proposal (DYNAMIC-EXTENT-FUNCTION:EXTEND):
Extend the DYNAMIC-EXTENT declaration to accept arguments that are
lists of the form (FUNCTION <name>) where <name> is a function name,
as well as symbols.
A (FUNCTION <name>) list appearing in a DYNAMIC-EXTENT declaration is
used to declare that the lexically visible functional binding of <name>
has dynamic extent. Except for the interpretation of <name> as the
name of a function instead of the name of a variable, such a declaration
otherwise has semantics that are identical to those already described
in proposal DYNAMIC-EXTENT:NEW-DECLARATION.
Rationale:
This permits a programmer to offer advice to an implementation about
what functions may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Current Practice:
JonL says that Lucid's compiler can stack-allocate closures, but they
have no mechanism for programmers to give the compiler permission to
do so.
HPCL-I has an UPWARD-CLOSURES declaration that pervasively affects
all closures created within the scope of the declaration.
The Symbolics Genera compiler can often infer when functions can be
implemented to have dynamic extent. Also, if a function has a
SYS:DOWNWARD-FUNCTION declaration in front of its body, then the
function is implemented with dynamic extent regardless of whether
the compiler thinks all uses are "downward". (This declaration is
rather peculiar because its scope is actually larger than the lambda
expression containing the declaration; implementationally, it's the
surrounding function definition.)
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
Loosemore supports DYNAMIC-EXTENT-FUNCTION:EXTEND.
This proposal does not attempt to address the issue of specifying
dynamic extent for anonymous closures (which is really a special case
of the more general problem of specifying dynamic extent for unnamed
objects of any type). It's possible, although often awkward, to
restructure the program to give the object a name and explicitly
identify its extent.
One possible solution to the problem of dynamic extent for anonymous
lambdas would be to clarify that a reference to a closed-over variable
or function appearing lexically within a FUNCTION form is enough to
cause its value to be "saved" when the FUNCTION form is executed,
regardless of whether or not that reference is actually executed when
the resulting function is called. Then, if all of the closed-over
functions and variables referenced within a closure are declared to
have dynamic extent, the closure could be assumed to have dynamic
extent as well. (More precisely, its maximum extent would be the
intersection of the extents of the closed-over functions and
variables.)
∂21-Jun-89 1506 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:06:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 614524; 21 Jun 89 13:01:57 EDT
Date: Wed, 21 Jun 89 13:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: Jon L White <jonl@lucid.com>
cc: X3J13@sail.stanford.edu
In-Reply-To: <8906210535.AA04536@bhopal>
Message-ID: <19890621170228.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 20 Jun 89 22:35:42 PDT
From: Jon L White <jonl@lucid.com>
....turns out to be a proposal that removes the portability of
the type SIMPLE-ARRAY.
Haven't we been over and over and over this already? No portability is
removed.
....Since it is so critically important for stock hardware implementations
to have some way to DECLARE implementational properties about subclasses
of arrays, in order to do optimizations on AREF etc based on the morphology
of the object, then I doubt that any such vendor will give up use of the
type SIMPLE-ARRAY....
There is nothing in the proposal that would require, encourage, or
suggest any vendor to do any such thing. None of us want to remove that
capability from stock hardware implementations. I think you are simply
misreading what the proposal says. We spent an enormous amount of time
in private discussions making sure that the proposal would not do what
you are accusing it of doing. Please read the proposal again with an
open mind, not biased by earlier versions of the proposal.
Rather, the consequence of this proposal is merely to make that very
common, standard practice be "non standard" -- that is, it is no longer
guaranteed that programs which depend on the type SIMPLE-ARRAY will work
the same when moved from one implementation to another. Note: this *isn't*
saying that all such programs will break -- only that some reasonable ones
will either break or work differently. Consider for example the trivial:
(typep (make-array 5 :adjustable t) 'simple-array)
If I read the proposal correctly, it would explicitly permit this
to return true, instead of false.
That is correct. How does that break any program? How does that force
any vendor to change their implementation? I do not believe that there
is any program that works in any implementation that will stop working
in that implementation as a result of this proposal. I think if you
read carefully what the proposal actually says, not biased by earlier
versions of the proposal, you will agree with me in that conclusion.
∂21-Jun-89 1507 X3J13-mailer Issue: PATHNAME-LOGICAL (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:06:31 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 614486; 21 Jun 89 12:20:55 EDT
Date: Wed, 21 Jun 89 12:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Reply-To: CL-Cleanup@sail.stanford.edu
Subject: Issue: PATHNAME-LOGICAL (version 3)
To: X3J13@sail.stanford.edu
Message-ID: <19890621161905.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is an old issue but it has not been written up before. I'm sorry this
is coming out so late, but it's been quite a struggle to cast it into clear
and easily understood form. It is rather a long proposal in order to be
very clear about exactly what it's proposing, and I apologize for the
length.
Issue: PATHNAME-LOGICAL
Forum: Cleanup
References: Pathnames (pp410-413)
OPEN (p.418), WITH-OPEN-FILE (p.422), RENAME-FILE (p.423),
DELETE-FILE (p.424), PROBE-FILE (p.424),
FILE-WRITE-DATE (p.424), FILE-AUTHOR (p.424), LOAD (p.426),
COMPILE-FILE (p.439), DIRECTORY (p.427), PATHNAME (p.413),
TRUENAME (p.413), MERGE-PATHNAMES (p.415),
MAKE-PATHNAME (p.416), and PARSE-NAMESTRING (p.414).
Related issues: PATHNAME-CANONICAL-TYPE, PATHNAME-COMPONENT-VALUES,
PATHNAME-SUBDIRECTORY-LIST, and PATHNAME-WILD
Category: ADDITION
Edit history: Version 1, 11-May-89, by Moon
Version 2, 18-May-89, by Moon
Version 3, 21-Jun-89, by Moon (revise based on discussion
in the cleanup committee)
Problem description:
Pathname values are not portable, but they are sometimes part of a
program, for example the names of files containing the program and the
data used by the program. Moving large programs between sites would
be easier if pathname values did not have to be translated.
Pathname values are nonportable because not all Common Lisp
implementations use the same operating system and file name syntax varies
widely among operating systems. In addition, corresponding files at two
different sites may have different names even when the operating system
is the same; for example, they may be on different directories or
different devices.
The issue of portable pathname values is separate from the issues of
portable pathname operations. See the related issues listed above.
For inter-issue interactions, see the discussion section below.
Note that issue PATHNAME-LOGICAL fundamentally depends on issue
PATHNAME-WILD. If PATHNAME-WILD:NEW-FUNCTIONS does not pass,
PATHNAME-LOGICAL cannot pass.
Proposal (PATHNAME-LOGICAL:ADD):
1. Define a "logical" file system that looks the same at every site.
This file system is implemented by translating each logical pathname into
a physical pathname on a real file system. The logical pathnames are the
same at all sites, but the translations are different at each site, thus
the physical pathnames can be different at each site.
2a. The syntax of a logical pathname namestring is as follows:
[ host ":" ] [ ";" ] { directory ";" }* [ name ] [ "." type [ "." version ]]
2b. Terminology:
A <word> consists of one or more uppercase letters, digits, and hyphens.
A <wildcard word> consists of one or more asterisks, uppercase letters,
digits, and hyphens, including at least one asterisk, with no two
asterisks adjacent. Each asterisk matches a sequence of zero or more
characters. The <wildcard word> "*" parses into :WILD, the others parse
into strings.
In <words> and <wildcard words> lowercase letters are translated to
uppercase. The consequences of using other characters are unspecified.
2c. Logical pathname components:
The host is a <word> that has been defined as a logical pathname host by
using SETF of LOGICAL-PATHNAME-TRANSLATIONS.
There is no device, so the device component of a logical pathname is
always :UNSPECIFIC. No other component can be :UNSPECIFIC.
Each directory is a <word>, a <wildcard word>, or "**" (:WILD-INFERIORS).
If a semicolon precedes the directories, the directory component is
relative, otherwise it is absolute.
The name is a <word> or a <wildcard word>.
The type is a <word> or a <wildcard word>.
The version is a positive decimal integer or "NEWEST" (:NEWEST) or "*"
(:WILD). The letters in "NEWEST" can be in either alphabetic case.
The consequences of using any value not specified here as a logical
pathname component are unspecified.
The null string "" is not a valid value for any component of a logical
pathname, since "" is not a <word> and not a <wildcard word>.
3. Parsing of logical pathname namestrings into logical pathnames
operates as follows:
3a. Logical pathname namestrings are recognized by the LOGICAL-PATHNAME
and TRANSLATE-LOGICAL-PATHNAME functions. In this case the host portion
of the logical pathname namestring and its following colon are required.
3b. The PARSE-NAMESTRING function recognizes a logical pathname
namestring when the host argument is logical or the defaults argument is
a logical pathname. In this case the host portion of the logical
pathname namestring and its following colon are optional. If the host
portion of the namestring and the host argument are both present and do
not match, an error is signalled.
The host argument is logical if it is supplied and came from
PATHNAME-HOST of a logical pathname. Whether a host argument is logical
if it is a string equal to a logical pathname host name is
implementation-defined.
3c. The MERGE-PATHNAMES function recognizes a logical pathname namestring
when the defaults argument is a logical pathname. In this case the host
portion of the logical pathname namestring and its following colon are
optional.
3d. Whether the other functions that coerce strings to pathnames
(PATHNAME, TRUENAME, PARSE-NAMESTRING in other circumstances than those
described in point 3b, MERGE-PATHNAMES in other circumstances than those
described in point 3c, the :DEFAULTS argument to MAKE-PATHNAME,
PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME,
PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING, FILE-NAMESTRING,
DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING, OPEN,
WITH-OPEN-FILE, RENAME-FILE, DELETE-FILE, PROBE-FILE, FILE-WRITE-DATE,
FILE-AUTHOR, LOAD, DIRECTORY, COMPILE-FILE, ED, DRIBBLE, WILD-PATHNAME-P,
PATHNAME-MATCH-P, TRANSLATE-PATHNAME, and COMPILE-FILE-PATHNAME)
recognize logical pathname namestrings is implementation defined.
4. Some real file systems do not have versions. Logical pathname
translation to such a file system ignores the version. This implies that
a program cannot rely on being able to store more than one version of a
file named by a logical pathname.
5. The type of a logical pathname for a Common Lisp source file is "LISP".
This should be translated into whatever type is appropriate in a physical
pathname.
6. The logical pathname host name "SYS" is reserved for the implementation.
The existence and meaning of SYS: logical pathnames is
implementation-defined.
7. File manipulation functions operate with logical pathnames as follows:
7a. The functions OPEN (and WITH-OPEN-FILE), RENAME-FILE, DELETE-FILE,
PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD, DIRECTORY, COMPILE-FILE,
ED, DRIBBLE, COMPILE-FILE-PATHNAME, and TRUENAME accept logical pathnames
and translate them into physical pathnames, as if by calling the
TRANSLATE-LOGICAL-PATHNAME function.
7b. PATHNAME of a stream created by OPEN (or WITH-OPEN-FILE) of a logical
pathname is a logical pathname.
7c. TRUENAME, PROBE-FILE, and DIRECTORY never return logical pathnames.
7d. RENAME-FILE with a logical pathname as the second argument returns a
logical pathname as the first value.
7e. MERGE-PATHNAMES returns a logical pathname if and only if its first
argument is a logical pathname or its first argument does not specify a
host and the default is a logical pathname.
7f. MAKE-PATHNAME returns a logical pathname if and only if the host is
logical. If the :host argument to MAKE-PATHNAME is supplied, the host is
logical if it came from PATHNAME-HOST of a logical pathname. Whether a
:host argument is logical if it is a string equal to a logical pathname
host name is implementation-defined.
7g. PARSE-NAMESTRING returns a logical pathname according to points 3b
and 3d.
Add these defined names to Common Lisp in support of logical pathnames:
8. LOGICAL-PATHNAME [Class]
LOGICAL-PATHNAME is a subclass of PATHNAME.
9. LOGICAL-PATHNAME pathname [Function]
Converts the argument to a logical pathname and returns it. The
argument can be a logical pathname, a logical pathname namestring
containing a host component, or a stream for which the PATHNAME
function returns a logical pathname. For any other argument,
LOGICAL-PATHNAME signals an error of type TYPE-ERROR.
10. TRANSLATE-LOGICAL-PATHNAME pathname [Function]
Translates a logical pathname to the corresponding physical pathname.
The pathname argument is first coerced to a pathname. If it is not a
pathname, string, or file stream an error of type TYPE-ERROR is
signalled.
If the coerced argument is a logical pathname, the first matching
translation (according to PATHNAME-MATCH-P) of the logical pathname
host is applied, using TRANSLATE-PATHNAME with the reversible argument
true. If the result is a logical pathname, this process is repeated.
Three values are returned:
1. The physical pathname
2. The from-wildcard of the translation
3. The to-wildcard of the translation
If no translation matches, an error of type FILE-ERROR is signalled.
If the coerced argument is a physical pathname, it is returned as all
three values.
All three values are pathnames. The second and third values might not
come directly from a logical pathname translation list; they might be
modified to reflect multiple levels of translation and/or additional
translations, typically to provide translation of file types to local
naming conventions, to accomodate physical file systems with limited
length names, or to deal with special character requirements such as
translating hyphens to underscores or uppercase letters to lowercase.
Any such additional translations are implementation defined. Some
implementations do no additional translations.
Except when an error is signalled, TRANSLATE-LOGICAL-PATHNAME satisfies
this identity:
(MULTIPLE-VALUE-BIND (PHYSICAL FROM-WILDCARD TO-WILDCARD)
(TRANSLATE-LOGICAL-PATHNAME LOGICAL)
(AND (EQUAL (TRANSLATE-PATHNAME LOGICAL FROM-WILDCARD TO-WILDCARD T)
PHYSICAL)
(EQUAL (TRANSLATE-PATHNAME PHYSICAL TO-WILDCARD FROM-WILDCARD T)
LOGICAL)))
The above is written assuming the LOGICAL argument has already been
coerced to a pathname.
11. LOGICAL-PATHNAME-TRANSLATIONS host [Function]
If <host> is not the host component of a logical pathname and not a
string that has been defined as a logical pathname host name by SETF of
LOGICAL-PATHNAME-TRANSLATIONS, signals an error of type TYPE-ERROR.
Otherwise returns the host's list of translations. Each translation is
a list of at least two elements: from-wildcard and to-wildcard. Any
additional elements are implementation defined. From-wildcard is a
logical pathname whose host is <host>. To-wildcard is a pathname.
Translations are searched in the order listed, so more specific
from-wildcards must precede more general ones.
(SETF (LOGICAL-PATHNAME-TRANSLATIONS host) translations) sets a logical
pathname host's list of translations. If <host> is a string that has
not been previously used as logical pathname host, a new logical
pathname host is defined, otherwise an existing host's translations are
replaced. Logical pathname host names are compared with STRING-EQUAL.
When setting the translations list, each from-wildcard can be a logical
pathname whose host is <host> or a logical pathname namestring
parseable by (PARSE-NAMESTRING string host). Each to-wildcard can be
anything coercible to a pathname by (PATHNAME to-wildcard). If
to-wildcard coerces to a logical pathname, TRANSLATE-LOGICAL-PATHNAME
will perform repeated translation steps when it uses it. There can
be implementation-defined restrictions against logical to-wildcards
that would produce non-reversible translations.
Implementations can define additional functions that operate on
logical pathname hosts.
12. LOAD-LOGICAL-PATHNAME-TRANSLATIONS host [Function]
If a logical pathname host named <host> (a string) is already defined,
return NIL. Otherwise, search for a logical pathname host definition
in an implementation defined manner. If none is found, signal an
error. If a definition is found, install it and return T.
The search used by LOAD-LOGICAL-PATHNAME-TRANSLATIONS should be
documented, as logical pathname definitions will be created by users,
not only by Lisp implementors. A typical search technique is to
look in a certain directory for a file whose name is derived from
the host name in an implementation-defined fashion.
13. COMPILE-FILE-PATHNAME pathname &key :output-file [Function]
Returns the pathname that COMPILE-FILE would write into, if given the
same arguments. If the pathname argument is a logical pathname and the
:output-file argument is unspecified, the result is a logical pathname.
If an implementation supports additional keyword arguments to
COMPILE-FILE, COMPILE-FILE-PATHNAME must accept the same arguments.
Examples:
;This function is like DIRECTORY, but if its argument is a logical
;pathname it returns logical pathnames in the results. If its
;argument is a physical pathname, it is the same as DIRECTORY.
(defun logical-directory (pathname)
(multiple-value-bind (physical from-wildcard to-wildcard)
(translate-logical-pathname pathname)
(map 'list #'(lambda (truename)
(translate-pathname truename to-wildcard
from-wildcard t))
(directory physical))))
;A very simple example of setting up a logical pathname host. No
;translations are necessary to get around file system restrictions, so
;all that is necessary is to specify the root of the physical directory
;tree that contains the logical file system.
;The namestring syntax on the right-hand side is implementation-specific.
(setf (logical-pathname-translations "foo")
'(("**;*.*.*" "MY-LISPM:>library>foo>**>")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "foo:bar;baz;mum.quux.3")
=> MY-LISPM:>library>foo>bar>baz>mum.quux.3,
foo:**;*.*.*,
MY-LISPM:>library>foo>**>*.*.*
;A more complex example, dividing the files among two file servers
;and several different directories. This Unix doesn't support
;:WILD-INFERIORS in the directory, so each directory level must
;be translated individually. No file name or type translations
;are required except for .MAIL to .MBX.
;The namestring syntax on the right-hand side is implementation-specific.
(setf (logical-pathname-translations "prog")
'(("RELEASED;*.*.*" "MY-UNIX:/sys/bin/my-prog/")
("RELEASED;*;*.*.*" "MY-UNIX:/sys/bin/my-prog/*/")
("EXPERIMENTAL;*.*.*" "MY-UNIX:/usr/Joe/development/prog/")
("EXPERIMENTAL;DOCUMENTATION;*.*.*"
"MY-VAX:SYS$DISK:[JOE.DOC]")
("EXPERIMENTAL;*;*.*.*" "MY-UNIX:/usr/Joe/development/prog/*/")
("MAIL;**;*.MAIL" "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:mail;save;ideas.mail.3")
=> MY-VAX:SYS$DISK:[JOE.MAIL.PROG.SAVE]IDEAS.MBX.3,
PROG:MAIL;**;*.MAIL.*,
MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX.*
;Example translations for a program that uses three files main.lisp,
;auxiliary.lisp, and documentation.lisp. These translations might be
;supplied by a software supplier as examples.
;For Unix with long file names
(setf (logical-pathname-translations "prog")
'(("CODE;*.*.*" "/lib/prog/")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> /lib/prog/documentation.lisp,
PROG:CODE;*.*.*,
/lib/prog/*
;For Unix with 14-character file names, using .lisp as the type
(setf (logical-pathname-translations "prog")
'(("CODE;DOCUMENTATION.*.*" "/lib/prog/docum.*")
("CODE;*.*.*" "/lib/prog/")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> /lib/prog/docum.lisp,
PROG:CODE;DOCUMENTATION.*.*,
/lib/prog/docum.*
;For Unix with 14-character file names, using .l as the type
;The second translation shortens the compiled file type to .b
(setf (logical-pathname-translations "prog")
`(("**;*.LISP.*" ,(logical-pathname "PROG:**;*.L.*"))
(,(compile-file-pathname (logical-pathname "PROG:**;*.LISP.*"))
,(logical-pathname "PROG:**;*.B.*"))
("CODE;DOCUMENTATION.*.*" "/lib/prog/documentatio.*")
("CODE;*.*.*" "/lib/prog/")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> /lib/prog/documentatio.l,
PROG:CODE;DOCUMENTATION.LISP.*,
/lib/prog/documentatio.l
;For a Cray with 6 character names and no directories, types, or versions.
(setf (logical-pathname-translations "prog")
(let ((l '(("MAIN" "PGMN")
("AUXILIARY" "PGAUX")
("DOCUMENTATION" "PGDOC")))
(logpath (logical-pathname "prog:code;"))
(phypath (pathname "XXX")))
(append
;; Translations for source files
(mapcar #'(lambda (x)
(let ((log (first x))
(phy (second x)))
(list (make-pathname :name log
:type "LISP"
:version :wild
:defaults logpath)
(make-pathname :name phy
:defaults phypath))))
l)
;; Translations for compiled files
(mapcar #'(lambda (x)
(let* ((log (first x))
(phy (second x))
(com (compile-file-pathname
(make-pathname :name log
:type "LISP"
:version :wild
:defaults logpath))))
(setq phy (concatenate 'string phy "B"))
(list com
(make-pathname :name phy
:defaults phypath))))
l))))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> PGDOC,
PROG:CODE;DOCUMENTATION.LISP.*,
PGDOC
Rationale:
1. Large programs can be moved between sites without changing any
pathnames, provided all pathnames used are logical. A portable system
construction tool can be created that operates on programs defined as
sets of files named by logical pathnames.
2. Logical pathname syntax was chosen to be easily translated into most
popular file systems, while still being powerful enough for storing large
programs. Although they have hierarchical directories, extended wildcard
matching, versions, and no limit on the length of names, they can be
mapped onto a less capable real file file system by translating each
directory that is used into a flat directory name, doing wildcards in
Lisp rather than in the file system, treating all versions as :newest,
and/or using translations to shorten long names.
Logical pathname words are restricted to non-case-sensitive letters,
digits, and hyphens to avoid creating problems with real file systems
that support limited character sets for file naming. Other characters
could have been mapped onto such file systems through translations, but
that didn't seem worth the trouble. Logical pathnames have to be
non-case-sensitive or it would be very difficult to map them onto a
non-case-sensitive file system.
Features such as :UP and :BACK relative directories and a namestring
syntax for the root directory were not felt to be necessary in logical
pathnames. They could be added later if a need emerges.
It is not a goal of logical pathnames to be able to represent all
possible file names. Their goal is rather to represent just enough file
names to be useful for storing software. Real pathnames, in contrast,
need to provide a uniform interface to all possible file names, including
names and naming conventions that are not under the control of Common
Lisp.
The choice of logical pathname syntax, using colon, semicolon, and
period, was guided by the goals of being visually distinct from real file
systems and minimizing the use of special characters.
The consequences of using any value not specified here as a logical
pathname component are unspecified, for the benefit of the Explorer.
3. The LOGICAL-PATHNAME function is separate from the PATHNAME function
so that the syntax of logical pathname namestrings does not constrain the
syntax of physical pathname namestrings in any way. Logical pathname
syntax must be defined by Common Lisp so that logical pathnames can be
conveniently exchanged between implementations, but physical pathname
syntax is dictated by forces outside our control.
3b,c. Allowing PARSE-NAMESTRING and MERGE-PATHNAMES to recognize logical
pathname namestrings in these situations provides for natural operations
on logical pathnames. Frequently a string containing just a name, or a
name and a type, will be recognized as a logical pathname by merging it
against a default containing a logical pathname host and directory.
3d. Recognition of logical pathname namestrings by PATHNAME and related
functions is left up to each implementation because some implementations
definitely require this, other implementations don't want to do this, and
nobody wants to change. In any case, Common Lisp historically has avoided
saying anything about the syntax of the strings accepted by the PATHNAME
function, and point 3d preserves that position.
3b,7f. Leaving it implementation defined whether a string, used as the
host argument to PARSE-NAMESTRING or the :host argument to MAKE-PATHNAME,
can be recognized as logical pathname host name is for the same reason as
point 3d. It allows each implementation to decide whether there is one
namespace or two. The correct way to write this is:
(MAKE-PATHNAME :HOST (PATHNAME-HOST (LOGICAL-PATHNAME "hostname:"))
...)
4. Logical pathname versions could have been supported on real file
systems that do not have versions by defining a kind of translation to
encode the version number in the name. However, the typical use of
versions is such that on a file system without versions, people would
rather just store one version of a file, and not preserve the version
information by encoding it somehow in the name. This is different from
the typical use of types or directories, where the files with different
values in those components are truly distinct and everything would break
if you only kept one file.
5,13. The COMPILE-FILE-PATHNAME function and the specification of "LISP"
as the type of a logical pathname for a Common Lisp source file together
provide enough information about compilation for a portable system
construction tool that uses logical pathnames to work. Suppose you want
to call COMPILE-FILE only if the source file is newer than the compiled
file. To do that, you have to have a way to know the name of the
compiled file without actually calling COMPILE-FILE.
No standard file type for compiler output is proposed, because in some
implementations the compiler produces one of several file types,
depending on a variety of implementation-dependent circumstances.
COMPILE-FILE-PATHNAME provides access to the "default[ing] in a manner
appropriate to the implementation's file system conventions" mentioned in
the CLtL documentation of COMPILE-FILE.
6. The use of the logical pathname host name "SYS" for the implementation
is current practice. Standardizing on this name helps users choose
logical pathname host names that avoid conflicting with
implementation-defined names.
7. Accepting logical pathnames for file access is a natural extension
of the file access functions and makes it easier to program using only
logical pathnames in situations where that is appropriate.
8. The LOGICAL-PATHNAME class exists so that methods can distinguish
logical pathnames from regular pathnames.
9. See point 3 above.
10. TRANSLATE-LOGICAL-PATHNAME is the heart of the logical pathname
feature. The two extra values returned by TRANSLATE-LOGICAL-PATHNAME
allow for back-translation, as shown in the LOGICAL-DIRECTORY example.
Allowing TRANSLATE-LOGICAL-PATHNAME on a physical pathname, simply
returning the argument, makes some programs easier to write. Additional
implementation defined translations make it possible for implementations
with unusual file systems to offer some help to the user in setting up
the translations for a logical pathname host, by handling some of the
work automatically. Logical pathnames that translate to other logical
pathnames are a feature that several people have requested.
11. SETF of LOGICAL-PATHNAME-TRANSLATIONS is a simple way for a user to
define a new logical pathname host. Using SETF makes it possible to add
to or modify the translations of an existing logical pathname host. The
restriction against non-reversible translations is necessary because many
logical pathname using programs depend on reversibility, for instance to
translate a truename back into a logical pathname. If logical pathname
translation was not reversible, two different logical pathnames might
translate into the same physical pathname, which could scramble files.
It is always up to the person who writes the translation rules for a
particular logical pathname host to a particular physical file system to
make sure that the logical pathnames that are actually going to be used
translate to valid pathnames for the particular file system.
12. Loading of logical pathname translations from a site-dependent file
allows software to be distributed using logical pathnames. The assumed
model of software distribution is a division of labor between the
supplier of the software and the user installing it. The supplier
chooses logical pathnames to name all the files used or created by the
software, and supplies examples of logical pathname translations for a
few popular file systems. Each example uses an assumed directory and/or
device name, assumes local file naming conventions, and provides
translations that will translate all the logical pathnames used or
generated by the particular software into valid physical pathnames.
For a powerful file system these translations can be quite simple. For
a more restricted file system, it may be necessary to list an explicit
translation for every logical pathname used, for example when dealing
with restrictions on the maximum length of a file name.
The user installing the software decides on which device and/or directory
to store the files and edits the example logical pathname translations
accordingly. If necessary, the user also adjusts the translations for
local file naming conventions and any other special aspects of the user's
local file system policy and local Common Lisp implementation. For
example, the files might be divided among several file server hosts to
share the load. The process of defining site-customized logical pathname
translations is quite easy for a user of a popular file system for which
the software supplier has provided an example. A user of a more unusual
file system might have to take more time; the supplier can help by
providing a list of all the logical pathnames used or generated by the
software.
Once the user has created a suitable SETF of LOGICAL-PATHNAME-TRANSLATIONS
form, he can evaluate that form and then load and run the software. It
may be necessary to use the translations again, or on another workstation
at the same site, so it is best to save the SETF form in the standard
place where it can be found later by LOAD-LOGICAL-PATHNAME-TRANSLATIONS.
Often a software supplier will include a program for restoring software
from the distribution medium to the file system, and a program for loading
the software from the file system into a Common Lisp, and these programs
will start by calling LOAD-LOGICAL-PATHNAME-TRANSLATIONS to make sure that
the logical pathname host is defined.
Note that the SETF of LOGICAL-PATHNAME-TRANSLATIONS form isn't part of
the program, it's separate. It's written by the user, not by the
software supplier. That separation, and a uniform convention for how to
do the separation, are the key aspects of logical pathnames. For small
programs involving only a handful of files, it doesn't matter much. The
real benefits come with large programs with hundreds or thousands of
files and more complicated situations such as program-generated file
names or porting a program developed on a system with long file names
onto a system with a very restrictive limit on the length of file names.
Current practice:
Symbolics Genera has had a similar facility for many years. It is used
extensively for software distribution by Symbolics and its customers.
The Genera facility uses the same logical pathname syntax but different
function names, and is somewhat more complicated. The extra complexity
is not necessary in the Common Lisp standard.
The T.I. Explorer also has a comparable logical pathname facility,
although the translation mechanism is unfortunately less general than
proposed here. The namestring syntax used is slightly different:
host ":" [{directory "."}* directory ";"] [name] ["." type] ["#" version]
The newest version is indicated by ">" instead of "newest".
Macintosh Allegro Common Lisp) has a logical pathname feature which is
somewhat simpler but aimed at solving the same problems. It has logical
directory names, to simplify access to sets of files in differently named
directories (an especially severe problem on micros where everybody just
has to have a different pet name for their hard disk). This isn't really
the same as simplifying access to different file systems, although of
course solving the latter automatically solves the former. In general,
access to different file systems requires translating names and types,
not just translating directories.
Symbolics Genera offers a function for translating from a physical
pathname back to a logical pathname. There are a number of problems with
this, and so it has not been proposed here. Instead
TRANSLATE-LOGICAL-PATHNAME returns enough information to allow the user
program to perform the backtranslation itself.
The Genera equivalent of LOAD-LOGICAL-PATHNAME-TRANSLATIONS looks for
a file named SYS:SITE;hostname.TRANSLATIONS.
Current practice in Genera, Explorer, and Macintosh has one namespace for
both logical and physical namestrings. This proposal allows an
implementation to choose to have one namespace or to have two separate
namespaces for namestrings.
Cost to Implementors:
This is a fairly complex facility, but its performance is unimportant
so a straightforward implementation should suffice. Most of the
complexity comes in dealing with unusual file systems, such as ones
that don't allow long file names.
Cost to Users:
None.
Cost of non-adoption:
Portable software construction and distribution will have to rely on
implementation-dependent kludges. Lisp software will continue to be
difficult to install.
Performance impact:
None.
Benefits:
Avoid cost of non-adoption.
Esthetics:
Improved portability of large programs.
Discussion:
Issue PATHNAME-LOGICAL fundamentally depends on issue PATHNAME-WILD. If
PATHNAME-WILD:NEW-FUNCTIONS does not pass, PATHNAME-LOGICAL cannot pass.
If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT passes, it will affect the
behavior of the function TRANSLATE-PATHNAME and therefore the behavior of
the function TRANSLATE-LOGICAL-PATHNAME. When a logical pathname
translation has from-wildcard and to-wildcard type components that are
:WILD or omitted, translation of the type will be guided by canonical
types. If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT fails to pass, it will
either have to be done behind the scenes by TRANSLATE-PATHNAME or users
will have to write more verbose translations that individually specify
the handling of each file type.
∂21-Jun-89 1550 X3J13-mailer Issue: PATHNAME-WILD (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:50:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614835; 21 Jun 89 18:52:08 EDT
Date: Wed, 21 Jun 89 18:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (version 5)
To: masinter.pa@Xerox.COM
cc: x3j13@sail.stanford.edu
In-Reply-To: <890621-105115-17348@Xerox>
Message-ID: <19890621225250.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Larry, this PATHNAME-WILD writeup you just mailed out is out of
date. The current version is version 6. Is it possible that
some of your incoming mail is getting lost?
∂21-Jun-89 1550 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 15:50:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614836; 21 Jun 89 18:52:29 EDT
Date: Wed, 21 Jun 89 18:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
To: masinter.pa@Xerox.COM
cc: x3J13@sail.stanford.edu
In-Reply-To: <890621-103757-17307@Xerox>
Message-ID: <19890621225311.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Larry, this PATHNAME-SUBDIRECTORY-LIST writeup you just mailed out is
out of date. The current version is version 7. Is it possible that
some of your incoming mail is getting lost?
∂21-Jun-89 1827 X3J13-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89 18:27:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUN 89 18:26:54 PDT
Date: 21 Jun 89 18:26 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 21 Jun 89 18:53 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, x3J13@sail.stanford.edu
Message-ID: <890621-182654-18446@Xerox>
Hoops, maybe so. I'll double check with your records before mailing any
more out. Sorry, out there in net-land.
∂22-Jun-89 0528 X3J13-mailer csprop
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 05:26:04 PDT
Date: Thu, 22 Jun 89 02:30:57 PDT
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890622.023057.baggins@almvma>
Subject: csprop
I've just sent out the character proposal revised per the last
meeting (unless I forgot something or misread my notes).
All the proposals passed or failed at the March meeting are
so noted. The proposals which were modified during discussion
have been modified. Proposals 2.4.2,3,4 and 2.5.1,2,4,5 are the only
remaining items to be voted on in Palo Alto.
The major changes:
The terminology change from registry to script has been made.
I changed the list of candidate character script names to correspond
to a selection of ones mentioned in ISO 10646.
Proposal 2.4.4: *all-character-script-names* was changed to
the function all-character-script-names. A new function
all-character-language-names was added.
Proposal 2.5.7: This was completely rewritten per suggestions
from Sandra Loosemore. The string-encoded-length function is
replaced with the file-string-length function.
∂22-Jun-89 0553 X3J13-mailer csprop
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 05:52:22 PDT
Date: Thu, 22 Jun 89 02:09:38 PDT
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890622.020938.baggins@almvma>
Subject: csprop
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{June 10, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newtheorem{prop}{Proposal}[section]
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from L. Masinter and other members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
To universally identify each character, we utilize a
universal registry of characters which incorporates a
collection of repertoires called {\em character scripts}
as a partitioning of all characters.
That is, each character is included
in one and only one character script.
\footnote{The practical realization of this registry is the
Draft ISO 10646 Coded Character Set Standard. \cite{iso10646}}
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character script and a character label.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
All other character data objects are classified
as {\em non-graphic} (or {\em control}).
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities. For example, while Common LISP is free to
define unique manipulation facilities for characters, character scripts
and coded character sets, it should
not define standard coded character sets nor standard
character scripts.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
A final purpose is to serve as a basis for terminology within the
standard language specification.
\begin{prop}[Passed 03/89]
The terminology introduced in this proposal will be included
in the language specification at the discretion of the editor.
\end{prop}
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices.
The notion of attributes of character
objects within Common LISP has proven to be either not used or
not portable. The essential aspect of the following proposals is
to what extent attributes continue to be supported by the
language specifications.
\begin{prop}[Alternative A, Passed as Modified 03/89]
Remove all discussion of attributes from
the language specification. Add the following discussion:
\begin{quote}
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects. These and other
supported attributes are considered implementation-defined
attributes and if supported by an implementation effect the
action of selected functions.
\end{quote}
All types, constants and functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified as follows:
\begin{itemize}
\item Modify {\clkwd char-=}: If two characters differ in any
implementation-defined attributes, then they are not {\clkwd char-=}.
\item Modify {\clkwd char-<}: If two characters have identical
implementation-defined attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item Modify {\clkwd char-equal}:
The effect, if any, on {\clkwd char-equal} of each
implementation-defined attribute has to be specified as part of
the definition of that attribute (and similarly for
{\clkwd char-not-equal, char-lessp, char-greaterp,
char-not-greaterp, char-not-lessp}).
\item Modify {\clkwd char-upcase} and {\clkwd char-downcase}:
The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve implementation-defined attributes.
\item Modify {\clkwd read}: It is implementation dependent which
attributes are removed from symbol names.
It is implementation dependent which attributes are removed
from characters within double quotes.
\item Modify {\clkwd intern}: It is implementation dependent
which implementation-defined attributes are removed.
\item Modify {\clkwd digit-char}: remove the optional {\em font}
argument.
\item Modify {\clkwd code-char}: remove the optional {\em font}
and {\em bits} arguments.
\item Remove {\clkwd char-font-limit}
\item Remove {\clkwd char-bits-limit}
\item Remove {\clkwd int-char}
\item Remove {\clkwd char-int}
\item Remove {\clkwd char-bits}
\item Remove {\clkwd char-font}
\item Remove {\clkwd make-char}
\item Remove {\clkwd char-control-bit}
\item Remove {\clkwd char-meta-bit}
\item Remove {\clkwd char-super-bit}
\item Remove {\clkwd char-hyper-bit}
\item Remove {\clkwd char-bit}
\item Remove {\clkwd set-char-bit}
\item Remove {\clkwd string-char} and {\clkwd string-char-p}
\item Modify readtable: If implementation-defined attributes
are supported, an implementation need not (but may) allow
for such characters to have syntax descriptions in the readtable.
Otherwise, all characters are representable in the readtable.
\end{itemize}
\end{prop}
\begin{prop}[Alternative B, Passed as Modified 03/89]
This is identical to all of Alternative A (above) except that
the function {\clkwd char-int} is retained.
{\clkwd char-int} returns a non-negative integer encoding the
character object. The manner in which the integer is computed
is implementation dependent. In contrast to {\clkwd sxhash},
the result is not guaranteed independent of the particular
"incarnation" or "core image".
\end{prop}
With the elimination of {\em font} and {\em bits} from the
specification the usefulness of {\clkwd char-code} and {\clkwd
code-char} is diminished. They are no longer needed for constructing
characters.
The portable mechanisms for hashing are provided by
{\clkwd char-int} and {\clkwd sxhash}.
In addition, using {\clkwd char-code-limit} to iterate over
characters is extremely inefficient in implementations that
support large or user-defined repertoires.
\begin{prop}[Alternative C, Failed 03/89]
This an amendment to Alternative B (above).
\begin{itemize}
\item Remove {\clkwd char-code-limit}
\item Remove {\clkwd char-code}
\item Remove {\clkwd code-char}
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Standard and Semi-Standard Characters}
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional mechanisms,
such as in \cite{kurokawa88}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\begin{prop}[Passed 03/89]
The discussion of standard characters is
replaced by the following:
Common LISP requires all implementations to support a {\em standard}
character subrepertoire.
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic Id categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
Id & Glyph & Name or description
& Id & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\end{prop}
The definition of semi-standard characters has been of minimum
practical use since implementations may or may not support any
of these characters. The essential feature is that, when
supported, they have a predictable treatment by the reader.
\begin{prop}[Failed 03/89]
Remove all discussion of semi-standard characters.
Add that in implementations supporting non-graphic characters other
than \#$\backslash${\clkwd Newline}, the {\clkwd read} function
is required to treat those as
whitespace characters.
\end{prop}
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements need to
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to allow specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarly for the {\clkwd simple-string}
type specifier). This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
\begin{prop}[Passed as Modified 03/89]
Define {\clkwd base-character} as {\clkwd
(upgraded-array-element-type 'standard-char)} and
{\clkwd extended-character} as type {\clkwd
(and character (not base-character))}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
extended-character)}
are referred to as {\em extended characters}.
\end{prop}
This establishes the relationship between the string encoding and
array upgrading strategies of the implementation and
the important character types.
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
\item
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}
\end{itemize}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, may
be privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However,
the proposal emphasizes that whether a character is "base" to
Common LISP depends on the way that an implementation represents
strings, and not any other properties of the implementation or the
host operating system. Imagine two implementations, one of which
encodes all strings as 16-bit characters, and another which has
two kinds of strings: 8-bit strings and 16-bit strings. In the
first implementation, the {\clkwd base-character} is
{\clkwd character}: there's only one kind of string. In the
second implementation, the {\clkwd base-character} would be those
that could be stored in an 8-bit string, and it would be a proper
sub-type of {\clkwd character}.
\subsection{String Type}
\begin{prop}[Passed 03/89]
The {\clkwd string} type
is defined as
a union type. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of {\clkwd character}.
{\clkwd string} used as a type specifier for object creation
means {\clkwd (vector character)}.
\end{prop}
\begin{prop}[Passed as Modified 03/89]
The following string
subtypes are
distinguished with standardized names.
\begin{itemize}
\item {\clkwd base-string} is equivalent to {\clkwd (vector
base-character)}.
Strings of type {\clkwd base-string} are referred to as {\em base
strings}.
\item {\clkwd base-string} is valid as a type specifier that
abbreviates.
\end{itemize}
\end{prop}
\begin{prop}[Passed as Modified 03/89]
Define {\clkwd simple-string} as a union type.
A simple
string is a specialized simple
one dimensional array whose elements are of type
{\clkwd character} or a subtype of character.
{\clkwd simple-string} used as a type specifier for object creation
means {\clkwd (simple-array character ({\em size}))}.
\end{prop}
\begin{prop}[Passed as Modified 03/89]
The following simple string
subtypes are
distinguished with standardized names:
\begin{itemize}
\item {\clkwd simple-base-string} is equivalent to {\clkwd
(simple-array base-character (*)). simple-base-string} is a subtype
of {\clkwd base-string}.
\item {\clkwd simple-base-string} is
valid as a type specifier that abbreviates.
\end{itemize}
\end{prop}
A base string is the most efficient string which can hold
the standard characters.
All Common LISP functions defined to operate on strings treat
all strings strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coercion to an extended string.}
An implementation may support string subtypes in addition
to {\clkwd base-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic characters
might provide as extended characters:
\begin{itemize}
\item {\clkwd string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd string}.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
\begin{prop}[Passed 03/89]
Extend the {\clkwd make-string} function to allow an
{\clkwd element-type} keyword argument:
\begin{itemize}
\item {\clkwd make-string} {\em size}
{\clkwd \&key :initial-element :element-type} [Function]
This returns a simple string of length {\em size}, each
of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be
initialized in an implementation-dependent way. The
{\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type. If
{\clkwd :element-type} is omitted, the type {\clkwd character}
is the default.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Character Naming}
A Common LISP program should be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of character registry is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character script, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
\begin{prop}[Passed 03/89]
Common LISP character codes are composed from a character script and
a character label. The convention by which a character label and
character script compose a character code is implementation
dependent.
\end{prop}
The naming and content of the standard character scripts
is left unspecified by this proposal.
\footnote{The only constraint is that character scripts and
labels be named using only the Latin capital letters A-Z, hyphen and
digits 0-9.}
Below are some candidate character script names:
\begin{itemize}
\item latin
\item extended-latin
\item international-african-alphabet
\item extended-symbols
\item diacritics
\item cyrillic-for-major-languages
\item cyrillic-for-minor-languages
\item greek
\item arabic
\item armenian
\item georgian
\item hebrew
\item hiragana-symbols
\item katakana
\item control (meaning the collection of standard text communication
control codes)
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive.
\footnote{In fact, they are simply 15 of the scripts represented
within
\cite{iso10646}}
The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?). It is application
programs which require a reliable definition of the
script names and their constituents. The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.
\begin{prop}
Standardized Character Scripts are fixed;
an implementation may not extend a standard script's
constituent set of characters beyond the
standard definition.
An implementation may provide support for all or part of any
character script
and may provide new character scripts which include characters
having unique semantics (i.e. not defined in any standard
character script).
Implementation scripts must be uniquely
named using only Latin capital letters A-Z, hyphen and digits 0-9.
An implementation must document the scripts it supports.
For each script supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions. Character labels must be uniquely
named using only Latin capital letters A-Z, hyphen and digits 0-9.
\item Reader Canonicalization.
\footnote{Any mechanisms by which the {\clkwd read} function treats
distinct characters as equivalent.}
\item Effect of character predicates. In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
supported are documented.
\end{itemize}
\end{prop}
We introduce new functions to
compose and decompose character objects. We also extend the
{\clkwd characterp} predicate to
support testing
membership of a character in a given character repertoire.
\footnote{
For example,
testing membership in the Japanese Katakana character repertoire.
}
Functions {\clkwd all-character-script-names}
and {\clkwd all-character-language-names}
are added to
allow application determination of
implementation supported character repertoires.
\begin{prop}
Add the type specifier and (modified) type predicate:
\begin{itemize}
\item {\clkwd (character {\em repertoire})}
This denotes a character type specialized to members of the
specified repertoire. {\em Repertoire} may be {\clkwd :base}
or {\clkwd :standard} or any supported character repertoire
name (a symbol), or a list of names.
{\clkwd (character :base)} is equivalent to {\clkwd base-character}
and
{\clkwd (character :standard)} is equivalent to {\clkwd standard-char}
\item {\clkwd (characterp {\em object} \&optional
{\em repertoire})}
If {\em repertoire} is omitted, {\clkwd characterp} is true if
{\em object} is a character object, and otherwise is false. If
a {\em repertoire} argument is specified, {\clkwd characterp}
is true if {\em object} is a character object and a member
of the specified repertoire, and otherwise is false. {\em Repertoire}
may be any supported character repertoire name (a symbol)
or the names {\clkwd :base} or {\clkwd :standard}.
{\clkwd (characterp x :standard)} is equivalent to
{\clkwd (standard-char-p x)}.
{\clkwd (characterp x :base)} is true if x is a member of the
base character repertoire.
\end{itemize}
\end{prop}
\begin{prop}
Add the following functions:
\begin{itemize}
\item {\clkwd all-character-script-names} {\em [Function]}
The value of {\clkwd all-character-script-names} is a list
of all character script names (symbols) supported by
the implementation. All character scripts are repertiores.
\item {\clkwd all-character-language-names} {\em [Function]}
The value of {\clkwd all-character-language-names} is a list
of all character language names (symbols) supported by
the implementation. All character languages are repertoires.
\footnote{International agreement is also necessary to
establish language repertoires (eg. Canadian-French) and
their respective sorting algorithms, date formats, etc.
\cite{ison622}, \cite{ison623}}
\item {\clkwd char-label} {\em char [Function]}
{\clkwd char-label} returns a string representing the character
label of {\em char}. It is an error if the argument is
not a character object.
\item {\clkwd char-script-name} {\em char [Function]}
{\clkwd char-script-name} returns a string representing the character
script to which {\em char} belongs. It is an error if the
argument is not a character object.
\item {\clkwd find-char} {\em script label [Function]}
{\clkwd find-char} returns a character object. The arguments
{\em script} and {\em label} are names (symbols) of
a character script and label. {\em label} uniquely
identifies a character within the character script named
{\em script}. If the implementation does not support the
specified character, {\clkwd nil} is returned.
\end{itemize}
\end{prop}
\begin{prop}
Character
names accepted and constructed by {\clkwd char-name, name-char}, and
{\clkwd \#$\backslash$} are extended to include character script
names of the form {\em script:label}.
\end{prop}
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
There are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
Given that multiple coded character sets exist, it is useful
to provide portable mechanisms based on their definitions.
\begin{prop}
Add the following functions:
\begin{itemize}
\item {\clkwd char-external-code} {\em char name [Function]}
{\clkwd char-external-code} returns the non-negative integer
representing the encoding of the character {\em char} in the
coded character set named by {\em name}, a symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain the character,
{\clkwd nil} is returned.
\item {\clkwd find-external-char} {\em name index [Function]}
{\clkwd find-external-char} returns a character object.
The argument {\em index} is a non-negative integer
representing the encoding of a character in the
coded character set named by {\em name}, a symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain the character,
{\clkwd nil} is returned.
\end{itemize}
\end{prop}
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
Which coded character sets and encoding schemes
are supported by the overall computing system and the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.
\begin{prop}
Add the additional keyword argument to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-format}
which
specifies a name, or list of names (keyword symbols)
indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
The default value is {\clkwd :default} and is
implementation defined but must include the
base characters.
As many coded character set names must be provided as the
implementation requires for that external coding convention.
Coded character set names must
include the full reference number and approval year. For example,
:ISO8859P1V1987 and :ISO6937P2V1983.
All implementation recognized schemes are formed from
the Latin uppercase A-Z, hyphen, and digit 0-9 characters.
\end{itemize}
This argument is provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream. (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide atopopriate line division behavior
for all character streams.)
\end{prop}
The existing default for the {\clkwd :element-type} argument of
{\clkwd open} is {\clkwd string-char}. This is no longer appropriate
given the elimination of {\clkwd string-char} within the
standard specification.
\begin{prop}[Withdrawn 03/89]
Modify the {\clkwd :element-type} argument to {\clkwd open} as follows:
\begin{itemize}
\item Add {\clkwd base-character} as a valid type.
\item Remove {\clkwd string-char} as a valid type.
\end{itemize}
\end{prop}
The following alternative is consistent with the general
premise that portability is emphasized over efficiency.
\begin{prop}[Alternative A]
The default for the {\clkwd :element-type} argument of {\clkwd open}
is {\clkwd character}.
\end{prop}
The following alternative (B), allows implementations to match
the behavior of {\clkwd open} to the expected behavior of
their file systems.
\begin{prop}[Alternative B]
The default for the {\clkwd :element-type} argument of {\clkwd open}
is implementation defined as a super-type
of {\clkwd base-character}
and a sub-type of {\clkwd character}.
\end{prop}
\begin{prop}
Modify the following functions:
\begin{itemize}
\item {\clkwd with-output-to-string} if no string argument is
provided, produces a stream that accepts all characters and returns
a string of the most specialized type
that accommodates the characters that were actually output.
\item {\clkwd make-string-output-stream}
produces a stream that accepts all characters and returns
(via {\clkwd get-output-stream-string})
a string of the most specialized type
that accommodates the characters that were actually output.
\end{itemize}
\end{prop}
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
This function is necessary
to determine if strings can be written to fixed length
fields in databases. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
\begin{prop}
Add the following function:
\begin{itemize}
\item {\clkwd file-string-length}
{\em file-stream object} [Function]
{\clkwd file-string-length} returns a non-negative integer
which represents the difference between what {\clkwd
(file-position {\em file-stream})} would be after writing the object
and its current value, or {\clkwd nil} if this cannot be
determined. {\em object} must be a string or character.
This integer corresponds to the current state of the stream and
may change if there has been intervening output.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Miscellaneous}
In the process of creating this document, some comments were found
within CLtL which seem appropriate to modify independently of
the other proposals mentioned previously. For each, we identify
the existing statement of CLtL and the recommended change.
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
\multicolumn{2}{l} }
\newcommand{\csdag}{\bf$\Rightarrow$\ddag}
\newcommand{\editstart}{}
\newcommand{\editend}{\\ & \end{tabular}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{prop}[Passed 03/89]
\edithead {\csdag (p12) Chapter 2 Data Types}
\editstart
\\ \bf replace &
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\\ \bf with &
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\editend
\end{prop}
\begin{prop}[Passed as Modified 03/89]
\edithead {\csdag (p25) Chapter 2 Symbols}
\editstart
\\ \bf clarify &
\cltxt
A symbol may have any character in its print name.
\editend
\end{prop}
\begin{prop}[Passed 03/89]
\edithead {\csdag (p163) Chapter 10 Symbols}
\editstart
\\ \bf replace &
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
It is an error to alter a symbol's print name.
\editend
\end{prop}
\begin{prop}[Passed 03/89]
\edithead {\csdag (p168) Chapter 10 The Print Name}
\editstart
\\ \bf replace &
\cltxt
It is an extremely bad idea to modify a string being used
as the print name of a symbol.
\\ \bf with &
\cltxt
It is an error to modify a string being used
as the print name of a symbol.
\editend
\end{prop}
\begin{prop}[Passed 03/89]
\edithead {\csdag (p249,make-sequence) Chapter 14 Simple Sequence
Functions}
\editstart
\\ \bf append &
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\editend
\end{prop}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO DP 10646]{iso10646} ISO,
{\em
Draft Proposal Information processing -- Multiple octet coded
character set
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[ISO N622R]{ison622} ISO,
{\em
Programming Language Recommendations for International
Character Handling
},
Joint meeting of ISO SC2, SC22, SC21/WG3, Geneva 26-28 (1989).
\bibitem[ISO N623R]{ison623} ISO,
{\em
Requirements on Coded Characters Sets for International
Characters
},
Joint meeting of ISO SC2, SC22, SC21/WG3, Geneva 26-28 (1989).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂22-Jun-89 0723 X3J13-mailer Re: csprop
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jun 89 07:23:42 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18663; Thu, 22 Jun 89 08:24:07 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02645; Thu, 22 Jun 89 08:24:05 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906221424.AA02645@defun.utah.edu>
Date: Thu, 22 Jun 89 08:24:01 MDT
Subject: Re: csprop
To: Thom Linden <baggins@IBM.com>
Cc: Common Lisp mailing <x3j13@sail.stanford.edu>
In-Reply-To: Thom Linden <baggins@IBM.com>, Thu, 22 Jun 89 02:30:57 PDT
I've put a copy of the character proposal where you can get it via
anonymous FTP. It's on cs.utah.edu, in ~ftp/pub/cl-cs-proposal.{tex|dvi}.
-Sandra
-------
∂22-Jun-89 1217 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 12:16:53 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 12:17:15 PDT
Date: 22 Jun 89 12:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
To: x3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890622-121715-1166@Xerox>
Version 3 of this issue passed Jan 89 with some amendments
there. Since then, some problems were discovered with it.
It was raised at the March 89 meeting, but as there
wasn't a recent version available, tabled to Jun 89.
Version 5 was ready in March, but there were some additional
comments from David Moon. I've modified it to include
(most of) his recommendations.
Version 3 of this proposal was raised at the January 1989
X3J13, and passed with three amendments:
a) add RANDOM-STATE to the list of types
b) add the requirement that TYPE-OF is a subtype of CLASS-OF
c) change the relation to CLOS to say
"for all objects
for which CLASS-OF returns a class with a proper name, TYPE-OF returns
that proper name."
It was noted that SHORT-FLOAT, LONG-FLOAT and RATIONAL were
omitted inadvertently. We would like to ask that the proposal
be reconsidered so that these types could also be included.
This version includes those amendments, and also
adds SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Version 4, 3-14-89 Steele
Version 5, 16-Mar-89, Masinter (add other amendments)
Version 6, 22-Jun-89, Masinter (fix as per Moon)
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, COMPLEX, NUMBER, NULL, SYMBOL,
STRING, BIT-VECTOR, VECTOR, ARRAY, RANDOM-STATE, SEQUENCE,CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be T, or use SATISFIES, AND, OR, NOT or VALUES.
(d) The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF, and is a subtype that the implementation's
SUBTYPEP can recognize.
(e) For objects of metaclass STRUCTURE-CLASS or STANDARD-CLASS,
TYPE-OF returns the proper name of the class returned by CLASS-OF
if it has a proper name, and otherwise returns the class itself.
In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
About part (c): the restriction on T is meaningless, since the CLASS-OF
restriction dominates it. The restriction on MEMBER is OK, just to keep
TYPE-OF from being the silly definition that (type-of x) = `(member ,x). I
think we're running out of good reasons to leave out SATISFIES, AND, OR,
NOT, and VALUES; they're probably no more useful, but we're probably
overspecifying for no good reason.
Some types are left out of the list in (a), including:
BIGNUM and FIXNUM were left out because their division was implementation
dependent.
KEYWORD was left out because under odd circumstances it is possible to
dynamically change the 'type' (e.g., by UNINTERN).
STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
aren't built-in classes.
(These reasonas are not 100% compelling.)
∂22-Jun-89 1218 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 12:18:51 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 89 12:18:04 PDT
Date: 22 Jun 89 12:17 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.6
To: x3J13@sail.stanford.edu
Comment: <<Subject line wrong: this is version 6>>
Message-ID: <890622-121804-1167@Xerox>
Version 3 of this issue passed Jan 89 with some amendments
there. Since then, some problems were discovered with it.
It was raised at the March 89 meeting, but as there
wasn't a recent version available, tabled to Jun 89.
Version 5 was ready in March, but there were some additional
comments from David Moon. I've modified it to include
(most of) his recommendations.
Version 3 of this proposal was raised at the January 1989
X3J13, and passed with three amendments:
a) add RANDOM-STATE to the list of types
b) add the requirement that TYPE-OF is a subtype of CLASS-OF
c) change the relation to CLOS to say
"for all objects
for which CLASS-OF returns a class with a proper name, TYPE-OF returns
that proper name."
It was noted that SHORT-FLOAT, LONG-FLOAT and RATIONAL were
omitted inadvertently. We would like to ask that the proposal
be reconsidered so that these types could also be included.
This version includes those amendments, and also
adds SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Version 4, 3-14-89 Steele
Version 5, 16-Mar-89, Masinter (add other amendments)
Version 6, 22-Jun-89, Masinter (fix as per Moon)
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, COMPLEX, NUMBER, NULL, SYMBOL,
STRING, BIT-VECTOR, VECTOR, ARRAY, RANDOM-STATE, SEQUENCE,CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be T, or use SATISFIES, AND, OR, NOT or VALUES.
(d) The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF, and is a subtype that the implementation's
SUBTYPEP can recognize.
(e) For objects of metaclass STRUCTURE-CLASS or STANDARD-CLASS,
TYPE-OF returns the proper name of the class returned by CLASS-OF
if it has a proper name, and otherwise returns the class itself.
In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
About part (c): the restriction on T is meaningless, since the CLASS-OF
restriction dominates it. The restriction on MEMBER is OK, just to keep
TYPE-OF from being the silly definition that (type-of x) = `(member ,x). I
think we're running out of good reasons to leave out SATISFIES, AND, OR,
NOT, and VALUES; they're probably no more useful, but we're probably
overspecifying for no good reason.
Some types are left out of the list in (a), including:
BIGNUM and FIXNUM were left out because their division was implementation
dependent.
KEYWORD was left out because under odd circumstances it is possible to
dynamically change the 'type' (e.g., by UNINTERN).
STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
aren't built-in classes.
(These reasonas are not 100% compelling.)
∂22-Jun-89 1251 X3J13-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 10
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jun 89 12:50:45 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA28295; Thu, 22 Jun 89 13:50:51 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02831; Thu, 22 Jun 89 13:50:47 -0600
Date: Thu, 22 Jun 89 13:50:47 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906221950.AA02831@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 10
This is a revised version of an issue that was distributed last week.
Besides fixing a few more typos, I have added some clarifications,
mostly relating to the interaction between DEFDECLARE and normal
compiler/interpreter processing of DECLARE, and resolution of
potential conflicts between declaration specifiers defined with
DEFDECLARE and those defined in the standard or by the implementation.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
CLtL Chapter 9: Declarations,
Issue COMPILE-FILE-ENVIRONMENT,
Issue DEFINING-MACROS-NON-TOP-LEVEL,
Issue DESTRUCTURING-BIND,
Issue EVAL-WHEN-NON-TOP-LEVEL,
Issue GET-SETF-METHOD-ENVIRONMENT,
Issue FUNCTION-NAME,
Issue FUNCTION-TYPE,
Issue MACRO-ENVIRONMENT-EXTENT,
Issue MACRO-FUNCTION-ENVIRONMENT,
Issue PROCLAIM-LEXICAL,
Issue PACKAGE-CLUTTER
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Version 7, 7-Apr-89, Moon & Barrett (more revisions)
Version 8, 9-Jun-89, Kim A. Barrett (add DEFDECLARE)
Version 9, 13-Jun-89, Moon (small corrections)
Version 10, 22-Jun-89, Loosemore (more clarifications,
primarily relating to DEFDECLARE)
Status: Ready for release
Problem description:
When macro forms are expanded, the expansion function is called with two
arguments: the form to be expanded, and the environment in which the form was
found. The environment argument is of limited utility. The only use
sanctioned currently is as an argument to MACROEXPAND or MACROEXPAND-1 or
passed directly as an argument to another macro expansion function. Recently
passed cleanup issues allow it as an argument to MACRO-FUNCTION and to
GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle local
macro and function definitions, due to insufficient access to the information
contained in environments and the inability to augment environments with local
definitions.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic environment
objects. In all of these functions the argument named ENV is an environment
of the sort received by the &ENVIRONMENT argument to a macro or as the
environment argument for EVALHOOK. (It is not required that implementations
provide a distinguished representation for such objects.) Optional "env"
arguments default to NIL, which represents the local null lexical environment
(containing only global definitions and proclamations that are present in the
runtime environment). All of these functions should signal an error of type
TYPE-ERROR if the value of an environment argument is not a syntactic
environment.
The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION-INFORMATION retrieve information about declarations that are in
effect in the environment. Since implementations are permitted to ignore
declarations (except for SPECIAL declarations and OPTIMIZE SAFETY
declarations if they ever compile unsafe code), these accessors are required
only to return information about declarations that were explicitly added to
the environment using AUGMENT-ENVIRONMENT. They might also return
information about declarations recognized and added to the environment by the
interpreter or the compiler, but that is optional at the discretion of the
implementer. Implementations are also permitted to canonicalize
declarations, so the information returned by the accessors might not be
identical to the information that was passed to AUGMENT-ENVIRONMENT.
VARIABLE-INFORMATION variable &optional env [Function]
This function returns information about the interpretation of the symbol
VARIABLE when it appears as a variable within the lexical environment ENV.
The following three values are returned.
The first value indicates the type of definition or binding which is apparent
in ENV:
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT, or VARIABLE is a keyword symbol.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result will also
refer to variables proclaimed lexical.]
The second value indicates whether there is a local binding of the name. If
the name is locally bound, the second value is true. Otherwise, NIL is
returned.
The third value is a property list containing information about declarations
that apply to the apparent binding of the variable. The keys in the property
list are symbols which name declaration-specifiers, and the format of the
corresponding values depends on the particular declaration-specifier
involved. The standard declaration-specifiers that might appear as keys in
this property list are:
DYNAMIC-EXTENT a non-NIL value indicates that the variable has been
declared DYNAMIC-EXTENT. If the value is NIL, the property
might be omitted.
IGNORE a non-NIL value indicates that the variable has been declared
IGNORE. If the value is NIL, the property might be omitted.
TYPE a type specifier associated with the variable by a TYPE
declaration or an abbreviated declaration such as (FIXNUM VAR).
If no explicit association exists, either by PROCLAIM or
DECLARE, then the type specifier is T. It is permissible for
implementations to use a type specifier that is equivalent
to or a supertype of the one appearing in the original
declaration. If the value is T, the property might be
omitted.
If an implementation supports additional declaration-specifiers that
apply to variable bindings, those declaration-specifiers might also
appear in the property list. However, the corresponding key must not
be a symbol that is external in any package defined in the standard
or that is otherwise accessible in the USER package.
The property list might contain multiple entries for a given
property. The consequences of destructively modifying the list
structure of this property list or its elements (except for values that
appear in the property list as a result of DEFDECLARE) are undefined.
Programmers are reminded that the global binding might differ from the
local one, and can be retrieved by calling VARIABLE-INFORMATION
again with a null lexical environment.
FUNCTION-INFORMATION function &optional env [Function]
This function returns information about the interpretation of the function
name FUNCTION when it appears in a functional position within lexical
environment ENV. The following three values are returned.
The first value indicates the type of definition or binding of the function
name which is apparent in ENV:
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
Some function names can refer to both a global macro and a global special
form. In such a case, the macro takes precedence, and :MACRO is returned as
the first value.
The second value specifies whether the definition is local or global. If
local, the second value is true, and it is false when the definition is
global.
The third value is a property list containing information about declarations
that apply to the apparent binding of the function. The keys in the property
list are symbols which name declaration-specifiers, and the format of the
corresponding values depends on the particular declaration-specifier
involved. The standard declaration-specifiers that might appear as keys in
this property list are:
INLINE one of the symbols INLINE, NOTINLINE, or NIL to indicate
whether the function name has been declared INLINE, has been
declared NOTINLINE, or neither. If the value is NIL, the
property might be omitted.
FTYPE the type specifier associated with the function name in the
environment, or the symbol FUNCTION if there is no functional
type declaration or proclamation associated with the function
name. This value might not include all the apparent FTYPE
declarations for the function name. It is permissible for
implementations to use a type specifier that is equivalent
to or a supertype of the one that appeared in the original
declaration. If the value is FUNCTION, the property might be
omitted.
If an implementation supports additional declaration-specifiers that
apply to function bindings, those declaration-specifiers might also
appear in the property list. However, the corresponding key must not be
a symbol that is external in any package defined in the standard or
that is otherwise accessible in the USER package.
The property list might contain multiple entries for a given
property. In this case the value associated with the first entry has
precedence. The consequences of destructively modifying the list
structure of this property list or its elements (except for values
that appear in the property list as a result of DEFDECLARE) are
undefined.
[If issue DYNAMIC-EXTENT-FUNCTION passes, the property DYNAMIC-EXTENT will
be added to the above table.]
Programmers are reminded that the global binding might differ from the local
one, and can be retrieved by calling FUNCTION-INFORMATION again with a null
lexical environment.
DECLARATION-INFORMATION decl-name &optional env [Function]
This function returns information about declarations named by the
symbol DECL-NAME that are in force in the environment ENV.
Only declarations that do not apply to function or variable bindings
(i.e., those that are "pervasive") can be accessed with this function.
The format of the information that is returned depends on the DECL-NAME
involved.
It is required that this function recognize OPTIMIZE and DECLARATION as
DECL-NAMEs. The values returned for these two cases are as follows:
OPTIMIZE a list whose entries are of the form (quality value), where
"quality" is one of the optimization qualities defined by the
standard (SPEED, SAFETY, COMPILATION-SPEED, SPACE, and DEBUG)
or some implementation-specific optimization quality, and
"value" is an integer in the range 0 to 3. The returned list
always contains an entry for each of the standard qualities and
for each of the implementation-specific qualities. In the
absence of any previous declarations, the associated values are
implementation-dependent. The list might contain multiple
entries for a quality, in which case the first such entry
specifies the current value.
The consequences of destructively modifying this list or
its elements are undefined.
DECLARATION a list of the declaration names which have been proclaimed as
valid through the use of the DECLARATION proclamation.
The consequences of destructively modifying this list or
its elements are undefined.
If an implementation has been extended to recognize additional
pervasive declaration specifiers in DECLARE or PROCLAIM, it is required that
either the DECLARATION-INFORMATION function should also recognize those
declarations, or that the implementation provide an accessor that is
specialized for that declaration specifier. If DECLARATION-INFORMATION
is used to return the information, the corresponding DECL-NAME must not
be a symbol that is external in any package defined in the standard or
that is otherwise accessible in the USER package.
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a new environment containing the information present in
ENV, augmented with the information provided by the keyword arguments. It is
intended to be used by program analyzers that perform a code walk.
The arguments are supplied as follows:
:VARIABLE A list of symbols which shall be visible as bound variables in
the new environment. Whether each binding is to be interpreted
as special or lexical depends on SPECIAL declarations recorded
in the environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, specified as a list of
(name definition) lists (that is, in the same format as the
CADR of a SYMBOL-MACROLET special form). The new environment
will have local symbol-macro bindings of each symbol to the
corresponding expansion, so that MACROEXPAND will be able to
expand them properly. A type declaration in the :DECLARE
argument which refers to a name in this list implicitly
modifies the definition associated with the name. The effect
is to wrap a THE form mentioning the type around the
definition.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, specified as a list of (name
definition) lists. Each definition must be a function of two
arguments (a form and an environment). The new environment
will have local macro bindings of each name to the
corresponding expander function, which will be returned by
MACRO-FUNCTION and used by MACROEXPAND.
:DECLARE A list of decl-specs. Information about these declarations can
be retrieved from the resulting environment using the
VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION-INFORMATION accessors.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list. An error is
signaled if any of the symbols naming macros in the :SYMBOL-MACRO alist are
also included in a SPECIAL decl-spec in the :DECLARE argument. An error is
signalled if any of the names of macros in the :MACRO alist are also included
in the :FUNCTION list. The consequences of destructively modifying the list
structure of any of the arguments to this function are undefined.
The condition type of each of these errors is PROGRAM-ERROR.
The extent of the returned environment is the same as the extent of the
argument environment. The result might share structure with the argument
environment, but the argument environment is not modified.
While an environment argument from EVALHOOK is permitted to be used as the
environment argument for this function, the reverse is not true. If an
attempt is made to use the result of AUGMENT-ENVIRONMENT as the environment
argument for EVALHOOK, the consequences are undefined. The environment
returned by AUGMENT-ENVIRONMENT can only be used for syntactic analysis, ie.
the functions specified by this proposal and functions such as MACROEXPAND.
DEFDECLARE decl-name lambda-list &body body [Macro]
Define a handler for the named declaration. This is the mechanism by which
AUGMENT-ENVIRONMENT is extended to support additional declaration
specifiers. The function defined by this macro will be called with two
arguments, a decl-spec whose CAR is decl-name, and the ENV argument to
AUGMENT-ENVIRONMENT. Two values must be returned by the function. The
first value must be one of the following keywords:
:VARIABLE the declaration applies to variable bindings.
:FUNCTION the declaration applies to function bindings.
:DECLARE the declaration is pervasive, rather than applying to bindings.
For the case where the first value indicates the declaration applies to
bindings, the second value is a list, the elements of which are lists of the
form (binding-name property value). If the corresponding information
function (either VARIABLE-INFORMATION or FUNCTION-INFORMATION) is applied to
the binding name and the augmented environment, the property list which is
the third value returned by the information function will contain the value
under the specified property.
When the first value is :DECLARE, the second value is a cons whose CAR is a
property and whose CDR is the associated value. The function
DECLARATION-INFORMATION, when applied to the property and the augmented
environment, will return the associated value.
DEFDECLARE causes DECL-NAME to be proclaimed to be a declaration (it is as
if its expansion included a call (PROCLAIM '(DECLARATION decl-name))).
As is the case with standard declaration specifiers, the evaluator and
compiler are permitted, but not required, to add information about
declaration specifiers defined with DEFDECLARE to the macroexpansion and
evalhook environments.
The consequences are undefined if DECL-NAME is a symbol which can
appear as the CAR of any declaration specifier defined in the standard.
The consequences are also undefined if the return value from a
declaration handler defined with DEFDECLARE includes a property name
that is used by the corresponding accessor to return information about
any declaration specifier defined in the standard. (For example, if
the first return value from the handler is :VARIABLE, the second return
value may not use the symbols DYNAMIC-EXTENT, IGNORE, or TYPE as property
names.)
The DEFDECLARE macro does not have any special compile-time
side-effects.
PARSE-MACRO name lambda-list body &optional env [Function]
This function is used to process a macro definition in the same way
as DEFMACRO and MACROLET. It returns a lambda-expression that accepts
two arguments (a form and an environment). The "name", "lambda-list",
and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
definition.
The "lambda-list" argument can include &ENVIRONMENT and &WHOLE. The "name"
argument is used to enclose the "body" in an implicit BLOCK, and might also
be used for implementation-dependent purposes (such as including the name of
the macro in error messages if the form does not match the lambda-list).
ENCLOSE lambda-expression &optional env [Function]
This function returns an object of type FUNCTION that is equivalent to what
would be obtained by evaluating `(FUNCTION ,LAMBDA-EXPRESSION) in syntactic
environment ENV. The consequences are undefined if any of the local
variable or function bindings (but not macro definitions) that are visible
in the lexical environment represented by ENV are referenced within the
LAMBDA-EXPRESSION.
Rationale:
This proposal defines a minimal set of accessors (VARIABLE-INFORMATION,
FUNCTION-INFORMATION, and DECLARATION-INFORMATION) and a constructor
(AUGMENT-ENVIRONMENT) for environments.
All of the standard declaration specifiers, with the exception of SPECIAL,
can be defined fairly easily using DEFDECLARE. It also seems to be able
to handle most extended declarations.
The PARSE-MACRO function is provided so that users don't have to write their
own code to destructure macro arguments. With the addition of
DESTRUCTURING-BIND to the language, this function is not entirely necessary.
However, it is probably worth including anyway, since any program-analyzing
program is going to need to define it, and the definition isn't completely
trivial.
ENCLOSE is needed to allow expander functions to be defined in a non-NULL
lexical environment, as required by DEFINING-MACROS-NON-TOP-LEVEL:ALLOW. It
also provides a mechanism by which the forms in an (EVAL-WHEN (COMPILE) ...)
can be executed in the enclosing environment (see Issue
EVAL-WHEN-NON-TOP-LEVEL).
Making declarations from an &ENVIRONMENT or EVALHOOK environment optional
continues to allow implementations the freedom simply to ignore all such
declarations in the compiler or interpreter.
Examples:
#1: This example illustrates the first two values returned by the function
VARIABLE-INFORMATION.
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (KIND BINDINGP)
(VARIABLE-INFORMATION VAR ENV)
`(LIST ',VAR ',KIND ',BINDINGP)))
(DEFVAR A)
(DEFCONSTANT B 43)
(DEFUN TEST ()
(LET (C)
(LET (D)
(DECLARE (SPECIAL D))
(SYMBOL-MACROLET ((E ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E)
(KIND-OF-VARIABLE F))))))
(TEST) -> ((A :SPECIAL NIL)
(B :CONSTANT NIL)
(C :LEXICAL T)
(D :SPECIAL T)
(E :SYMBOL-MACRO T)
(F NIL NIL))
#2: This example illustrates the first two values returned by the function
FUNCTION-INFORMATION.
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (KIND BINDINGP)
(FUNCTION-INFORMATION FUNCTION-NAME ENV)
`(LIST ',FUNCTION-NAME ',KIND ',BINDING)))
(DEFUN A ())
(DEFUN (SETF A) (V))
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(LIST (KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION (SETF A))
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> ((A :FUNCTION NIL)
(B :MACRO NIL)
(QUOTE :SPECIAL-FORM NIL)
((SETF A) :FUNCTION NIL)
(C :FUNCTION T)
(D :MACRO T)
(E NIL NIL))
#3: This example shows how a code-walker might walk a MACROLET special form.
It assumes that the revised MACROLET semantics described in proposal
DEFINING-MACROS-NON-TOP-LEVEL:ALLOW are in effect.
(DEFUN WALK-MACROLET (FORM ENV)
(LET ((MACROS (MAKE-MACRO-DEFINITIONS (CADR FORM) ENV)))
(MULTIPLE-VALUE-BIND (BODY DECLS) (PARSE-BODY (CDDR FORM))
(WALK-IMPLICIT-PROGN
BODY
(AUGMENT-ENVIRONMENT ENV :MACRO MACROS :DECLARE DECLS)))))
(DEFUN MAKE-MACRO-DEFINITIONS (DEFS ENV)
(MAPCAR #'(LAMBDA (DEF)
(LET ((NAME (CAR DEF)))
(LIST NAME
(ENCLOSE (PARSE-MACRO NAME (CADR DEF) (CDDR DEF) ENV)
ENV))))
DEFS))
Cost to Implementors:
Most implementations already record some of this information in some form.
Providing these functions should not be too difficult, but it is a more than
trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable Common
Loops defines a subset of this functionality for its code walker and
implements it on a number of diffent versions of Common Lisp.
Discussion:
The first version of this proposal expressly did not deal with the objects
which are used as environments by EVALHOOK. This version is extended to
support them in the belief that such environments share a lot of functionality
with the syntactic environments needed by a compiler. While the two types of
environments might have very different implementations, there are many
operations which are reasonable to perform on either type, including all of
the accessor functions described by this proposal.
There has been discussion about a macro called WITH-AUGMENTED-ENVIRONMENT,
either in addition to or instead of AUGMENT-ENVIRONMENT. The point of this
would be to say that the extent of the augmented environment is the dynamic
extent of the WITH-AUGMENTED-ENVIRONMENT form. There was some concern that
there might be cases where the macro was awkward to use. Such a macro is not
included in this proposal. If AUGMENT-ENVIRONMENT is provided, then such a
macro is trivially written in terms of the function. There are places in the
processing of sequential binding forms where using such a macro might be more
difficult than using the specified function.
Some people have indicated they think that the :MACRO argument (and the
:SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an a-list of the
form ((name . definition)...) rather than the form ((name definition)...).
Some people have indicated they think that implementations must never discard
any declarations, even if they are not otherwise used by the interpreter or
compiler. Proposal SMALL is consistent with what CLtL says (implementations
are free to ignore all declarations except SPECIAL declarations), but the
DECLARATION-INFORMATION function might not be particularly useful unless it is
guaranteed to do something. Requiring implementations to keep track of
declarations they'd otherwise ignore would involve some implementation cost
and also might incur a performance penalty.
ENCLOSE happens to subsume the extension to COERCE for converting a lambda
expression into a function (see Issue FUNCTION-TYPE, passed in June 1988).
Perhaps the extension to COERCE should be backed out?
There have been some suggestions for related functionality that have not
been included in this proposal because we haven't had the time to give
them adequate consideration, and some of them might be controversial.
These suggestions include:
- Adding a function to canonicalize type specifiers.
- Extending VARIABLE-INFORMATION to return a value indicating whether there
is a special binding of the variable in the environment, regardless of
whether or not it has been shadowed by a lexical or symbol-macro binding
of the same name.
- A function to map over all names that are defined in the lexical
environment:
MAP-ENVIRONMENT fn key &optional env
KEY must be one of the symbols :FUNCTION, :VARIABLE, or :DECLARATION.
when key is :FUNCTION,
for every symbol S for which (FUNCTION-INFORMATION s ENV)
would return the values X, true, Y, for any X and Y,
FN is applied to the arguments S, X, and Y.
when key is :VARIABLE,
for every symbol S for which (VARIABLE-INFORMATION s ENV)
would return the values X, true, Y, for any X and Y,
FN is applied to the arguments S, X, and Y.
when key is :DECLARATION,
for every symbol S for which (VARIABLE-INFORMATION s ENV)
would return a non-nil value L
FN is applied to the arguments S and L.
- Adding additional accessors and keyword arguments to AUGMENT-ENVIRONMENT
for BLOCK and TAGBODY labels.
∂22-Jun-89 1408 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jun 89 14:08:34 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03026; Thu, 22 Jun 89 15:08:55 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02863; Thu, 22 Jun 89 15:08:49 -0600
Date: Thu, 22 Jun 89 15:08:49 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906222108.AA02863@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 7
Version 6 of this issue with only proposal TIGHTEN was distributed
last week. However, since then, a number of people on the cl-compiler
mailing list have expressed support for flushing COMPILED-FUNCTION
and/or dissatisfaction with proposal TIGHTEN. Therefore, I have
restored proposal FLUSH, which previously appeared in the version of
this issue that was distributed at the last meeting. Proposal TIGHTEN
is unchanged from version 6.
I have attempted to summarize the latest bunch of e-mail in the
discussion section of the writeup. I expect there will be some
further discussion on this issue at the meeting.
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION (passed)
Issue EVAL-WHEN-NON-TOP-LEVEL (passed)
Issue LOAD-TIME-EVAL (passed)
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Issue COMPILE-ARGUMENT-PROBLEMS (passed)
Category: CLARIFICATION, CHANGE
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
V3, 10 Feb 1989, Sandra Loosemore (new proposal)
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
with other pending proposals)
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
V6, 30 May 1989, Sandra Loosemore (fix proposal TIGHTEN to
apply only to COMPILE-FILE)
V7, 22 Jun 1989, Sandra Loosemore (restore FLUSH again)
Status: Ready for release
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
There are two proposals, FLUSH and TIGHTEN.
Proposal TIGHTEN presents a simple model of the compilation process. A
minimal compiler could be implemented to perform a code walk to apply
the indicated transformations to the function source code. Of course,
most compilers will perform other transformations as well, such as
translating the Lisp source code into a representation that is more
compact or which can be executed more efficiently.
Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:
(1) Remove the type specifier COMPILED-FUNCTION and the predicate
COMPILED-FUNCTION-P from the language.
(2) Remove the language from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY
that says "it is an error" to try to COMPILE a function that
was defined interpretively in a non-null lexical environment.
Instead, state that if COMPILE cannot compile the function,
it should simply behave as an identity operation.
Rationale:
Some people think the wording of proposal TIGHTEN is too vague and
does not provide an adequate definition of what COMPILED-FUNCTIONs
are. Some people think that since proposal TIGHTEN does not require
COMPILE to produce a COMPILED-FUNCTION, its specification is too
weak to be of much use to users.
Since we are unable to reach concensus on what a COMPILED-FUNCTION
really is, or how to construct one, it seems better to remove it
from the language entirely.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls appearing lexically within the function have
already been expanded and will not be expanded again when the
function is called. (See CLtL p. 143.) The process of
compilation effectively turns MACROLET and SYMBOL-MACROLET
constructs into PROGNs with all instances of the local macros
in the body fully expanded.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within
the function are to be treated as lexical or special.
- Lexically nested EVAL-WHENs have been processed as stated in
proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
an implicit PROGN or as the constant NIL.
- If the function contains lexically nested LOAD-TIME-VALUE forms,
these have already been pre-evaluated and will not be evaluated
again when the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for functions that are
not COMPILED-FUNCTIONs to satisfy the above criteria.
(3) Clarify when functions are defined in a file which is compiled
with COMPILE-FILE, and the compiled file is subsequently LOADed,
objects of type COMPILED-FUNCTION result.
(4) Clarify that COMPILE may or may not produce an object of type
COMPILED-FUNCTION; if the implementation cannot compile a function,
it may simply do nothing at all. Change the description of
COMPILE (from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY) to state
that the behavior of COMPILE when passed a function that was
defined in a non-null lexical environment is unspecified (rather
than "is an error").
Rationale:
This proposal allows users to count on COMPILE-FILE always producing
objects that are COMPILED-FUNCTION-P. It also allows for the
possibility that COMPILE may not actually do anything interesting
in some implementations.
Some specific properties are assigned to compiled functions. Users
would be able to rely on any function which is of type
COMPILED-FUNCTION having really been (at least partially) compiled.
It also states what many people believe to be the minimum functionality
required of a compiler.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation. It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.
Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
In Utah Common Lisp, COMPILED-FUNCTION-P currently returns true of all
function objects, but there is an internal tag field in the object
which allows real compiled functions to be distinguished from
interpreted functions.
Cost to implementors:
Unknown, but probably not too great. Many implementations will
probably have to make some minor changes to representation of
functions and/or to the definition of COMPILED-FUNCTION-P, but
probably most of those changes are necessary to support the
FUNCTION-TYPE proposal anyway.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
This writeup originally contained an additional proposal,
TIGHTEN-COMPILE. A straw vote at the March 1989 meeting indicated
that an earlier version of proposal TIGHTEN had the most support.
However, a number of people still have a strong preference for
proposal FLUSH.
Recent mail on the cl-compiler list has indicated that Moon, Loosemore
and MacLachlan favor flushing COMPILED-FUNCTION; White and Burke have
no objection to doing so; and that Pitman would like to see the type
retained with both COMPILE and COMPILE-FILE required to produce
compiled functions. Nobody has explicitly stated a preference for
proposal TIGHTEN in this round of discussion.
Loosemore would also prefer to see the type retained, but thinks that
since we have been unable to reach a consensus on what the
compiled-function type means or how to construct an object of this
type, we are much better off not saying anything about it at all in
the standard, than standardizing a definition that is too vague to
be of any use to users, or that some people believe is wrong.
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One use of the COMPILED-FUNCTION type is in declarations. A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION. However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION.
Moon says:
I much prefer the option FLUSH...
This type has no portable meaning and never should have existed.
Pierson says:
What I (and believe Kent) want is a guarantee that [COMPILE] won't
signal an error; if nothing else works COMPILE will simply apply
#'IDENTITY to the symbol's function. Specifically, it should be
legal and safe to attempt to speed up my current program(s) by
doing:
(DO-SYMBOLS (SYM <my-package>)
(WHEN (FBOUNDP SYM) (COMPILE SYM)))
∂22-Jun-89 1422 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 13
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jun 89 14:21:01 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA04026; Thu, 22 Jun 89 15:21:22 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02875; Thu, 22 Jun 89 15:21:19 -0600
Date: Thu, 22 Jun 89 15:21:19 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906222121.AA02875@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-DIAGNOSTICS, version 13
Version 11 of this issue passed at the March meeting. However, there has
been a request to reopen the issue. The changes are confined to item (4)
of the proposal, and involve changing the description of COMPILE to
return a second value to indicate the status of the compilation in the
same way as COMPILE-FILE, and specifying that the status value should be
a symbol indicating the severity of the problems encountered during
compilation instead of just a boolean.
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Issue CONDITION-RESTARTS
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
V9, 26 Jan 1989, Sandra Loosemore (simplify)
V10, 22 Mar 1989, Sandra Loosemore (error terminology)
V11, 11 Apr 1989, Kent Pitman (changes per X3J13)
V12, 21-Jun-89, Moon (changes to point 4 only: return a
status value from COMPILE also, make the status
value provide more detail)
V13, 22-Jun-89, Loosemore (fix one of the fixes)
Status: Passed V11
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
of WARNING.
(2) Clarify that ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) The compiler is permitted to signal diagnostics about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
calls to function with wrong number of arguments
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) State that both COMPILE and COMPILE-FILE are allowed to establish
a default condition handler. If such a condition handler is
established, however, it must first resignal the condition to give any
user-established handlers a chance to handle it. If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.
(4) Specify that COMPILE and COMPILE-FILE return two values. The first
value from COMPILE is not changed by this proposal. The first value
from COMPILE-FILE is the truename of the output file, or NIL if the
file could not be created. The second value is one of the following
symbols, to indicate the success or failure of the compilation:
ERROR if a condition of type ERROR was detected by the compiler's
default error handler but not handled by a user error handler
when the condition was resignalled. So even if the error
were turned into a warning by the default handler, it would
still count as an error for this purpose.
WARNING if there was no error, and a warning was issued by the
compiler in a situation where the standard explicitly states
that a warning must, should, or may be signalled; or where
the compiler can determine that a situation with undefined
consequences or that would cause an error to be signalled
would result at runtime.
STYLE-WARNING if there was no error or warning, but there was a
style warning as defined in point 2c.
NIL if there were no errors, warnings, or style warnings.
Rationale:
Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.
Requiring any condition handlers established by the compiler to resignal
the condition before proceeding with any implementation-specific action
gives user error handlers a chance to override the compiler's default
behavior. For example, the user error handler could invoke a restart
such as ABORT or MUFFLE-WARNING.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire compilation if it is not feasible to abort a
smaller part.
Requiring a second success-p value to be returned from COMPILE-FILE
gives the user some indication of whether there were serious problems
encountered in compiling the file.
Test Case/Example:
Here is an example of how COMPILE-FILE might set up its condition
handlers. It establishes an ABORT restart to abort the compilation
and a handler to take implementation-specific action on ERROR
conditions. Note that INTERNAL-COMPILE-FILE may set up additional
ABORT restarts.
(defvar *output-file-truename* nil)
(defun compile-file (input-file &key output-file)
(let ((*output-file-truename* nil)
(errors-detected nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((error #'(lambda (condition)
(setq errors-detected t)
(signal condition)
...)))
(internal-compile-file input-file output-file)))
(values *output-file-truename*
errors-detected)))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
Explicit calls to ERROR don't really justify warnings to be signalled
at compile-time, but we assume implementors have some common sense
about when it's appropriate to do so.
Proposal CONDITION-RESTARTS:PERMIT-ASSOCIATION would make it illegal
for conditions to be resignalled. If that proposal is accepted, the
wording here would have to be changed to indicated that the compiler's
condition handler makes a copy of the condition and signals that.
Moon says:
I think [requiring the ABORT restart to be handled] is wrong. The only
documentation of the ABORT restart that I could find says
The purpose of the ABORT restart is generally to allow return to the
innermost ``command level.''
I agree with this, and I believe it means that it is wrong for any
function other than one that establishes a read-eval-print loop or
a command-level to establish an ABORT restart. It would be useful
to have some restart that aborts a portion of the compilation, but
it should be given some other name.
∂22-Jun-89 1524 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Jun 89 15:24:41 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA07823g; Thu, 22 Jun 89 15:22:43 PDT
Received: by bhopal id AA08358g; Thu, 22 Jun 89 15:24:58 PDT
Date: Thu, 22 Jun 89 15:24:58 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8906222224.AA08358@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: X3J13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 21 Jun 89 13:02 EDT <19890621170228.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
re: Haven't we been over and over and over this already? No portability is
removed.
. . .
Consider for example the trivial:
(typep (make-array 5 :adjustable t) 'simple-array)
If I read the proposal correctly, it would explicitly permit this
to return true, instead of false.
That is correct. How does that break any program? How does that force
any vendor to change their implementation? I do not believe that there
is any program that works in any implementation that will stop working
in that implementation as a result of this proposal. I think if you
read carefully what the proposal actually says, not biased by earlier
versions of the proposal, you will agree with me in that conclusion.
Let's review the ground rules on what one means by "non-portable" and
"break". If FOO is a primitive specified in the language, and X refers
to some data object calculated by a program, the one would expect
(FOO X) to evaluate the same on two different implementations. The
"same" for type predicates simply means that either both implementations
return true, or both return false.
The program:
(typep (make-array 5 :adjustable t) 'simple-array)
"breaks" under this proposal -- it doesn't "break" under the definition
found on CLtL p.28.
By contrast -- just to show that this isn't a trivial, inconsequential
feature, the two programs:
(typep (int-char 100) 'number)
(typep (char-int #\A) 'character)
don't break under CLtL definitions, and aren't (yet!) broken by any
X3J13 proposals.
Programmers who add declarations to their programs will frequently
add runtime type discriminations, expecting different consequences.
Your reasoning that no "conformal" programs are broken is based on
the preassumption that there are no portability guarantees for
the type SIMPLE-ARRAY. I do not grant that presumption. This is
a change -- even if the primary programmatic effect is seen only
when one calls TYPEP. Of course, it has no effect whatsoever on
those who do not port their code form one so-called "conforming"
implementation to another so-called "conforming" implementation; but
from those who do such porting, we have heard numerous complaints on
precisely such variation.
-- JonL --
∂22-Jun-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 16:00:30 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 615657; 22 Jun 89 19:01:43 EDT
Date: Thu, 22 Jun 89 19:01 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: jonl@lucid.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, X3J13@sail.stanford.edu
In-Reply-To: <8906222224.AA08358@bhopal>
Message-ID: <19890622230138.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 22 Jun 89 15:24:58 PDT
From: Jon L White <jonl@lucid.com>
... Let's review the ground rules on what one means by "non-portable" and
"break". If FOO is a primitive specified in the language, and X refers
to some data object calculated by a program, the one would expect
(FOO X) to evaluate the same on two different implementations. The
"same" for type predicates simply means that either both implementations
return true, or both return false.
No, wrong on two points.
For example,
(DEFUN FOO (X) "Determines if FOO is a fixnum." (TYPEP X 'FIXNUM))
might be portable, and yet might yield a different result on different
implementations.
Furthermore, you are not using the working definition of portable for CLtL
programmers.
It is not the case that simply having an expectation that conforms with CLtL
and writing a program which is true to that expectation makes the program
portable. Right now, a program is portable only if it runs in all
implementations which claim to be conforming.
CLtL is at best legitimately ambiguous on the point in question. There are
two valid interpretations which conforming processors can use. Lucid has
chosen one, Symbolics the other. A portable program is one that does not
get into the gray area. Programs are non-portable if they do the kinds of
things you suggest.
For example, it is currently (under CLtL) conforming for (SUBTYPEP X anything)
to always return NIL,NIL. As such, any program which ever seriously expects
SUBTYPEP to return T is not portable because there might be a conforming
implementation that violates this assumption.
Conforming doesn't imply portable, nor does portable imply conforming.
It is probably conforming to declare your program SIMPLE-ARRAY.
It just happens not to be portably meaningful. As such, this is not
an incompatible change.
As precedent, I cite the fact that Steele made a similar remark about unbound
declarations. e.g., (LOCALLY (DECLARE (FIXNUM X)) (+ X 3)). His claim was
that this was conforming to CLtL because CLtL permitted it but meaningless
because CLtL did not define its meaning. When we did this issue, I think
we called it a clarification because no one claimed that it would break
portable code. But it could have broken conforming code, because some code
might have done it already, and it might have changed the effect of that
conforming code, even though the user had no reason to expect any particular
result from such conforming code.
I have tried to use the terminology CLARIFICATION/CHANGE in cleanup
issues I've written in which the issue is a CLARIFICATION from the point
of view of portable programs, but the issue infringes on conforming
extensions which particular implementations (such as yours) might have
made. I think you can make a case that this issue causes your
implementation some grief, but I don't think you can make the claim that
this issue causes a problem for portable programs.
∂22-Jun-89 1620 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 22 Jun 89 16:20:24 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 22 Jun 89 19:20:33 EDT
Date: Thu, 22 Jun 89 19:18 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
To: Jon L White <jonl@lucid.com>
Cc: Moon@stony-brook.scrc.symbolics.com, X3J13@sail.stanford.edu
In-Reply-To: <8906222224.AA08358@bhopal>
Message-Id: <19890622231840.7.BARMAR@OCCAM.THINK.COM>
Date: Thu, 22 Jun 89 15:24:58 PDT
From: Jon L White <jonl@lucid.com>
Let's review the ground rules on what one means by "non-portable" and
"break". If FOO is a primitive specified in the language, and X refers
to some data object calculated by a program, the one would expect
(FOO X) to evaluate the same on two different implementations. The
"same" for type predicates simply means that either both implementations
return true, or both return false.
The program:
(typep (make-array 5 :adjustable t) 'simple-array)
"breaks" under this proposal -- it doesn't "break" under the definition
found on CLtL p.28.
By that definition, (typep (expt 2 20) 'fixnum) "breaks". On a system
with 16-bit fixnums it returns NIL, but it returns T if fixnums are 32
bits.
Programmers who add declarations to their programs will frequently
add runtime type discriminations, expecting different consequences.
Your reasoning that no "conformal" programs are broken is based on
the preassumption that there are no portability guarantees for
the type SIMPLE-ARRAY. I do not grant that presumption. This is
a change -- even if the primary programmatic effect is seen only
when one calls TYPEP. Of course, it has no effect whatsoever on
those who do not port their code form one so-called "conforming"
implementation to another so-called "conforming" implementation; but
from those who do such porting, we have heard numerous complaints on
precisely such variation.
OK, by your definition, the proposal "breaks" SIMPLE-ARRAY. But what
difference does it make?
Let's think about what types such as SIMPLE-ARRAY and FIXNUM are useful
for. They are used when the program knows (either a priori, or by
testing) that it has an object of the implementation-specific data type,
so it can include declarations that enable the compiler to generate
faster code. For instance, one might write:
(if (<= most-negative-fixnum x most-positive-fixnum)
(locally (declare (fixnum x))
...)
...)
or
(if (typep a 'simple-array)
(locally (declare (simple-array a))
<code that doesn't try to set the fill pointer,
or adjust the array, and which should generate better
code in implementations that care>
)
<code that makes no assumptions, and may run slower>)
So, what happens if an implementation defines SIMPLE-ARRAY so that it
includes adjustable arrays? I say nothing bad. If the code inside the
LOCALLY calls ADJUST-ARRAY, it must (to be portable) use it as
(setq a (adjust-array a ...))
(unless it separately checked (adjustable-array-p a)).
Of course, it has no effect whatsoever on
those who do not port their code form one so-called "conforming"
implementation to another so-called "conforming" implementation; but
from those who do such porting, we have heard numerous complaints on
precisely such variation.
JonL, I'm not a member of the group that wrote up the proposal, but I
think they should be offended by your repeated implications, such as the
one quoted above, that they totally ignore the needs of programmers
porting applications and of conventional architecture implementations.
I believe Pitman was among those who worked on the latest version of
this proposal, and he is extremely sensitive to such needs; he has been
involved in Macsyma porting for years, recently porting it to CLOE,
which is heavily dependent on declarations for performance. And Gabriel
was also listed among the framers of this proposal, presumably
representing Lucid's interests. So let's keep the discussion technical,
without the mud-slinging.
barmar
∂22-Jun-89 1650 X3J13-mailer No content change. Fixed ugly printing of sec 2.6
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Jun 89 16:47:57 PDT
Date: Thu, 22 Jun 89 15:03:57 PDT
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890622.150357.baggins@almvma>
Subject: No content change. Fixed ugly printing of sec 2.6
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{June 10, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newtheorem{prop}{Proposal}[section]
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from L. Masinter and other members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
To universally identify each character, we utilize a
universal registry of characters which incorporates a
collection of repertoires called {\em character scripts}
as a partitioning of all characters.
That is, each character is included
in one and only one character script.
\footnote{The practical realization of this registry is the
Draft ISO 10646 Coded Character Set Standard. \cite{iso10646}}
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character script and a character label.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
All other character data objects are classified
as {\em non-graphic} (or {\em control}).
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities. For example, while Common LISP is free to
define unique manipulation facilities for characters, character scripts
and coded character sets, it should
not define standard coded character sets nor standard
character scripts.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
A final purpose is to serve as a basis for terminology within the
standard language specification.
\begin{prop}[Passed 03/89]
The terminology introduced in this proposal will be included
in the language specification at the discretion of the editor.
\end{prop}
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices.
The notion of attributes of character
objects within Common LISP has proven to be either not used or
not portable. The essential aspect of the following proposals is
to what extent attributes continue to be supported by the
language specifications.
\begin{prop}[Alternative A, Passed as Modified 03/89]
Remove all discussion of attributes from
the language specification. Add the following discussion:
\begin{quote}
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects. These and other
supported attributes are considered implementation-defined
attributes and if supported by an implementation effect the
action of selected functions.
\end{quote}
All types, constants and functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified as follows:
\begin{itemize}
\item Modify {\clkwd char-=}: If two characters differ in any
implementation-defined attributes, then they are not {\clkwd char-=}.
\item Modify {\clkwd char-<}: If two characters have identical
implementation-defined attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item Modify {\clkwd char-equal}:
The effect, if any, on {\clkwd char-equal} of each
implementation-defined attribute has to be specified as part of
the definition of that attribute (and similarly for
{\clkwd char-not-equal, char-lessp, char-greaterp,
char-not-greaterp, char-not-lessp}).
\item Modify {\clkwd char-upcase} and {\clkwd char-downcase}:
The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve implementation-defined attributes.
\item Modify {\clkwd read}: It is implementation dependent which
attributes are removed from symbol names.
It is implementation dependent which attributes are removed
from characters within double quotes.
\item Modify {\clkwd intern}: It is implementation dependent
which implementation-defined attributes are removed.
\item Modify {\clkwd digit-char}: remove the optional {\em font}
argument.
\item Modify {\clkwd code-char}: remove the optional {\em font}
and {\em bits} arguments.
\item Remove {\clkwd char-font-limit}
\item Remove {\clkwd char-bits-limit}
\item Remove {\clkwd int-char}
\item Remove {\clkwd char-int}
\item Remove {\clkwd char-bits}
\item Remove {\clkwd char-font}
\item Remove {\clkwd make-char}
\item Remove {\clkwd char-control-bit}
\item Remove {\clkwd char-meta-bit}
\item Remove {\clkwd char-super-bit}
\item Remove {\clkwd char-hyper-bit}
\item Remove {\clkwd char-bit}
\item Remove {\clkwd set-char-bit}
\item Remove {\clkwd string-char} and {\clkwd string-char-p}
\item Modify readtable: If implementation-defined attributes
are supported, an implementation need not (but may) allow
for such characters to have syntax descriptions in the readtable.
Otherwise, all characters are representable in the readtable.
\end{itemize}
\end{prop}
\begin{prop}[Alternative B, Passed as Modified 03/89]
This is identical to all of Alternative A (above) except that
the function {\clkwd char-int} is retained.
{\clkwd char-int} returns a non-negative integer encoding the
character object. The manner in which the integer is computed
is implementation dependent. In contrast to {\clkwd sxhash},
the result is not guaranteed independent of the particular
"incarnation" or "core image".
\end{prop}
With the elimination of {\em font} and {\em bits} from the
specification the usefulness of {\clkwd char-code} and {\clkwd
code-char} is diminished. They are no longer needed for constructing
characters.
The portable mechanisms for hashing are provided by
{\clkwd char-int} and {\clkwd sxhash}.
In addition, using {\clkwd char-code-limit} to iterate over
characters is extremely inefficient in implementations that
support large or user-defined repertoires.
\begin{prop}[Alternative C, Failed 03/89]
This an amendment to Alternative B (above).
\begin{itemize}
\item Remove {\clkwd char-code-limit}
\item Remove {\clkwd char-code}
\item Remove {\clkwd code-char}
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Standard and Semi-Standard Characters}
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional mechanisms,
such as in \cite{kurokawa88}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\begin{prop}[Passed 03/89]
The discussion of standard characters is
replaced by the following:
Common LISP requires all implementations to support a {\em standard}
character subrepertoire.
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic Id categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
Id & Glyph & Name or description
& Id & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\end{prop}
The definition of semi-standard characters has been of minimum
practical use since implementations may or may not support any
of these characters. The essential feature is that, when
supported, they have a predictable treatment by the reader.
\begin{prop}[Failed 03/89]
Remove all discussion of semi-standard characters.
Add that in implementations supporting non-graphic characters other
than \#$\backslash${\clkwd Newline}, the {\clkwd read} function
is required to treat those as
whitespace characters.
\end{prop}
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements need to
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to allow specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarly for the {\clkwd simple-string}
type specifier). This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
\begin{prop}[Passed as Modified 03/89]
Define {\clkwd base-character} as {\clkwd
(upgraded-array-element-type 'standard-char)} and
{\clkwd extended-character} as type {\clkwd
(and character (not base-character))}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
extended-character)}
are referred to as {\em extended characters}.
\end{prop}
This establishes the relationship between the string encoding and
array upgrading strategies of the implementation and
the important character types.
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
\item
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}
\end{itemize}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, may
be privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However,
the proposal emphasizes that whether a character is "base" to
Common LISP depends on the way that an implementation represents
strings, and not any other properties of the implementation or the
host operating system. Imagine two implementations, one of which
encodes all strings as 16-bit characters, and another which has
two kinds of strings: 8-bit strings and 16-bit strings. In the
first implementation, the {\clkwd base-character} is
{\clkwd character}: there's only one kind of string. In the
second implementation, the {\clkwd base-character} would be those
that could be stored in an 8-bit string, and it would be a proper
sub-type of {\clkwd character}.
\subsection{String Type}
\begin{prop}[Passed 03/89]
The {\clkwd string} type
is defined as
a union type. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of {\clkwd character}.
{\clkwd string} used as a type specifier for object creation
means {\clkwd (vector character)}.
\end{prop}
\begin{prop}[Passed as Modified 03/89]
The following string
subtypes are
distinguished with standardized names.
\begin{itemize}
\item {\clkwd base-string} is equivalent to {\clkwd (vector
base-character)}.
Strings of type {\clkwd base-string} are referred to as {\em base
strings}.
\item {\clkwd base-string} is valid as a type specifier that
abbreviates.
\end{itemize}
\end{prop}
\begin{prop}[Passed as Modified 03/89]
Define {\clkwd simple-string} as a union type.
A simple
string is a specialized simple
one dimensional array whose elements are of type
{\clkwd character} or a subtype of character.
{\clkwd simple-string} used as a type specifier for object creation
means {\clkwd (simple-array character ({\em size}))}.
\end{prop}
\begin{prop}[Passed as Modified 03/89]
The following simple string
subtypes are
distinguished with standardized names:
\begin{itemize}
\item {\clkwd simple-base-string} is equivalent to {\clkwd
(simple-array base-character (*)). simple-base-string} is a subtype
of {\clkwd base-string}.
\item {\clkwd simple-base-string} is
valid as a type specifier that abbreviates.
\end{itemize}
\end{prop}
A base string is the most efficient string which can hold
the standard characters.
All Common LISP functions defined to operate on strings treat
all strings strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coercion to an extended string.}
An implementation may support string subtypes in addition
to {\clkwd base-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic characters
might provide as extended characters:
\begin{itemize}
\item {\clkwd string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd string}.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
\begin{prop}[Passed 03/89]
Extend the {\clkwd make-string} function to allow an
{\clkwd element-type} keyword argument:
\begin{itemize}
\item {\clkwd make-string} {\em size}
{\clkwd \&key :initial-element :element-type} [Function]
This returns a simple string of length {\em size}, each
of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be
initialized in an implementation-dependent way. The
{\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type. If
{\clkwd :element-type} is omitted, the type {\clkwd character}
is the default.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Character Naming}
A Common LISP program should be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of character registry is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character script, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
\begin{prop}[Passed 03/89]
Common LISP character codes are composed from a character script and
a character label. The convention by which a character label and
character script compose a character code is implementation
dependent.
\end{prop}
The naming and content of the standard character scripts
is left unspecified by this proposal.
\footnote{The only constraint is that character scripts and
labels be named using only the Latin capital letters A-Z, hyphen and
digits 0-9.}
Below are some candidate character script names:
\begin{itemize}
\item latin
\item extended-latin
\item international-african-alphabet
\item extended-symbols
\item diacritics
\item cyrillic-for-major-languages
\item cyrillic-for-minor-languages
\item greek
\item arabic
\item armenian
\item georgian
\item hebrew
\item hiragana-symbols
\item katakana
\item control (meaning the collection of standard text communication
control codes)
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive.
\footnote{In fact, they are simply 15 of the scripts represented
within
\cite{iso10646}}
The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?). It is application
programs which require a reliable definition of the
script names and their constituents. The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.
\begin{prop}
Standardized Character Scripts are fixed;
an implementation may not extend a standard script's
constituent set of characters beyond the
standard definition.
An implementation may provide support for all or part of any
character script
and may provide new character scripts which include characters
having unique semantics (i.e. not defined in any standard
character script).
Implementation scripts must be uniquely
named using only Latin capital letters A-Z, hyphen and digits 0-9.
An implementation must document the scripts it supports.
For each script supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions. Character labels must be uniquely
named using only Latin capital letters A-Z, hyphen and digits 0-9.
\item Reader Canonicalization.
\footnote{Any mechanisms by which the {\clkwd read} function treats
distinct characters as equivalent.}
\item Effect of character predicates. In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
supported are documented.
\end{itemize}
\end{prop}
We introduce new functions to
compose and decompose character objects. We also extend the
{\clkwd characterp} predicate to
support testing
membership of a character in a given character repertoire.
\footnote{
For example,
testing membership in the Japanese Katakana character repertoire.
}
Functions {\clkwd all-character-script-names}
and {\clkwd all-character-language-names}
are added to
allow application determination of
implementation supported character repertoires.
\begin{prop}
Add the type specifier and (modified) type predicate:
\begin{itemize}
\item {\clkwd (character {\em repertoire})}
This denotes a character type specialized to members of the
specified repertoire. {\em Repertoire} may be {\clkwd :base}
or {\clkwd :standard} or any supported character repertoire
name (a symbol), or a list of names.
{\clkwd (character :base)} is equivalent to {\clkwd base-character}
and
{\clkwd (character :standard)} is equivalent to {\clkwd standard-char}
\item {\clkwd (characterp {\em object} \&optional
{\em repertoire})}
If {\em repertoire} is omitted, {\clkwd characterp} is true if
{\em object} is a character object, and otherwise is false. If
a {\em repertoire} argument is specified, {\clkwd characterp}
is true if {\em object} is a character object and a member
of the specified repertoire, and otherwise is false. {\em Repertoire}
may be any supported character repertoire name (a symbol)
or the names {\clkwd :base} or {\clkwd :standard}.
{\clkwd (characterp x :standard)} is equivalent to
{\clkwd (standard-char-p x)}.
{\clkwd (characterp x :base)} is true if x is a member of the
base character repertoire.
\end{itemize}
\end{prop}
\begin{prop}
Add the following functions:
\begin{itemize}
\item {\clkwd all-character-script-names} {\em [Function]}
The value of {\clkwd all-character-script-names} is a list
of all character script names (symbols) supported by
the implementation. All character scripts are repertiores.
\item {\clkwd all-character-language-names} {\em [Function]}
The value of {\clkwd all-character-language-names} is a list
of all character language names (symbols) supported by
the implementation. All character languages are repertoires.
\footnote{International agreement is also necessary to
establish language repertoires (eg. Canadian-French) and
their respective sorting algorithms, date formats, etc.
\cite{ison622}, \cite{ison623}}
\item {\clkwd char-label} {\em char [Function]}
{\clkwd char-label} returns a string representing the character
label of {\em char}. It is an error if the argument is
not a character object.
\item {\clkwd char-script-name} {\em char [Function]}
{\clkwd char-script-name} returns a string representing the character
script to which {\em char} belongs. It is an error if the
argument is not a character object.
\item {\clkwd find-char} {\em script label [Function]}
{\clkwd find-char} returns a character object. The arguments
{\em script} and {\em label} are names (symbols) of
a character script and label. {\em label} uniquely
identifies a character within the character script named
{\em script}. If the implementation does not support the
specified character, {\clkwd nil} is returned.
\end{itemize}
\end{prop}
\begin{prop}
Character
names accepted and constructed by {\clkwd char-name, name-char}, and
{\clkwd \#$\backslash$} are extended to include character script
names of the form {\em script:label}.
\end{prop}
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
There are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
Given that multiple coded character sets exist, it is useful
to provide portable mechanisms based on their definitions.
\begin{prop}
Add the following functions:
\begin{itemize}
\item {\clkwd char-external-code} {\em char name [Function]}
{\clkwd char-external-code} returns the non-negative integer
representing the encoding of the character {\em char} in the
coded character set named by {\em name}, a symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain the character,
{\clkwd nil} is returned.
\item {\clkwd find-external-char} {\em name index [Function]}
{\clkwd find-external-char} returns a character object.
The argument {\em index} is a non-negative integer
representing the encoding of a character in the
coded character set named by {\em name}, a symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain the character,
{\clkwd nil} is returned.
\end{itemize}
\end{prop}
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
Which coded character sets and encoding schemes
are supported by the overall computing system and the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.
\begin{prop}
Add the additional keyword argument to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-format}
which
specifies a name, or list of names (keyword symbols)
indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
The default value is {\clkwd :default} and is
implementation defined but must include the
base characters.
As many coded character set names must be provided as the
implementation requires for that external coding convention.
Coded character set names must
include the full reference number and approval year. For example,
:ISO8859P1V1987 and :ISO6937P2V1983.
All implementation recognized schemes are formed from
the Latin uppercase A-Z, hyphen, and digit 0-9 characters.
\end{itemize}
This argument is provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream. (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide atopopriate line division behavior
for all character streams.)
\end{prop}
The existing default for the {\clkwd :element-type} argument of
{\clkwd open} is {\clkwd string-char}. This is no longer appropriate
given the elimination of {\clkwd string-char} within the
standard specification.
\begin{prop}[Withdrawn 03/89]
Modify the {\clkwd :element-type} argument to {\clkwd open} as follows:
\begin{itemize}
\item Add {\clkwd base-character} as a valid type.
\item Remove {\clkwd string-char} as a valid type.
\end{itemize}
\end{prop}
The following alternative is consistent with the general
premise that portability is emphasized over efficiency.
\begin{prop}[Alternative A]
The default for the {\clkwd :element-type} argument of {\clkwd open}
is {\clkwd character}.
\end{prop}
The following alternative (B), allows implementations to match
the behavior of {\clkwd open} to the expected behavior of
their file systems.
\begin{prop}[Alternative B]
The default for the {\clkwd :element-type} argument of {\clkwd open}
is implementation defined as a super-type
of {\clkwd base-character}
and a sub-type of {\clkwd character}.
\end{prop}
\begin{prop}
Modify the following functions:
\begin{itemize}
\item {\clkwd with-output-to-string} if no string argument is
provided, produces a stream that accepts all characters and returns
a string of the most specialized type
that accommodates the characters that were actually output.
\item {\clkwd make-string-output-stream}
produces a stream that accepts all characters and returns
(via {\clkwd get-output-stream-string})
a string of the most specialized type
that accommodates the characters that were actually output.
\end{itemize}
\end{prop}
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
This function is necessary
to determine if strings can be written to fixed length
fields in databases. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
\begin{prop}
Add the following function:
\begin{itemize}
\item {\clkwd file-string-length}
{\em file-stream object} [Function]
{\clkwd file-string-length} returns a non-negative integer
which represents the difference between what {\clkwd
(file-position {\em file-stream})} would be after writing the object
and its current value, or {\clkwd nil} if this cannot be
determined. {\em object} must be a string or character.
This integer corresponds to the current state of the stream and
may change if there has been intervening output.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Miscellaneous}
In the process of creating this document, some comments were found
within CLtL which seem appropriate to modify independently of
the other proposals mentioned previously. For each, we identify
the existing statement of CLtL and the recommended change.
\begin{prop}[Passed 03/89]
Chapter 2 Data Types (Page 12)
\begin{itemize}
\item {\bf replace}
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\item {\bf with}
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\end{itemize}
\end{prop}
\begin{prop}[Passed as Modified 03/89]
Chapter 2 Symbols (Page 25)
\begin{itemize}
\item {\bf clarify}
\cltxt
A symbol may have any character in its print name.
\end{itemize}
\end{prop}
\begin{prop}[Passed 03/89]
Chapter 10 Symbols (Page 163)
\begin{itemize}
\item {\bf replace}
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\item {\bf with}
\cltxt
It is an error to alter a symbol's print name.
\end{itemize}
\end{prop}
\begin{prop}[Passed 03/89]
Chapter 10 The Print Name (Page 168)
\begin{itemize}
\item {\bf replace}
\cltxt
It is an extremely bad idea to modify a string being used
as the print name of a symbol.
\item {\bf with}
\cltxt
It is an error to modify a string being used
as the print name of a symbol.
\end{itemize}
\end{prop}
\begin{prop}[Passed 03/89]
Chapter 14 Simple Sequence Functions (Page 249, make-sequence)
\begin{itemize}
\item{\bf append}
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO DP 10646]{iso10646} ISO,
{\em
Draft Proposal Information processing -- Multiple octet coded
character set
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[ISO N622R]{ison622} ISO,
{\em
Programming Language Recommendations for International
Character Handling
},
Joint meeting of ISO SC2, SC22, SC21/WG3, Geneva 26-28 (1989).
\bibitem[ISO N623R]{ison623} ISO,
{\em
Requirements on Coded Characters Sets for International
Characters
},
Joint meeting of ISO SC2, SC22, SC21/WG3, Geneva 26-28 (1989).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂23-Jun-89 0642 X3J13-mailer June meeting registration list
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Jun 89 06:41:58 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA12227g; Fri, 23 Jun 89 06:40:00 PDT
Received: by challenger id AA03659g; Fri, 23 Jun 89 06:41:35 PDT
Date: Fri, 23 Jun 89 06:41:35 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906231341.AA03659@challenger>
To: x3j13@sail.stanford.edu
Subject: June meeting registration list
X3J13 Attendee Information
06/23/89
Name Institute Paid L1 L2 L3
Kim Barrett -0- -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Kathy Chapman DEC -0- - - -
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI -0- y y y
George Hadden Honeywell -0- y y y
Steve Haflich Franz, Inc. -0- y y y
Jim Kempf Sun MicroSystems -0- y y y
Gregor Kiczales Xerox Corp. -0- y y y
Kerry Kimbrough -0- -0- - - -
Timothy Koschmann Southern Illinois -0- y y y
Aaron Larson Honeywell 80.00 y y y
Ray Lim NASA Ames -0- - - -
David Loeffler MCC 80.00 y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines 80.00 y y y
Robert Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Dan Pierson Encore Computer -0- y y y
Kent Pitman Symbolics -0- y y y
Guy Steele Thinking Machines -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂23-Jun-89 0645 X3J13-mailer Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Jun 89 06:45:03 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA12253g; Fri, 23 Jun 89 06:43:11 PDT
Received: by challenger id AA03673g; Fri, 23 Jun 89 06:44:42 PDT
Date: Fri, 23 Jun 89 06:44:42 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906231344.AA03673@challenger>
To: x3j13@sail.stanford.edu
Subject: Agenda DRAFT
and very drafty at that. It's certain this will change by Monday.
See you all in Palo Alto.
---jan---
X3J13 Committee Meeting Agenda DRAFT
June 26 - 29, 1989
1 Call to Order, Monday, June 26, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Waters/Perdue series and generated proposals vote, Guy Steele
7 Coffee Break 10:30
8 ISO Report, Dick Gabriel (1 hour)
9 LUNCH 12:00
10 Window System Standard, Jim Kempf (2 hours)
11 Break
12
13 Recess, 5:00pm
14 Call to Order, Tuesday, June 27 9:00am
15 Compiler Subcommittee Report, Sandra Loosemore (4 hours)
16 Coffee Break 10:30am
17 Compiler Subcommittee Report continuation
18 Lunch 12:00
19 2:00 Cleanup Committee Report, Kent Pitman (3 hours)
20 Break 3:00
21 Recess 5:00
22 Call to Order, Wednesday, 6/28, 9:00am
23 Drafting Committee Report, Kathy Chapman (4 hours)
24 Coffee Break 10:30
25 Drafting Committee Report Continuation
26 Lunch 12:00
27 Drafting Committee Report Continuation
28 Characters Proposal, Thom Linden (2 hours)
29 Break 3:00
30 Characters Proposal continuation
31 Adjournment 5:00pm
∂23-Jun-89 1048 X3J13-mailer Amendments
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89 10:48:23 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 616027; 23 Jun 89 13:50:03 EDT
Date: Fri, 23 Jun 89 13:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Amendments
To: X3J13@sail.stanford.edu
Supersedes: <19890623174627.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Comments: Previous copy was sent to "X3J13" in the wrong "package", i.e. the wrong people.
Message-ID: <19890623174823.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
I spent the morning preparing amended versions of the issues
ADJUST-ARRAY-NOT-ADJUSTABLE, DATA-IO, MAP-INTO, PATHNAME-LOGICAL,
and PATHNAME-WILD. I will mail these electronically in a moment,
and will also bring copies to the meeting. These changes
just reflect the discussion that followed upon the earlier
versions that were mailed.
∂23-Jun-89 1049 X3J13-mailer Issue: DATA-IO (version 8)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89 10:49:27 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 616030; 23 Jun 89 13:51:22 EDT
Date: Fri, 23 Jun 89 13:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DATA-IO (version 8)
To: X3J13@sail.stanford.edu
Message-ID: <19890623174939.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
This issue has been amended based on last minute discussion. Clarify
that "readable" is defined in terms of "similar as constants" as
defined in issue CONSTANT-COMPILABLE-TYPES. This modifies point 1a and
adds new points 1d, 1e, and 1f. The interaction between *PRINT-READABLY*
and other printer control variables has been tightened; this modifies
point 1c and deletes the old points 1d and 1e.
Issue: DATA-IO
References: CLtL pp.360, 370, 382
Related issues: CONSTANT-COMPILABLE-TYPES
Category: ADDITION
Edit history: Version 1, 9-May-89, by Moon
Version 2, 10-May-89, by Moon
(clarify ambiguities, add PRINT-UNREADABLE-OBJECT)
Version 3, 18-May-89, by Moon (respond to KMP's comments)
Version 4, 21-May-89, by Moon (almost-final cleanup)
Version 5, 22-May-89, by Pitman (``never say never'')
Version 6, 23-May-89, by Moon (final cleanup)
Version 7, 18-Jun-89, by Moon (more fixes based on
discussion in the cleanup subcommittee)
Version 8, 23-Jun-89, by Moon (fixes based on discussion)
Problem description:
Storing data in textual form in files, as Lisp expressions, is common
practice but has some pitfalls. Files can be unreadable if #<...> syntax
is written by the printer, or if the reader syntax or package varies
between writing and reading. Files of data intended to be carried from
one Lisp implementation to another can fail to read correctly if
implementation-dependent syntax extensions get used when not intended.
CLtL p.370 recommends that unreadable objects be printed with #<...>
syntax including implementation-dependent information. Now that users
can write their own PRINT-OBJECT methods, a way is needed for such
methods to print this syntax without any implementation-dependent coding.
Proposal (DATA-IO:ADD-SUPPORT):
1a. Add a new variable *PRINT-READABLY*. Add a corresponding keyword
argument :READABLY to WRITE. The default value of *PRINT-READABLY* is
NIL. If *PRINT-READABLY* is true, then printing any object produces a
printed representation that the reader will accept. The reader will
produce an object that is "similar as a constant" to the object that
was printed. The term "similar as a constant" is defined in the
already accepted compiler issue CONSTANT-COMPILABLE-TYPES:SPECIFY.
If *PRINT-READABLY* is true and printing a readable printed
representation is not possible, the printer signals an error of type
PRINT-NOT-READABLE rather than using an unreadable syntax such as #<...>.
The printed representation produced when *PRINT-READABLY* is true might
or might not be the same as the printed representation produced when
*PRINT-READABLY* is false.
1b. All methods for PRINT-OBJECT must obey *PRINT-READABLY*. This
includes both user-defined methods and implementation-defined methods.
1c. If *PRINT-READABLY* is true and another printer control variable
(*PRINT-LENGTH*, *PRINT-LEVEL*, *PRINT-ESCAPE*, *PRINT-GENSYM*,
*PRINT-ARRAY*, or an implementation-defined printer control variable)
would cause the requirements of point 1a to be violated, that other
printer control variable is ignored.
1d. The printing of interned symbols is not affected by *PRINT-READABLY*,
regardless of the outcome of issue COMPILE-FILE-SYMBOL-HANDLING
(referenced by issue CONSTANT-COMPILABLE-TYPES).
1e. Note that the "similar as a constant" rule for readable printing
implies that #A or #( syntax cannot be used for arrays of element-type
other than T. An implementation will have to use another syntax or
signal a PRINT-NOT-READABLE error. A PRINT-NOT-READABLE error will not
be signalled for strings or bit-vectors.
1f. Readable printing of structures and standard-objects is controlled
by their PRINT-OBJECT method, not by their MAKE-LOAD-FORM method.
"Similarity as a constant" for these objects is application dependent
and hence is defined to be whatever these methods do.
2. Add a new reader control variable, *READ-EVAL*, whose default value is
T. If *READ-EVAL* is NIL, the #. reader macro signals an error. If
*READ-EVAL* is false and *PRINT-READABLY* is true, any PRINT-OBJECT
method that would output a #. reader macro either outputs something
different or signals an error of type PRINT-NOT-READABLE.
3. Add a new macro:
WITH-STANDARD-IO-SYNTAX &body body [Macro]
Within the dynamic extent of <body>, all reader/printer control
variables, including any implementation-defined ones not specified by
Common Lisp, are bound to values that produce standard read/print
behavior. The values for Common Lisp specified variables are:
*PACKAGE* The USER package
*PRINT-ARRAY* T
*PRINT-BASE* 10
*PRINT-CASE* :UPCASE
*PRINT-CIRCLE* NIL
*PRINT-ESCAPE* T
*PRINT-GENSYM* T
*PRINT-LENGTH* NIL
*PRINT-LEVEL* NIL
*PRINT-PRETTY* NIL
*PRINT-RADIX* NIL
*PRINT-READABLY* T
*READ-BASE* 10
*READ-DEFAULT-FLOAT-FORMAT* SINGLE-FLOAT
*READ-EVAL* T
*READ-SUPPRESS* NIL
*READTABLE* The standard readtable
The values returned by WITH-STANDARD-IO-SYNTAX are the values
of the last body form, or NIL if there are no body forms.
4. Add a new macro:
PRINT-UNREADABLE-OBJECT (object stream &key type identity) [Macro]
&body body
Output a printed representation of <object> on <stream>, beginning with
"#<" and ending with ">". Everything output to <stream> by the <body>
forms is enclosed in the angle brackets. If :type is true, the body
output is preceded by a brief description of the object's type and a
space character. If :identity is true, the body output is followed by
a space character and a representation of the object's identity,
typically a storage address.
If *PRINT-READABLY* is true, PRINT-UNREADABLE-OBJECT signals an error
of type PRINT-NOT-READABLE without printing anything.
The <object>, <stream>, :type, and :identity arguments are all evaluated
normally. :type and :identity default to false. It is valid to omit
the <body> forms. If :type and :identity are both true and there are no
<body> forms, only one space character separates the type and the identity.
The value returned by PRINT-UNREADABLE-OBJECT is NIL.
5. Add a new condition type:
PRINT-NOT-READABLE [Type]
Errors which occur during output while *PRINT-READABLY* is true, as a
result of attempting to output a printed representation that cannot be
read back, should inherit from this type. This is a subtype of ERROR.
The init keyword :OBJECT is supported to initialize the slot containing
the object being printed, which can be accessed using
PRINT-NOT-READABLE-OBJECT.
Examples:
;; Example #1: Reliable Write-Read
(WITH-OPEN-FILE (FILE pathname :DIRECTION :OUTPUT)
(WITH-STANDARD-IO-SYNTAX
(PRINT DATA FILE)))
; ... Later, in another Lisp:
(WITH-OPEN-FILE (FILE pathname :DIRECTION :INPUT)
(WITH-STANDARD-IO-SYNTAX
(SETQ DATA (READ FILE))))
;; Example #2: Use of PRINT-UNREADABLE-OBJECT
;; Note that in this example, the precise form of the output
;; is really implementation-dependent.
(DEFMETHOD PRINT-OBJECT ((OBJ AIRPLANE) STREAM)
(PRINT-UNREADABLE-OBJECT (OBJ STREAM :TYPE T :IDENTITY T)
(PRINC (TAIL-NUMBER OBJ) STREAM)))
(PRINT MY-AIRPLANE)
#<Airplane NW0773 36000123135> ;in Implementation A
;or
#<FAA:AIRPLANE NW0773 17> ;in Implementation B
Rationale:
1. *PRINT-READABLY* is important so that errors involving data with no
readable printed representation are detected when writing the file, not
later on when the file is read.
*PRINT-READABLY* is different from *PRINT-ESCAPE* because output printed
with escapes only has to be generally recognizable by humans, whereas
output printed readably has to be reliably recognizable by computers.
2. Binding *READ-EVAL* to NIL is useful when reading data that came from
an untrusted source, such as a network or a user-supplied data file, to
prevent the #. reader macro from being exploited as a "Trojan horse" to
cause arbitrary forms to be evaluated.
3. Providing the WITH-STANDARD-IO-SYNTAX macro to bind all the variables,
instead of using LET and explicit bindings of the existing variables,
ensures that nothing is overlooked and avoids problems with
implementation-defined reader/printer control variables.
If the user wishes to use a non-standard value for some variable, such as
*PACKAGE* or *READ-EVAL*, it can be bound by LET inside the body of
WITH-STANDARD-IO-SYNTAX. Similarly, if the user dislikes the somewhat
arbitrary choices of values for *PRINT-CIRCLE* and *PRINT-PRETTY*, they
can be bound to the preferred values inside the body.
4. PRINT-UNREADABLE-OBJECT allows user-written PRINT-OBEJCT methods to
adhere to implementation-specific style without requiring users to write
implementation-dependent code.
5. Defining a specific condition type associated with *PRINT-READABLY*
makes it possible for programs to handle the condition and recognize
the offending object.
Current practice:
Symbolics Genera has had these features for many years, except with
different names. For instance, WITH-STANDARD-IO-SYNTAX is named
WITH-STANDARD-IO-ENVIRONMENT and binds *PACKAGE* to a non-standard
package. The proposed new names are better than the Genera names.
Genera's WITH-STANDARD-IO-ENVIRONMENT also disables #., to prevent trojan
horses, since #. could evaluate an arbitrary form. This is particularly
important for network protocols. WITH-STANDARD-IO-SYNTAX does not bind
*READ-EVAL* to NIL, because that would prevent using #. in the printer
for common datatypes, which is current practice in some implementations
for printing PATHNAMEs or RANDOM-STATEs.
In Genera, PRINT-UNREADABLE-OBJECT is called SYS:PRINTING-RANDOM-OBJECT
and takes slightly different arguments. In PCL, PRINT-UNREADABLE-OBJECT
is called PCL:PRINTING-RANDOM-THING.
Cost to Implementors:
Very small, these features are all easy to add. If #. is output by any
system-supplied print methods, they might want to invent a different
syntax, however that is not required by this proposal.
Cost to Users:
None if they don't use the feature. Otherwise just the cost of
supporting *PRINT-READABLY* or using PRINT-UNREADABLE-OBJECT in their
PRINT-OBJECT methods.
Cost of non-adoption:
There will be no reliable, standard way to write data into a file.
Performance impact:
Negligible. Entering WRITE may be slightly slower since there is
one more keyword argument to parse and one more special variable
to bind before calling PRINT-OBJECT.
Benefits:
Data can be written into files reliably without resorting to
implementation-specific programming.
Esthetics:
Mildly improved.
Discussion:
Pitman and Moon support this proposal.
∂23-Jun-89 1050 X3J13-mailer Issue: MAP-INTO (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89 10:50:30 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 616033; 23 Jun 89 13:52:24 EDT
Date: Fri, 23 Jun 89 13:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAP-INTO (version 3)
To: X3J13@sail.stanford.edu
Message-ID: <19890623175044.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is a new issue. It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
This version has been revised based on BarMar's suggestions: It can
be called without any argument sequences; if the result sequence is
a vector with a fill-pointer, the fill-pointer's current value is
ignored, and the fill-pointer is set to the number of results produced.
Issue: MAP-INTO
References: none
Related issues: BIT-ARRAY-FUNCTIONS
Category: ADDITION
Edit history: 23-May-89, version 1 by Moon
19-Jun-89, version 2 by Moon (fix arglist)
23-Jun-89, version 3 by Moon (include BarMar's suggestions)
Problem description:
The function MAP is very useful but can be a source of inefficiency
because it conses the result. Sometimes the user has storage
already allocated in which the result could be stored.
Proposal (MAP-INTO:ADD-FUNCTION):
Add the following function:
MAP-INTO result-sequence function &rest sequences [Function]
Destructively modifies the result-sequence to contain the results of
applying function to each element in the argument sequences in turn.
Returns result-sequence.
The arguments result-sequence and each element of sequences can each be
either a list or a vector (one-dimensional array). Note that NIL is
considered to be a sequence, of length zero. If result-sequence and
each element of sequences are not all the same length, the iteration
terminates when the shortest sequence is exhausted. If result-sequence
is a vector with a fill-pointer, the fill-pointer is ignored when
deciding how many iterations to perform, and afterwards the
fill-pointer is set to the number of times function was applied.
If result-sequence is longer than the shortest element of sequences,
extra elements at the end of result-sequence are left unchanged.
MAP-INTO differs from MAP in that it modifies an existing sequence
rather than creating a new one. In addition, MAP-INTO can be called
with only two arguments, while MAP requires at least three arguments.
If result-sequence is NIL, MAP-INTO immediately returns NIL, since
NIL is a sequence of length zero.
If BIT-ARRAY-FUNCTIONS:NO-NEW-FUNCTIONS passes, then MAP-INTO will
allow result-sequence and each element of sequences to be mappables
all of the same rank.
The function must take at least as many arguments as there are
sequences provided.
If function has side effects, it can count on being called first on all
of the elements with index 0, then on all of those numbered 1, and so
on.
Examples:
(map-into x #'+ x y)
(map-into q #'cons keys vals)
(map-into syms #'gensym)
Rationale:
MAP-INTO is a simple way to express reuse of storage that is
stylistically consistent with the rest of Common Lisp.
Current practice:
Symbolics Genera 7.2 implements the proposal.
Cost to Implementors:
Small.
Cost to Users:
None.
Cost of non-adoption:
Small.
Performance impact:
None.
Benefits:
More expressive language.
Esthetics:
User programs won't have to write the above examples as
(loop for xx on x and yy in y do
(setf (car xx) (+ (car xx) yy)))
or something else about equally horrible.
Discussion:
None.
∂23-Jun-89 1049 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 11)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89 10:49:01 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 616029; 23 Jun 89 13:50:43 EDT
Date: Fri, 23 Jun 89 13:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 11)
To: X3J13@sail.stanford.edu
Message-ID: <19890623174903.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Version 5 of this proposal passed with amendments at the January
1989 X3J13 meeting. However, the amendments were found to result
in an inconsistent proposal, and it was also pointed out that some
related problems with simple-arrays were not addressed. Since then
there has been a great deal of private discussion, and review of
various versions of the proposal including ones earlier than 5.
The result is this proposal, which is believed to be acceptable to
everyone and is being offered for a vote in June to replace the
January version that was already voted in.
This version has been amended based on last minute discussion: the
statement that ADJUST-ARRAY, when it copies, can destroy the original has
been removed. A remark about VECTOR-PUSH-EXTEND has been added. These
changes are in points 4 and f. In the discussion section I mentioned
suggestions to get rid of ADJUSTABLE-ARRAY-P.
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289),
simple strings with fill pointers (p299),
VECTOR-PUSH-EXTEND (p296)
Category: CLARIFICATION and CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
6-Jun-89, Version 10, by Moon and Gabriel, do over.
23-Jun-89, Version 11, by Moon, two little corrections
Problem Description:
There are a number of unclear passages in CLtL related to simple arrays
and adjustable arrays. There is disagreement on precisely how these
passages are to be interpreted, and no one is happy with the fact that
ADJUST-ARRAY works only on an implementation-dependent subset of arrays.
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288 says that
``the argument, if specified and not NIL, indicates that it must be
possible to alter the array's size dynamically after it is created. This
argument defaults to NIL.'' The description of the :ADJUSTABLE option
does not say what MAKE-ARRAY will do if the argument is unsupplied or
explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is true ``if
the argument (which must be an array) is adjustable, and otherwise
false.'' However, the description of MAKE-ARRAY makes it clear that this
is not necessarily the same as asking if the array was created with
:ADJUSTABLE T. If ADJUSTABLE-ARRAY-P returns NIL, you know that
:ADJUSTABLE NIL was supplied (or no :ADJUSTABLE option was supplied), but
if ADJUSTABLE-ARRAY-P returns T, then there is no information about
whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is ``not
permitted to call ADJUST-ARRAY on an array that was not created with the
:ADJUSTABLE option.'' This is inconsistent with ADJUSTABLE-ARRAY-P.
The definition of SIMPLE-ARRAY on p.28 says ``an array that is not
displaced to another array, has no fill pointer, and is not to have its
size adjusted dynamically after creation is called a simple array.''
It is left unclear whether this is an implication or an equivalence,
i.e. whether there can be other simple arrays as well.
CLtL p.299 appears to refer to simple strings with fill pointers,
suggesting that it is an implication, but similar language is used for
equivalences in other parts of CLtL.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY)
1. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
2. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
3. It is permitted to call ADJUST-ARRAY on any array. (Remove the
restriction documented at the bottom of p.297.)
4. If ADJUST-ARRAY is applied to an array created with :ADJUSTABLE true,
the array returned is EQ to its first argument. It is not specified
whether ADJUST-ARRAY returns an array EQ to its first argument for any
other arrays. If the array returned by ADJUST-ARRAY is not EQ to its
first argument, the original array is unchanged and does not share
storage with the new array.
5. The predicate ADJUSTABLE-ARRAY-P is true if and only if ADJUST-ARRAY
will return a value EQ to this array when given this array as its first
argument.
Clarifications and Logical Consequences:
a. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
b. There is no specified way to create an array that is non-simple.
c. The definition of SIMPLE-ARRAY on p.28 is taken to be an implication,
not an equivalence. This is either a clarification or a change depending
on one's prior reading of that definition.
d. The meaning of ADJUSTABLE-ARRAY-P is changed.
e. As with such functions as DELETE and NCONC, textbooks should
instruct programmers to be careful to receive the value returned by
ADJUST-ARRAY, as it might not be EQ to the first argument.
f. VECTOR-PUSH-EXTEND still signals an error if given a non-adjustable
array. ADJUST-ARRAY's new feature of making a copy cannot be used
by VECTOR-PUSH-EXTEND, since there is no way to return the copy to
the caller.
Rationale:
Points 3 and 4 eliminate the problem of ADJUST-ARRAY only working on a
subset of arrays, by changing it to work on all arrays. It remains
implementation-dependent whether the array is modified in place or
copied, i.e. whether the result is EQ to the argument, however many other
functions in Common Lisp have similar implementation-dependent behavior.
Implementation-dependent storage allocation or reuse is considered
more benign than implementation-dependent applicability of an operation.
Point 3 recognizes that ADJUST-ARRAY offers features that are offered by
no other function and which are useful in cases involving non-adjustable
arrays (for what amounts to copying). This change would allow an
expression such as:
(SETQ X (ADJUST-ARRAY X ...))
to work reliably. Those desiring the old behavior could do:
(IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
(NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
(ERROR "Array cannot be adjusted."))
to get the old style error checking.
Point 5 recycles the name ADJUSTABLE-ARRAY-P as a test for whether an
array is adjusted in place or by copying.
Point 2 preserves the raison d'etre of simple arrays, which is to provide
a portable interface to implementation-dependent specialized arrays that
trade decreased functionality for faster access. A proposed alternative
was to specify a way to create an array that is guaranteed not to be
simple. This would have made (typep (make-array ...) 'simple-array)
return the same value in all implementations, but would have required
large changes to some implementations and would be of little benefit to
users. Users need to know that certain arrays are simple, so they can
put in declarations and get higher performance, but users have no need to
be able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable.
Examples:
1. The following program is conforming.
(defun double (a)
(adjust-array a (* (length a) 2)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
3. The following program is non-conforming. The consequences of this
program are undefined because the type declaration is violated in some
implementations.
(let ((a (make-array 100 :adjustable t)))
(declare (simple-array a))
(frob a))
Current Practice:
Every correct CLtL implementation conforms to points 1 and 2. It is
unlikely that any implementation currently exists that conforms to points
3, 4, and 5. Points 3 and 4 involve additions to an implementation to
support the copying form of ADJUST-ARRAY. Point 5 may involve a change
to ADJUSTABLE-ARRAY-P or may be able to use the existing implementation
of the function.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is a SIMPLE-ARRAY.
The arrays that are internally simple in Symbolics Genera are a different
subset of arrays from the type SIMPLE-ARRAY, because simplicity in that
implementation depends on the rank and total-size as well as on the
fill-pointer and displacement, thus Genera does not use the type
SIMPLE-ARRAY for anything.
Lucid, IIM, Ibuki, and Symbolics Cloe make :ADJUSTABLE NIL arrays
non-adjustable in all cases, and make every array non-simple that CLTL
does not require to be simple.
Macintosh Allegro Common Lisp v1.2 makes :ADJUSTABLE NIL arrays
non-adjustable in all cases, makes all arrays of rank other than 1
non-simple (violating point 1), and makes every array non-simple that
CLTL does not require to be simple.
Cost to Implementors:
The change to ADJUSTABLE-ARRAY-P is easy. The change to ADJUST-ARRAY may
involve some complex coding but should not be a large task. No changes
are required to anything connected with SIMPLE-ARRAY.
Cost to Users:
None in code that does not call ADJUSTABLE-ARRAY-P. This is a fully
upward-compatible change from the user's standpoint.
Benefits:
Programs that use simple arrays and/or adjust arrays will be easier
to port, as the language specification for these features will be
clearer. More programs will be able to call ADJUST-ARRAY, as its use
will not be restricted to a subset of arrays.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired signal. A few programs might have
porting problems due to variation among implementations of whether the
result of ADJUST-ARRAY is EQ to the first argument.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language more clearly specified is an aesthetic improvement.
Allowing ADJUST-ARRAY on all arrays is an aesthetic improvement.
Discussion:
There are at least 110 messages of discussion preceding this version of the
proposal. It does not seem feasible to summarize them here.
Dick Gabriel, Dave Moon, and Guy Steele support this proposal.
Some commentors would like to get rid of ADJUSTABLE-ARRAY-P, since
ADJUST-ARRAY now works on all arrays. Other commentors have said that
ADJUSTABLE-ARRAY-P is still needed in some applications, such as user
written functions that behave like VECTOR-PUSH-EXTEND, and hence should
be kept; the concept of "adjustable array" is still meaningful.
∂23-Jun-89 1052 X3J13-mailer Issue: PATHNAME-WILD (version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89 10:51:51 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 616035; 23 Jun 89 13:53:42 EDT
Date: Fri, 23 Jun 89 13:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (version 7)
To: X3J13@sail.stanford.edu
Message-ID: <19890623175202.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This issue is on the agenda for the June X3J13 meeting. KMP and I
have prepared a revised writeup which we think is ready for release.
This version has been updated based on last minute discussion:
Remove reversible argument from TRANSLATE-PATHNAME, add ability for
implementations to add keyword arguments and extra return values.
Issue: PATHNAME-WILD
Forum: Cleanup
References: Pathnames (pp410-413)
Related issues: PATHNAME-COMPONENT-VALUE, PATHNAME-LOGICAL
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
9-May-89, Version 3 by Moon (small fixes)
10-May-89, Version 4 by Moon (add two more functions)
13-May-89, Version 5 by Moon (minor cleanups, add clarification)
19-Jun-89, Version 6 by Moon (revise based on extensive
discussion in the cleanup subcommittee; rewrite
the description of TRANSLATE-PATHNAME so it is
possible to understand it)
23-Jun-89, Version 7 by Moon (simplify TRANSLATE-PATHNAME
based on last minute discussion of logical pathnames)
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards (:WILD). For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
Some file systems support even more complex wildcards, for example
regular expressions.
The CL pathname model does not specify a way to represent complex
wildcards, which means, for example, that (MAKE-PATHNAME :NAME "F*O")
cannot be recognized by portable code as containing a wildcard.
Common Lisp provides only the first of these four common operations
on wildcard pathnames:
(1) Enumerate the set of existing files that match the pathname;
this is provided by the DIRECTORY function.
(2) Test whether a pathname contains wildcards.
(3) Test whether a pathname matches a wildcard pathname.
(4) Translate one pathname into another according to a mapping specified
by a pair of wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTIONS):
Introduce the following three functions:
1. WILD-PATHNAME-P pathname &optional field-key
Tests a pathname for the presence of wildcard components. If the first
argument is not a pathname, string, or file stream an error of type
TYPE-ERROR is signalled.
If no <field-key> is provided, or the <field-key> is NIL, the result is
T if <pathname> has any wildcard components, NIL if <pathname> has none.
If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, the result is T
if the indicated component of <pathname> is a wildcard, NIL if the
component is not a wildcard. Note that not all implementations
support wildcards in all fields, according to PATHNAME-COMPONENT-VALUE.
2. PATHNAME-MATCH-P pathname wildcard
T if <pathname> matches <wildcard>, otherwise NIL. The matching rules
are implementation-defined but should be consistent with the
DIRECTORY function. Missing components of <wildcard> default to :WILD.
If either argument is not a pathname, string, or file stream an error
of type TYPE-ERROR is signalled. It is valid for <pathname> to be a
wild pathname; a wildcard field in <pathname> will only match a
wildcard field in <wildcard>, i.e. the function is not commutative.
It is valid for <wildcard> to be a non-wild pathname.
3. TRANSLATE-PATHNAME source from-wildcard to-wildcard &key
Translates the pathname <source>, which matches <from-wildcard>, into
a corresponding pathname <result>, which matches <to-wildcard>, and
returns <result>.
The pathname <result> is <to-wildcard> with each wildcard or missing
field replaced by a portion of <source>. A "wildcard field" is a
pathname component with a value of :WILD, a :WILD element of a
list-valued directory component, or an implementation-defined portion
of a component, such as the "*" in the complex wildcard string
"foo*bar" that some implementations support. An implementation that
adds other wildcard features, such as regular expressions, must define
how TRANSLATE-PATHNAME extends to those features. A "missing field" is
a pathname component with a value of NIL.
The portion of <source> that is copied into <result> is implementation
defined. Typically it is determined by the user interface conventions
of the file systems involved. Usually it is the portion of <source>
that matches a wildcard field of <from-wildcard> that is in the same
position as the wildcard or missing field of <to-wildcard>. If there
is no wildcard field in <from-wildcard> at that position, then usually
it is the entire corresponding pathname component of <source>, or in
the case of a list-valued directory component, the entire corresponding
list element. For example, if the name components of <source>,
<from-wildcard>, and <to-wildcard> are "gazonk", "gaz*", and "h*"
respectively, then in most file systems, the wildcard fields of the
name component of <from-wildcard> and <to-wildcard> are each "*", the
matching portion of <source> is "onk", and the name component of
<result> is "honk". However, the exact behavior of TRANSLATE-PATHNAME
cannot be dictated by the Common Lisp language and must be allowed to
vary, depending on the user interface conventions of the file systems
involved.
During the copying of a portion of <source> into <result>, additional
implementation-defined translations of alphabetic case or file naming
conventions might occur, especially when <from-wildcard> and
<to-wildcard> are for different hosts.
If any of the first three arguments is not a pathname, string, or file
stream an error of type TYPE-ERROR is signalled. It is valid for
<source> to be a wild pathname; in general this will produce a wild
result. It is valid for <from-wildcard> and/or <to-wildcard> to be
non-wild pathnames. (PATHNAME-MATCH-P <source> <from-wildcard>) must
be true or an error is signalled.
There are no specified keyword arguments for TRANSLATE-PATHNAME, but
implementations are permitted to extend it by adding keyword arguments.
There is one specified return value from TRANSLATE-PATHNAME;
implementations are permitted to extend it by returning additional
values.
Implementation guideline: one file system performs this operation by
examining each piece of the three pathnames in turn, where a piece is a
pathname component or a list element of a structured component such as
a hierarchical directory. Hierarchical directory elements in
<from-wildcard> and <to-wildcard> are matched by whether they are
wildcards, not by depth in the directory hierarchy. If the piece in
<to-wildcard> is present and not wild, it is copied into the result.
If the piece in <to-wildcard> is :WILD or NIL, the piece in <source> is
copied into the result. Otherwise, the piece is <to-wildcard> might be
a complex wildcard such as "foo*bar" and the piece in <from-wildcard>
should be wild; the portion of the piece in <source> that matches the
wildcard portion of the piece in <from-wildcard> replaces the wildcard
portion of the piece in <to-wildcard> and the value produced is used in
the result.
4. Clarify that the functions OPEN (and WITH-OPEN-FILE), PROBE-FILE,
FILE-WRITE-DATE, FILE-AUTHOR, and TRUENAME only accept non-wildcard
pathnames and signal an error if given a pathname for which
WILD-PATHNAME-P returns true.
5. Clarify that the functions RENAME-FILE, DELETE-FILE, LOAD, and
COMPILE-FILE have implementation-defined consequences when given a
wildcard pathname. Each function might signal an error or might operate
on all files that match the wildcard pathname.
Examples:
;The following examples are not portable. They are written to run
;with particular file systems and particular wildcard conventions.
;Other implementations will behave differently. These examples are
;intended to be illustrative, not to be prescriptive.
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
(WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
(WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
(WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
;This example assumes one particular set of wildcard conventions
;Not all file systems will run this example exactly as written
(DEFUN RENAME-FILES (FROM TO)
(DOLIST (FILE (DIRECTORY FROM))
(RENAME-FILE FILE (TRANSLATE-PATHNAME FILE FROM TO))))
(RENAME-FILES "/usr/me/*.lisp" "/dev/her/*.l")
;Renames /usr/me/init.lisp to /dev/her/init.l
(RENAME-FILES "/usr/me/pcl*/*" "/sys/pcl/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp
;In some file systems the result might be /sys/pcl/5-may/low.lisp
(RENAME-FILES "/usr/me/pcl*/*" "/sys/library/*/")
;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp
;In some file systems the result might be /sys/library/5-may/low.lisp
(RENAME-FILES "/usr/me/foo.bar" "/usr/me2/")
;Renames /usr/me/foo.bar to /usr/me2/foo.bar
(RENAME-FILES "/usr/joe/*-recipes.text" "/usr/jim/cookbook/joe's-*-rec.text")
;Renames /usr/joe/lamb-recipes.text to /usr/jim/cookbook/joe's-lamb-rec.text
;Renames /usr/joe/pork-recipes.text to /usr/jim/cookbook/joe's-pork-rec.text
;Renames /usr/joe/veg-recipes.text to /usr/jim/cookbook/joe's-veg-rec.text
;This example assumes one particular set of wildcard conventions
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz")) => "barbaz"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*")) => "foobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*" "foo*")) => "foofoobar"
(PATHNAME-NAME (TRANSLATE-PATHNAME "bar" "*" "foo*")) => "foobar"
;Using Unix syntax and the wildcard conventions used by the
;particular version of Unix on which I tried this:
(NAMESTRING
(TRANSLATE-PATHNAME "/usr/dmr/hacks/frob.l"
"/usr/d*/hacks/*.l"
"/usr/d*/backup/hacks/backup-*.*"))
=> "/usr/dmr/backup/hacks/backup-frob.l"
(NAMESTRING
(TRANSLATE-PATHNAME "/usr/dmr/hacks/frob.l"
"/usr/d*/hacks/fr*.l"
"/usr/d*/backup/hacks/backup-*.*"))
=> "/usr/dmr/backup/hacks/backup-ob.l"
;This is similar to the above example but uses two different hosts,
;U: which is a Unix and V: which is a VMS. Note the translation
;of file type and alphabetic case conventions.
(NAMESTRING
(TRANSLATE-PATHNAME "U:/usr/dmr/hacks/frob.l"
"U:/usr/d*/hacks/*.l"
"V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
=> "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-FROB.LSP"
(NAMESTRING
(TRANSLATE-PATHNAME "U:/usr/dmr/hacks/frob.l"
"U:/usr/d*/hacks/fr*.l"
"V:SYS$DISK:[D*.BACKUP.HACKS]BACKUP-*.*"))
=> "V:SYS$DISK:[DMR.BACKUP.HACKS]BACKUP-OB.LSP"
;This example presumes background information described in PATHNAME-LOGICAL
(DEFUN TRANSLATE-LOGICAL-PATHNAME-1 (PATHNAME RULES)
(LET ((RULE (ASSOC PATHNAME RULES :TEST #'PATHNAME-MATCH-P)))
(UNLESS RULE (ERROR "No translation rule for ~A" PATHNAME))
(TRANSLATE-PATHNAME PATHNAME (FIRST RULE) (SECOND RULE))))
(TRANSLATE-LOGICAL-PATHNAME-1 "FOO:CODE;BASIC.LISP"
'(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")
("FOO:CODE;" "MY-UNIX:/lib/foo/")
("FOO:PATCHES;*;" "MY-UNIX:/lib/foo/patch/*/")))
=> the pathname MY-UNIX:/lib/foo/basic.l
Rationale:
1,2,3. These three functions provide a standardized interface to the
idiosyncratic wildcard functionality of each host file system.
1. WILD-PATHNAME-P makes it possible to detect wild pathnames reliably and
do something useful (give up, merge out the bothersome components, call
DIRECTORY for a list of matching pathnames, etc.)
2,3. TRANSLATE-PATHNAME is needed by many application programs that deal
with wildcard pathnames. PATHNAME-MATCH-P and TRANSLATE-PATHNAME are
needed by logical pathnames. The PATHNAME-LOGICAL proposal cannot be
implemented without these features. Implementing PATHNAME-LOGICAL could
involve adding additional capabilities to TRANSLATE-PATHNAME, depending
on the type of file system used, but those capabilities do not need to
be in the standard.
4. Since these functions return a value connected with one file, there
is no meaningful way to extend them to work on wildcard pathnames. It
seems best to specify that they signal an error, rather than leaving
the consequences undefined.
5. The consequences are proposed to be implementation-defined because
current practice varies and no one wants to change.
Current Practice:
Presumably no implementation supports the proposal exactly as stated.
Symbolics Genera has had similar features under different names for many
years:
(SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
etc., indicating the first wild field.
(SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
etc. test individual fields.
The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
:PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
PATHNAME-MATCH-P.
The Explorer also supports the messages :WILD-P (although it only
returns NIL or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and
:PATHNAME-MATCH.
Points 4 and 5 are current practice as far as the authors are aware.
The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
all files that match.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcards to write it.
Since the detailed behavior is at the implementor's discretion, the cost
is unlikely to be large. Some file systems will do all the work and the
implementor need only provide an interface to the file system or to a
standard library routine. For other file systems the implementor has to
write the actual matching and translation algorithms.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
many situations. User programs that deal with wildcard pathnames would
have to operate on implementation-dependent representations and hence
would not be easily portable.
The biggest cost is that the logical pathnames proposal would be stymied.
Performance Impact:
None.
Benefits:
A more complete set of wildcard pathname operations. Portable user
programs that deal with wildcard pathnames will be more consistent
and reliable. A portable system construction tool can be written
and the foundations are laid for a `logical pathname' facility
(proposed separately in PATHNAME-LOGICAL).
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
There was some question about the name. The name PATHNAME-WILD-P
suggests a ``slot'' of a pathname (like PATHNAME-HOST),
while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
The committee was split on what to call it. Since it is more
like a type than a slot, the name WILD-PATHNAME-P was chosen.
It's been suggested that WILD-PATHNAME-P and PATHNAME-MATCH-P be allowed
to return a value other than T to represent "truth", which would
somehow encode some additional information.
∂23-Jun-89 1051 X3J13-mailer Issue: PATHNAME-LOGICAL (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89 10:51:11 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 616034; 23 Jun 89 13:53:02 EDT
Date: Fri, 23 Jun 89 13:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL (version 4)
To: X3J13@sail.stanford.edu
Message-ID: <19890623175120.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
This is an old issue but it has not been written up before. I'm sorry this
is coming out so late, but it's been quite a struggle to cast it into clear
and easily understood form. It is rather a long proposal in order to be
very clear about exactly what it's proposing, and I apologize for the
length.
This version has been amended and simplified based on last-minute
discussion: Support for back-translation has been removed.
TRANSLATE-LOGICAL-PATHNAME now returns only value, but has added ability
for implementations to add keyword arguments and extra return values.
I also made a minor clarification under LOGICAL-PATHNAME-TRANSLATIONS.
The LOGICAL-DIRECTORY example has been removed, as it is no longer
possible for a user to implement that functionality.
Issue: PATHNAME-LOGICAL
Forum: Cleanup
References: Pathnames (pp410-413)
OPEN (p.418), WITH-OPEN-FILE (p.422), RENAME-FILE (p.423),
DELETE-FILE (p.424), PROBE-FILE (p.424),
FILE-WRITE-DATE (p.424), FILE-AUTHOR (p.424), LOAD (p.426),
COMPILE-FILE (p.439), DIRECTORY (p.427), PATHNAME (p.413),
TRUENAME (p.413), MERGE-PATHNAMES (p.415),
MAKE-PATHNAME (p.416), and PARSE-NAMESTRING (p.414).
Related issues: PATHNAME-CANONICAL-TYPE, PATHNAME-COMPONENT-VALUES,
PATHNAME-SUBDIRECTORY-LIST, and PATHNAME-WILD
Category: ADDITION
Edit history: Version 1, 11-May-89, by Moon
Version 2, 18-May-89, by Moon
Version 3, 21-Jun-89, by Moon (revise based on discussion
in the cleanup committee)
Version 4, 23-Jun-89, by Moon (remove backtranslation)
Problem description:
Pathname values are not portable, but they are sometimes part of a
program, for example the names of files containing the program and the
data used by the program. Moving large programs between sites would
be easier if pathname values did not have to be translated.
Pathname values are nonportable because not all Common Lisp
implementations use the same operating system and file name syntax varies
widely among operating systems. In addition, corresponding files at two
different sites may have different names even when the operating system
is the same; for example, they may be on different directories or
different devices.
The issue of portable pathname values is separate from the issues of
portable pathname operations. See the related issues listed above.
For inter-issue interactions, see the discussion section below.
Note that issue PATHNAME-LOGICAL fundamentally depends on issue
PATHNAME-WILD. If PATHNAME-WILD:NEW-FUNCTIONS does not pass,
PATHNAME-LOGICAL cannot pass.
Proposal (PATHNAME-LOGICAL:ADD):
1. Define a "logical" file system that looks the same at every site.
This file system is implemented by translating each logical pathname into
a physical pathname on a real file system. The logical pathnames are the
same at all sites, but the translations are different at each site, thus
the physical pathnames can be different at each site.
2a. The syntax of a logical pathname namestring is as follows:
[ host ":" ] [ ";" ] { directory ";" }* [ name ] [ "." type [ "." version ]]
2b. Terminology:
A <word> consists of one or more uppercase letters, digits, and hyphens.
A <wildcard word> consists of one or more asterisks, uppercase letters,
digits, and hyphens, including at least one asterisk, with no two
asterisks adjacent. Each asterisk matches a sequence of zero or more
characters. The <wildcard word> "*" parses into :WILD, the others parse
into strings.
In <words> and <wildcard words> lowercase letters are translated to
uppercase. The consequences of using other characters are unspecified.
2c. Logical pathname components:
The host is a <word> that has been defined as a logical pathname host by
using SETF of LOGICAL-PATHNAME-TRANSLATIONS.
There is no device, so the device component of a logical pathname is
always :UNSPECIFIC. No other component can be :UNSPECIFIC.
Each directory is a <word>, a <wildcard word>, or "**" (:WILD-INFERIORS).
If a semicolon precedes the directories, the directory component is
relative, otherwise it is absolute.
The name is a <word> or a <wildcard word>.
The type is a <word> or a <wildcard word>.
The version is a positive decimal integer or "NEWEST" (:NEWEST) or "*"
(:WILD). The letters in "NEWEST" can be in either alphabetic case.
The consequences of using any value not specified here as a logical
pathname component are unspecified.
The null string "" is not a valid value for any component of a logical
pathname, since "" is not a <word> and not a <wildcard word>.
3. Parsing of logical pathname namestrings into logical pathnames
operates as follows:
3a. Logical pathname namestrings are recognized by the LOGICAL-PATHNAME
and TRANSLATE-LOGICAL-PATHNAME functions. In this case the host portion
of the logical pathname namestring and its following colon are required.
3b. The PARSE-NAMESTRING function recognizes a logical pathname
namestring when the host argument is logical or the defaults argument is
a logical pathname. In this case the host portion of the logical
pathname namestring and its following colon are optional. If the host
portion of the namestring and the host argument are both present and do
not match, an error is signalled.
The host argument is logical if it is supplied and came from
PATHNAME-HOST of a logical pathname. Whether a host argument is logical
if it is a string equal to a logical pathname host name is
implementation-defined.
3c. The MERGE-PATHNAMES function recognizes a logical pathname namestring
when the defaults argument is a logical pathname. In this case the host
portion of the logical pathname namestring and its following colon are
optional.
3d. Whether the other functions that coerce strings to pathnames
(PATHNAME, TRUENAME, PARSE-NAMESTRING in other circumstances than those
described in point 3b, MERGE-PATHNAMES in other circumstances than those
described in point 3c, the :DEFAULTS argument to MAKE-PATHNAME,
PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME,
PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING, FILE-NAMESTRING,
DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING, OPEN,
WITH-OPEN-FILE, RENAME-FILE, DELETE-FILE, PROBE-FILE, FILE-WRITE-DATE,
FILE-AUTHOR, LOAD, DIRECTORY, COMPILE-FILE, ED, DRIBBLE, WILD-PATHNAME-P,
PATHNAME-MATCH-P, TRANSLATE-PATHNAME, and COMPILE-FILE-PATHNAME)
recognize logical pathname namestrings is implementation defined.
4. Some real file systems do not have versions. Logical pathname
translation to such a file system ignores the version. This implies that
a program cannot rely on being able to store more than one version of a
file named by a logical pathname.
5. The type of a logical pathname for a Common Lisp source file is "LISP".
This should be translated into whatever type is appropriate in a physical
pathname.
6. The logical pathname host name "SYS" is reserved for the implementation.
The existence and meaning of SYS: logical pathnames is
implementation-defined.
7. File manipulation functions operate with logical pathnames as follows:
7a. The functions OPEN (and WITH-OPEN-FILE), RENAME-FILE, DELETE-FILE,
PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD, DIRECTORY, COMPILE-FILE,
ED, DRIBBLE, COMPILE-FILE-PATHNAME, and TRUENAME accept logical pathnames
and translate them into physical pathnames, as if by calling the
TRANSLATE-LOGICAL-PATHNAME function.
7b. PATHNAME of a stream created by OPEN (or WITH-OPEN-FILE) of a logical
pathname is a logical pathname.
7c. TRUENAME, PROBE-FILE, and DIRECTORY never return logical pathnames.
7d. RENAME-FILE with a logical pathname as the second argument returns a
logical pathname as the first value.
7e. MERGE-PATHNAMES returns a logical pathname if and only if its first
argument is a logical pathname or its first argument does not specify a
host and the default is a logical pathname.
7f. MAKE-PATHNAME returns a logical pathname if and only if the host is
logical. If the :host argument to MAKE-PATHNAME is supplied, the host is
logical if it came from PATHNAME-HOST of a logical pathname. Whether a
:host argument is logical if it is a string equal to a logical pathname
host name is implementation-defined.
7g. PARSE-NAMESTRING returns a logical pathname according to points 3b
and 3d.
Add these defined names to Common Lisp in support of logical pathnames:
8. LOGICAL-PATHNAME [Class]
LOGICAL-PATHNAME is a subclass of PATHNAME.
9. LOGICAL-PATHNAME pathname [Function]
Converts the argument to a logical pathname and returns it. The
argument can be a logical pathname, a logical pathname namestring
containing a host component, or a stream for which the PATHNAME
function returns a logical pathname. For any other argument,
LOGICAL-PATHNAME signals an error of type TYPE-ERROR.
10. TRANSLATE-LOGICAL-PATHNAME pathname &key [Function]
Translates a logical pathname to the corresponding physical pathname.
The pathname argument is first coerced to a pathname. If it is not a
pathname, string, or file stream an error of type TYPE-ERROR is
signalled.
If the coerced argument is a physical pathname, it is returned.
If the coerced argument is a logical pathname, the first matching
translation (according to PATHNAME-MATCH-P) of the logical pathname
host is applied, as if by calling TRANSLATE-PATHNAME. If the result is
a logical pathname, this process is repeated. When the result is
finally a physical pathname, it is returned.
If no translation matches, an error of type FILE-ERROR is signalled.
TRANSLATE-LOGICAL-PATHNAME might perform additional translations,
typically to provide translation of file types to local naming
conventions, to accomodate physical file systems with limited length
names, or to deal with special character requirements such as
translating hyphens to underscores or uppercase letters to lowercase.
Any such additional translations are implementation defined. Some
implementations do no additional translations.
There are no specified keyword arguments for
TRANSLATE-LOGICAL-PATHNAME, but implementations are permitted to extend
it by adding keyword arguments. There is one specified return value
from TRANSLATE-LOGICAL-PATHNAME; implementations are permitted to
extend it by returning additional values.
11. LOGICAL-PATHNAME-TRANSLATIONS host [Function]
If <host> is not the host component of a logical pathname and not a
string that has been defined as a logical pathname host name by SETF of
LOGICAL-PATHNAME-TRANSLATIONS, signals an error of type TYPE-ERROR.
Otherwise returns the host's list of translations. Each translation is
a list of at least two elements: from-wildcard and to-wildcard. Any
additional elements are implementation defined. From-wildcard is a
logical pathname whose host is <host>. To-wildcard is a pathname.
Translations are searched in the order listed, so more specific
from-wildcards must precede more general ones.
(SETF (LOGICAL-PATHNAME-TRANSLATIONS host) translations) sets a logical
pathname host's list of translations. If <host> is a string that has
not been previously used as logical pathname host, a new logical
pathname host is defined, otherwise an existing host's translations are
replaced. Logical pathname host names are compared with STRING-EQUAL.
When setting the translations list, each from-wildcard can be a logical
pathname whose host is <host> or a logical pathname namestring
parseable by (PARSE-NAMESTRING string <<host>>), where <<host>>
represents the appropriate object as defined in point 3b. Each
to-wildcard can be anything coercible to a pathname by
(PATHNAME to-wildcard). If to-wildcard coerces to a logical pathname,
TRANSLATE-LOGICAL-PATHNAME will perform repeated translation steps when
it uses it.
Implementations can define additional functions that operate on
logical pathname hosts, for example to specify additional translation
rules or options.
12. LOAD-LOGICAL-PATHNAME-TRANSLATIONS host [Function]
If a logical pathname host named <host> (a string) is already defined,
return NIL. Otherwise, search for a logical pathname host definition
in an implementation defined manner. If none is found, signal an
error. If a definition is found, install it and return T.
The search used by LOAD-LOGICAL-PATHNAME-TRANSLATIONS should be
documented, as logical pathname definitions will be created by users,
not only by Lisp implementors. A typical search technique is to
look in a certain directory for a file whose name is derived from
the host name in an implementation-defined fashion.
13. COMPILE-FILE-PATHNAME pathname &key :output-file [Function]
Returns the pathname that COMPILE-FILE would write into, if given the
same arguments. If the pathname argument is a logical pathname and the
:output-file argument is unspecified, the result is a logical pathname.
If an implementation supports additional keyword arguments to
COMPILE-FILE, COMPILE-FILE-PATHNAME must accept the same arguments.
Examples:
;A very simple example of setting up a logical pathname host. No
;translations are necessary to get around file system restrictions, so
;all that is necessary is to specify the root of the physical directory
;tree that contains the logical file system.
;The namestring syntax on the right-hand side is implementation-specific.
(setf (logical-pathname-translations "foo")
'(("**;*.*.*" "MY-LISPM:>library>foo>**>")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "foo:bar;baz;mum.quux.3")
=> MY-LISPM:>library>foo>bar>baz>mum.quux.3
;A more complex example, dividing the files among two file servers
;and several different directories. This Unix doesn't support
;:WILD-INFERIORS in the directory, so each directory level must
;be translated individually. No file name or type translations
;are required except for .MAIL to .MBX.
;The namestring syntax on the right-hand side is implementation-specific.
(setf (logical-pathname-translations "prog")
'(("RELEASED;*.*.*" "MY-UNIX:/sys/bin/my-prog/")
("RELEASED;*;*.*.*" "MY-UNIX:/sys/bin/my-prog/*/")
("EXPERIMENTAL;*.*.*" "MY-UNIX:/usr/Joe/development/prog/")
("EXPERIMENTAL;DOCUMENTATION;*.*.*"
"MY-VAX:SYS$DISK:[JOE.DOC]")
("EXPERIMENTAL;*;*.*.*" "MY-UNIX:/usr/Joe/development/prog/*/")
("MAIL;**;*.MAIL" "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:mail;save;ideas.mail.3")
=> MY-VAX:SYS$DISK:[JOE.MAIL.PROG.SAVE]IDEAS.MBX.3
;Example translations for a program that uses three files main.lisp,
;auxiliary.lisp, and documentation.lisp. These translations might be
;supplied by a software supplier as examples.
;For Unix with long file names
(setf (logical-pathname-translations "prog")
'(("CODE;*.*.*" "/lib/prog/")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> /lib/prog/documentation.lisp
;For Unix with 14-character file names, using .lisp as the type
(setf (logical-pathname-translations "prog")
'(("CODE;DOCUMENTATION.*.*" "/lib/prog/docum.*")
("CODE;*.*.*" "/lib/prog/")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> /lib/prog/docum.lisp
;For Unix with 14-character file names, using .l as the type
;The second translation shortens the compiled file type to .b
(setf (logical-pathname-translations "prog")
`(("**;*.LISP.*" ,(logical-pathname "PROG:**;*.L.*"))
(,(compile-file-pathname (logical-pathname "PROG:**;*.LISP.*"))
,(logical-pathname "PROG:**;*.B.*"))
("CODE;DOCUMENTATION.*.*" "/lib/prog/documentatio.*")
("CODE;*.*.*" "/lib/prog/")))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> /lib/prog/documentatio.l
;For a Cray with 6 character names and no directories, types, or versions.
(setf (logical-pathname-translations "prog")
(let ((l '(("MAIN" "PGMN")
("AUXILIARY" "PGAUX")
("DOCUMENTATION" "PGDOC")))
(logpath (logical-pathname "prog:code;"))
(phypath (pathname "XXX")))
(append
;; Translations for source files
(mapcar #'(lambda (x)
(let ((log (first x))
(phy (second x)))
(list (make-pathname :name log
:type "LISP"
:version :wild
:defaults logpath)
(make-pathname :name phy
:defaults phypath))))
l)
;; Translations for compiled files
(mapcar #'(lambda (x)
(let* ((log (first x))
(phy (second x))
(com (compile-file-pathname
(make-pathname :name log
:type "LISP"
:version :wild
:defaults logpath))))
(setq phy (concatenate 'string phy "B"))
(list com
(make-pathname :name phy
:defaults phypath))))
l))))
;Sample use of that logical pathname. All return values
;are of course implementation-specific.
(translate-logical-pathname "prog:code;documentation.lisp")
=> PGDOC
Rationale:
1. Large programs can be moved between sites without changing any
pathnames, provided all pathnames used are logical. A portable system
construction tool can be created that operates on programs defined as
sets of files named by logical pathnames.
2. Logical pathname syntax was chosen to be easily translated into most
popular file systems, while still being powerful enough for storing large
programs. Although they have hierarchical directories, extended wildcard
matching, versions, and no limit on the length of names, they can be
mapped onto a less capable real file file system by translating each
directory that is used into a flat directory name, doing wildcards in
Lisp rather than in the file system, treating all versions as :newest,
and/or using translations to shorten long names.
Logical pathname words are restricted to non-case-sensitive letters,
digits, and hyphens to avoid creating problems with real file systems
that support limited character sets for file naming. Other characters
could have been mapped onto such file systems through translations, but
that didn't seem worth the trouble. Logical pathnames have to be
non-case-sensitive or it would be very difficult to map them onto a
non-case-sensitive file system.
Features such as :UP and :BACK relative directories and a namestring
syntax for the root directory were not felt to be necessary in logical
pathnames. They could be added later if a need emerges.
It is not a goal of logical pathnames to be able to represent all
possible file names. Their goal is rather to represent just enough file
names to be useful for storing software. Real pathnames, in contrast,
need to provide a uniform interface to all possible file names, including
names and naming conventions that are not under the control of Common
Lisp.
The choice of logical pathname syntax, using colon, semicolon, and
period, was guided by the goals of being visually distinct from real file
systems and minimizing the use of special characters.
The consequences of using any value not specified here as a logical
pathname component are unspecified, for the benefit of the Explorer.
3. The LOGICAL-PATHNAME function is separate from the PATHNAME function
so that the syntax of logical pathname namestrings does not constrain the
syntax of physical pathname namestrings in any way. Logical pathname
syntax must be defined by Common Lisp so that logical pathnames can be
conveniently exchanged between implementations, but physical pathname
syntax is dictated by forces outside our control.
3b,c. Allowing PARSE-NAMESTRING and MERGE-PATHNAMES to recognize logical
pathname namestrings in these situations provides for natural operations
on logical pathnames. Frequently a string containing just a name, or a
name and a type, will be recognized as a logical pathname by merging it
against a default containing a logical pathname host and directory.
3d. Recognition of logical pathname namestrings by PATHNAME and related
functions is left up to each implementation because some implementations
definitely require this, other implementations don't want to do this, and
nobody wants to change. In any case, Common Lisp historically has avoided
saying anything about the syntax of the strings accepted by the PATHNAME
function, and point 3d preserves that position.
3b,7f. Leaving it implementation defined whether a string, used as the
host argument to PARSE-NAMESTRING or the :host argument to MAKE-PATHNAME,
can be recognized as logical pathname host name is for the same reason as
point 3d. It allows each implementation to decide whether there is one
namespace or two. The correct way to write this is:
(MAKE-PATHNAME :HOST (PATHNAME-HOST (LOGICAL-PATHNAME "hostname:"))
...)
4. Logical pathname versions could have been supported on real file
systems that do not have versions by defining a kind of translation to
encode the version number in the name. However, the typical use of
versions is such that on a file system without versions, people would
rather just store one version of a file, and not preserve the version
information by encoding it somehow in the name. This is different from
the typical use of types or directories, where the files with different
values in those components are truly distinct and everything would break
if you only kept one file.
5,13. The COMPILE-FILE-PATHNAME function and the specification of "LISP"
as the type of a logical pathname for a Common Lisp source file together
provide enough information about compilation for a portable system
construction tool that uses logical pathnames to work. Suppose you want
to call COMPILE-FILE only if the source file is newer than the compiled
file. To do that, you have to have a way to know the name of the
compiled file without actually calling COMPILE-FILE.
No standard file type for compiler output is proposed, because in some
implementations the compiler produces one of several file types,
depending on a variety of implementation-dependent circumstances.
COMPILE-FILE-PATHNAME provides access to the "default[ing] in a manner
appropriate to the implementation's file system conventions" mentioned in
the CLtL documentation of COMPILE-FILE.
6. The use of the logical pathname host name "SYS" for the implementation
is current practice. Standardizing on this name helps users choose
logical pathname host names that avoid conflicting with
implementation-defined names.
7. Accepting logical pathnames for file access is a natural extension
of the file access functions and makes it easier to program using only
logical pathnames in situations where that is appropriate.
8. The LOGICAL-PATHNAME class exists so that methods can distinguish
logical pathnames from regular pathnames.
9. See point 3 above.
10. TRANSLATE-LOGICAL-PATHNAME is the heart of the logical pathname
feature. Allowing TRANSLATE-LOGICAL-PATHNAME on a physical pathname,
simply returning the argument, makes some programs easier to write.
Additional implementation defined translations make it possible for
implementations with unusual file systems to offer some help to the user
in setting up the translations for a logical pathname host, by handling
some of the work automatically. Logical pathnames that translate to
other logical pathnames are a feature that several people have requested.
11. SETF of LOGICAL-PATHNAME-TRANSLATIONS is a simple way for a user to
define a new logical pathname host. Using SETF makes it possible to add
to or modify the translations of an existing logical pathname host.
It is always up to the person who writes the translation rules for a
particular logical pathname host to a particular physical file system to
make sure that the logical pathnames that are actually going to be used
translate to valid pathnames for the particular file system, and that
no two logical pathnames that are supposed to be distinct translate to
the same physical pathname.
12. Loading of logical pathname translations from a site-dependent file
allows software to be distributed using logical pathnames. The assumed
model of software distribution is a division of labor between the
supplier of the software and the user installing it. The supplier
chooses logical pathnames to name all the files used or created by the
software, and supplies examples of logical pathname translations for a
few popular file systems. Each example uses an assumed directory and/or
device name, assumes local file naming conventions, and provides
translations that will translate all the logical pathnames used or
generated by the particular software into valid physical pathnames.
For a powerful file system these translations can be quite simple. For
a more restricted file system, it may be necessary to list an explicit
translation for every logical pathname used, for example when dealing
with restrictions on the maximum length of a file name.
The user installing the software decides on which device and/or directory
to store the files and edits the example logical pathname translations
accordingly. If necessary, the user also adjusts the translations for
local file naming conventions and any other special aspects of the user's
local file system policy and local Common Lisp implementation. For
example, the files might be divided among several file server hosts to
share the load. The process of defining site-customized logical pathname
translations is quite easy for a user of a popular file system for which
the software supplier has provided an example. A user of a more unusual
file system might have to take more time; the supplier can help by
providing a list of all the logical pathnames used or generated by the
software.
Once the user has created a suitable SETF of LOGICAL-PATHNAME-TRANSLATIONS
form, he can evaluate that form and then load and run the software. It
may be necessary to use the translations again, or on another workstation
at the same site, so it is best to save the SETF form in the standard
place where it can be found later by LOAD-LOGICAL-PATHNAME-TRANSLATIONS.
Often a software supplier will include a program for restoring software
from the distribution medium to the file system, and a program for loading
the software from the file system into a Common Lisp, and these programs
will start by calling LOAD-LOGICAL-PATHNAME-TRANSLATIONS to make sure that
the logical pathname host is defined.
Note that the SETF of LOGICAL-PATHNAME-TRANSLATIONS form isn't part of
the program, it's separate. It's written by the user, not by the
software supplier. That separation, and a uniform convention for how to
do the separation, are the key aspects of logical pathnames. For small
programs involving only a handful of files, it doesn't matter much. The
real benefits come with large programs with hundreds or thousands of
files and more complicated situations such as program-generated file
names or porting a program developed on a system with long file names
onto a system with a very restrictive limit on the length of file names.
Current practice:
Symbolics Genera has had a similar facility for many years. It is used
extensively for software distribution by Symbolics and its customers.
The Genera facility uses the same logical pathname syntax but different
function names, and is somewhat more complicated. The extra complexity
is not necessary in the Common Lisp standard.
The T.I. Explorer also has a comparable logical pathname facility,
although the translation mechanism is unfortunately less general than
proposed here. The namestring syntax used is slightly different:
host ":" [{directory "."}* directory ";"] [name] ["." type] ["#" version]
The newest version is indicated by ">" instead of "newest".
Macintosh Allegro Common Lisp) has a logical pathname feature which is
somewhat simpler but aimed at solving the same problems. It has logical
directory names, to simplify access to sets of files in differently named
directories (an especially severe problem on micros where everybody just
has to have a different pet name for their hard disk). This isn't really
the same as simplifying access to different file systems, although of
course solving the latter automatically solves the former. In general,
access to different file systems requires translating names and types,
not just translating directories.
Symbolics Genera offers a function for translating from a physical
pathname back to a logical pathname. There are a number of problems with
this, and so it has not been proposed here. An earlier version specified
TRANSLATE-LOGICAL-PATHNAME to return enough information to allow the user
program to perform the backtranslation itself, but that hsd problems
so it was removed.
The Genera equivalent of LOAD-LOGICAL-PATHNAME-TRANSLATIONS looks for
a file named SYS:SITE;hostname.TRANSLATIONS.
Current practice in Genera, Explorer, and Macintosh has one namespace for
both logical and physical namestrings. This proposal allows an
implementation to choose to have one namespace or to have two separate
namespaces for namestrings.
Cost to Implementors:
This is a fairly complex facility, but its performance is unimportant
so a straightforward implementation should suffice. Most of the
complexity comes in dealing with unusual file systems, such as ones
that don't allow long file names.
Cost to Users:
None.
Cost of non-adoption:
Portable software construction and distribution will have to rely on
implementation-dependent kludges. Lisp software will continue to be
difficult to install.
Performance impact:
None.
Benefits:
Avoid cost of non-adoption.
Esthetics:
Improved portability of large programs.
Discussion:
Issue PATHNAME-LOGICAL fundamentally depends on issue PATHNAME-WILD. If
PATHNAME-WILD:NEW-FUNCTIONS does not pass, PATHNAME-LOGICAL cannot pass.
If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT passes, it will affect the
behavior of the function TRANSLATE-PATHNAME and therefore the behavior of
the function TRANSLATE-LOGICAL-PATHNAME. When a logical pathname
translation has from-wildcard and to-wildcard type components that are
:WILD or omitted, translation of the type will be guided by canonical
types. If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT fails to pass, it will
either have to be done behind the scenes by TRANSLATE-PATHNAME or users
will have to write more verbose translations that individually specify
the handling of each file type (as shown in some of the examples here).
∂23-Jun-89 1234 X3J13-mailer issue CLOS-MACRO-COMPILATION, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jun 89 12:34:23 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA00110; Fri, 23 Jun 89 13:34:46 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03741; Fri, 23 Jun 89 13:34:43 -0600
Date: Fri, 23 Jun 89 13:34:43 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906231934.AA03741@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CLOS-MACRO-COMPILATION, version 5
This is a new version of an issue that was distributed last week. I
have made some changes to clarify some confusing wording, that are not
supposed to affect the content of the proposal. I hope this is ready
to vote on now.
Forum: Compiler
Issue: CLOS-MACRO-COMPILATION
References: CLOS chapters 1 & 2 (88-002R)
CLOS chapter 3 (89-003)
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION
Edit History: V1, 10 Mar 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore
V3, 21 Mar 1989, Sandra Loosemore (fix error language)
V4, 11 Jun 1989, Sandra Loosemore (Gregor's amendment)
V5, 23 Jun 1989, Sandra Loosemore (wording changes per Pitman)
Status: Ready for release
Problem Description:
Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?
A part of the problem is that we do not currently have a full
understanding of all the issues involved. In particular, work on
defining the CLOS meta-object protocol is still in progress. The goal
of this proposal is to say enough about the behavior of these macros
in the standard so that users can use them portably in compiled code,
but to leave as much of the behavior as possible unspecified to avoid
placing undue restrictions on the meta-object protocol.
Proposal CLOS-MACRO-COMPILATION:MINIMAL:
State that top-level calls to the CLOS defining macros have the
following compile-time side-effects. Any other compile-time behavior
is explicitly left unspecified.
DEFCLASS:
* The class name may appear in subsequent type declarations.
* The class name can be used as a specializer in subsequent
DEFMETHOD forms.
DEFGENERIC:
* The generic function can be referenced in subsequent DEFMETHOD forms.
* DEFGENERIC does not arrange for the generic function to be callable
at compile time.
DEFMETHOD:
* DEFMETHOD does not arrange for the method to be callable at compile
time. If there is a generic function with the same name defined at
compile time, compiling a DEFMETHOD does not add the method to that
generic function. (That is, the method is added to the generic
function only when the DEFMETHOD is actually executed.)
The error-signalling behavior described in the specification of
DEFMETHOD in CLOS chapter 2 (if the function isn't a generic function
or if the lambda-list is not congruent) happens only when the defining
form is executed, not at compile time.
The forms in EQL specializers are evaluated when the defining form
is executed. The compiler is permitted to build in knowledge
about what the form in an EQL specializer will evaluate to in cases
where the ultimate result can be syntactically inferred without
actually evaluating it.
DEFINE-METHOD-COMBINATION:
* The method combination can be used in subsequent DEFGENERIC forms.
The body of a DEFINE-METHOD-COMBINATION form is evaluated no earlier
than when the defining macro is executed and possibly as late as
generic function invocation time. The compiler may attempt to
evaluate these forms at compile time but must not depend on being able
to do so.
Rationale:
The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
DEFTYPE.
DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
function definition to the compile-time environment. Since generic
functions may be freely redefined between compile and run time (just
like any other function), a method may end up "belonging" to a
different generic function at load time than at compile time. This
is why it is inappropriate to signal errors about congruency problems
(etc) until the method is actually added to the generic function at
run time.
Current Practice:
The items listed under DEFCLASS in proposal MINIMAL are fairly standard
programming style.
Flavors does not support compile-time instantiation of classes. It
does not make method combinations available at compile-time either, but
Moon considers that to be a bad design choice.
Cost to implementors:
Unknown.
Cost to users:
Unknown, but probably fairly small.
Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
definitions will make sure they are fully defined at compile-time.
Alternatively, the definitions could be placed in a separate file,
which is loaded before compiling the file that depends on those
definitions.
Benefits:
Programmers can rely on programs that use the CLOS defining macros
being able to compile correctly in all implementations, without having
to wrap explicit EVAL-WHENs around every macro call.
Discussion:
This writeup is based on discussions between Moon, Gray, and
Loosemore, who are mostly in agreement on the things presented in
proposal MINIMAL. We have purposely avoided saying anything about
whether meta-objects representing the classes, methods, etc. get
created at compile-time, or whether such meta-objects are fully or
partially defined. The basic questions addressed by this issue are
what kinds of things can be defined and then used during compilation
of the same file that defines them, and what restrictions might apply.
These proposals are not completely compatible with the meta-object
protocol document (89-003). Gregor Kiczales says:
No one believes that what is written in draft 10 of the MOP is valid.
Sandra Loosemore says:
Although I admit I don't understand all of the issues involved with
the meta-object protocol, I prefer proposal MINIMAL over
NOT-SO-MINIMAL. I don't think leaving the issue of whether or not
classes can be instantiated at compile-time unspecified places an
undue burden on users, and it does leave more freedom for the
meta-object protocol to decide what the right behavior really is.
Dick Gabriel notes:
The question I have about the process going on with respect to the
CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
CLOS under various compilation/evaluation situations is being
over-specified.
At this stage of the game I worry that we might go a little too far in
one direction in specification when we are actually engaged in design
work. This isn't intended to be a criticism of any committees, but I
would feel a lot more comfortable with a conservative specification
that defined well-formed programs being loaded or compiled in fresh
Common Lisps with a pretty simple eval-when model that is easier to
specify and which makes it easy for all but the hairiest
compilation-environment-frobbing programs to be written.
∂25-Jun-89 0755 X3J13-mailer registration list update
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Jun 89 07:55:26 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA00640g; Sun, 25 Jun 89 07:53:21 PDT
Received: by challenger id AA02771g; Sun, 25 Jun 89 07:55:00 PDT
Date: Sun, 25 Jun 89 07:55:00 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906251455.AA02771@challenger>
To: x3j13@sail.stanford.edu
Subject: registration list update
X3J13 Attendee Information
06/25/89
Name Institute Paid L1 L2 L3
Kim Barrett -0- y y y
David Bartley TI -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Skona Brittain MSC -0- y y y
Kathy Chapman DEC -0- - - -
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI -0- y y y
Steve Haflich Franz -0- y y y
Jim Kempf Sun MicroSystems -0- y y y
Gregor Kiczales Xerox Corp. -0- y y y
Kerry Kimbrough -0- -0- - - -
Timothy Koschmann Southern Illinois -0- y y y
Aaron Larson Honeywell 80.00 y y y
Ray Lim NASA Ames -0- - - -
David Loeffler MCC 80.00 y y y
Sandra Loosemore University of Utah -0- y y y
Robert Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Chris Perdue Sun Microsystems -0- y y y
Dan Pierson Encore Computer -0- y y y
Kent Pitman Symbolics -0- y y y
Guy Steele Thinking Machines -0- y y y
Paul Tucker IBM -0- y y y
Bill York -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂29-Jun-89 2133 X3J13-mailer Top 10
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 29 Jun 89 21:33:03 PDT
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Fri, 30 Jun 89 00:34:17 EDT
Received: by kulla.think.com; Fri, 30 Jun 89 00:32:13 EDT
Date: Fri, 30 Jun 89 00:32:13 EDT
From: barmar@Think.COM
Message-Id: <8906300432.AA05337@kulla.think.com>
To: x3j13@sail.stanford.edu
Subject: Top 10
Path: think!ames!apple!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: rec.humor,comp.lang.c
Subject: Top Ten Things Overheard At The ANSI C Draft Committee Meetings
Message-ID: <12422@well.UUCP>
Date: 26 Jun 89 23:10:25 GMT
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Followup-To: rec.humor
Organization: Verbatim Corp.: Abort, Retry, Ignore?
Lines: 33
Xref: think rec.humor:27472 comp.lang.c:20637
[ From a guy who only has second-hand knowledge of the AN-C compiler. ]
Top Ten Things Overheard At The ANSI C Draft Committee Meetings:
10. Sorry, but that's too useful.
9. But little-endian systems *are* more consistent!
8: I'm on the committee and I *still* don't know what the hell
#pragma is for.
7. Well, it's an excellent idea, but it would make the compilers too
hard to write.
6. Them bats is smart; they use radar.
5. All right, who's the wiseguy who stuck this trigraph stuff in here?
4. How many times do we have to tell you, "No prior art!"
3. Ha, ha, they're actually going to adopt this sucker.
2. Thank you for your generous donation, Mr. Wirth.
And number one, the top thing heard at the ANSI C draft committee,
1. Gee, I wish we hadn't backed down on 'noalias'.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU
\_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac
O----↑o The Only Way To Fly. hplabs / (pronounced "AE-wack")
I've been busy...
∂04-Jul-89 0825 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89 08:25:38 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA06049; Tue, 4 Jul 89 09:26:07 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00508; Tue, 4 Jul 89 09:26:01 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041526.AA00508@defun.utah.edu>
Date: Tue, 4 Jul 89 09:25:59 MDT
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 5
To: x3j13@sail.stanford.edu
This is the amended version that was passed at last week's meeting.
Forum: Compiler
Issue: COMPILE-FILE-SYMBOL-HANDLING
References: CLtL p. 182
Issue IN-PACKAGE-FUNCTIONALITY (passed)
Issue CONSTANT-COMPILABLE-TYPES (passed)
Issue DEFPACKAGE (passed)
Category: CHANGE/CLARIFICATION
Edit History: V1, 01 Feb 1989, Sandra Loosemore
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
V3, 18 Apr 1989, Sandra Loosemore (new proposal)
V4, 15 Jun 1989, Sandra Loosemore (minor wording changes)
V5, 04 Jul 1989, Sandra Loosemore (incorporate amendments)
Status: Passed, as amended, June 89
Recommendation to drafting committee: in item 1b, clarify
that the "first" top-level form may appear as the first
form inside a top-level PROGN, as the result of macro
expansion, etc.
Problem Description:
It is not clear how COMPILE-FILE is supposed to specify to LOAD how
symbols in the compiled file should be interned. In particular, what
happens if the value of *PACKAGE* is different at load-time than it
was at compile-time, or if any of the packages referenced in the file
are defined differently?
There are two models currently being used to implement this behavior:
(1) Symbols appearing in the output file produced by COMPILE-FILE
are qualified with package prefixes in the same way that PRINT
would qualify them. Symbols that are accessible in *PACKAGE*
at compile-time are looked up in *PACKAGE* at load-time. (This
is the "current-package" model.)
(2) Symbols appearing in the output file produced by COMPILE-FILE
are always qualified with the name of their home package,
regardless of the value of *PACKAGE*. (This is the
"home-package" model.)
Proposal COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:
In order to guarantee that compiled files can be loaded correctly,
users must ensure that the packages referenced in the file are defined
consistently at compile and load time. Conforming Common Lisp programs
must satisfy the following requirements:
(1) The value of *PACKAGE* when a top-level form in the file is processed
by COMPILE-FILE must be the same as the value of *PACKAGE* when the
code corresponding to that top-level form in the compiled file is
executed by the loader. In particular:
(a) Any top-level form in a file which alters the value of *PACKAGE*
must change it to a package of the same name at both compile and
load time.
(b) If the first nonatomic top-level form in the file is not a call to
IN-PACKAGE, then the value of *PACKAGE* at the time LOAD is
called must be a package with the same name as the package that
was the value of *PACKAGE* at the time COMPILE-FILE was called.
(2) For all symbols appearing lexically within a top-level form that
were accessible in the package that was the value of *PACKAGE*
during processing of that top-level form at compile time, but
whose home package was another package, at load time there must
be a symbol with the same name that is accessible in both the
load-time *PACKAGE* and in the package with the same name as the
compile-time home package.
(3) For all symbols in the compiled file that were external symbols in
their home package at compile time, there must be a symbol with the
same name that is an external symbol in the package with the same name
at load time.
If any of these conditions do not hold, the package in which LOAD looks
for the affected symbols is unspecified. Implementations are permitted
to signal an error or otherwise define this behavior.
A symbol S appearing in the source code is similar as a constant to
a symbol S' in the compiled code if:
o Their print names are similar as constants
And, either
o S is accessible in *PACKAGE* at compile time, and S' is accessible in
*PACKAGE* at load time
Or
o S' is accessible in the package that is similar as a constant to the
home package of symbol S.
The "similar as constants" relationship for interned symbols has nothing
to do with *READTABLE* or how the function READ would parse the
characters in the print name of the symbol.
Rationale:
This proposal is merely an explicit statement of the status quo,
namely that users cannot depend on any particular behavior if the
package environment at load time is inconsistent with what existed
at compile time.
This proposal supports both the current-package and home-package
models as implementation techniques.
Current Practice:
PSL/PCLS implements the home-package model, as does A-Lisp. Utah
Common Lisp implements the current-package model, but the chief
compiler hacker says he thinks that the home-package model
actually makes more sense, and agrees that any program that behaves
differently under the two proposals is broken.
The TI Explorer currently implements the home-package model, after
trying it both ways.
KCL also implements the home-package model.
Lucid Lisp appears to implement the current-package model.
Symbolics Genera implements the current-package model. Symbolics
Cloe probably does also.
Coral also implements the current-package model.
Cost to implementors:
Proposal NEW-REQUIRE-CONSISTENCY is intended to be compatible with either
of the two models, but it may not be entirely compatible with the
details of current implementations.
In particular, some implementations that use the current-package
model appear to restrict IN-PACKAGE to being the first top-level
form in the file and dump all symbols referenced in the file after
the entire file has been processed (so that the value of *PACKAGE*
used to determine whether to qualify symbols in the output file is
the same for all symbols in the file). Under this proposal, these
implementations would have to note when the value of *PACKAGE*
changes during processing of a top-level form.
Cost to users:
Any user program that would break under proposal NEW-REQUIRE-CONSISTENCY
is probably already nonportable, since this proposal is intended to
leave the behavior unspecified where it would differ under the
two implementation models.
For a discussion of how the two models treat nonportable or erroneous
programs, see the "Analysis" section below.
Benefits:
COMPILE-FILE's treatment of symbols is made explicit in the standard.
Analysis:
The two implementation models differ in the following situations.
Proposal NEW-REQUIRE-CONSISTENCY, in effect, says that valid programs do
not cause any of these situations to occur, and the behavior in such
cases is unspecified (allowing both models to be used as valid
implementation techniques).
(1) The situation where the file does not contain a IN-PACKAGE
and where the compile-time value of *PACKAGE* is a package with a
different name than the load-time value of *PACKAGE*.
The current-package model would intern the names of symbols that
were accessible in *PACKAGE* at compile time in *PACKAGE* at load time.
The home-package model would intern the names of symbols that
were accessible in *PACKAGE* at compile time in the package with
the same name as their compile-time home package.
In general, programs must be compiled in the "right" package, so
that the compiler can find and apply the correct macro expansions,
type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.
As a result of macroexpansion or other transformations applied by
the compiler, the compiled file may contain symbol references that
were not present in the source file. The current-package model may
cause problems because these references may be resolved to be
symbols other than the ones that were intended. The home-package
model is more likely to find the correct symbols at load time.
(2) The situation where there is a symbol accessible in the
compile-time value of *PACKAGE* but with another home package, and
where at load time there is not a symbol with the same name that
is accessible in both packages. This situation might occur, for
example, if at compile time there is a symbol that is external in
its home package and that package is used by *PACKAGE*, but where
there is no such external symbol in that package at load time, or
the load-time *PACKAGE* does not use the other package.
The current-package model would find or create a symbol accessible
in *PACKAGE*.
The home-package model would find or create a symbol accessible in
a package with the same name as the symbol's compile-time home
package.
Some people feel that the behavior of the current-package model is
more intuitive in this situation, and that it is more forgiving of
differences between the compile-time and load-time package
structures. Others feel that the behavior of the home-package
model is more intuitive, and that if there have been significant
changes to the package structures, it is probably an indication
that the file needs to be recompiled anyway, since the compiler
might have picked up macro definitions and the like from the
wrong package.
(3) The situation where a symbol is external in its home package
and where there is no such external symbol in that package at load
time.
The current-package model would quietly find or create the symbol
in *PACKAGE* if the symbol were accessible in *PACKAGE* at compile
time. Otherwise, it will signal an error.
The home-package model would always just quietly find or create the
symbol as internal in its home package.
Not complaining when a symbol that is supposed to be external
isn't can be seen as a violation of modularity. However, it seems
like this argument should apply equally to symbols whose home
package is *PACKAGE* as symbols whose home package is somewhere
else.
Discussion:
There has been some further and lengthy discussion on the question of
whether this proposal overspecifies the behavior of COMPILE-FILE and
LOAD. At least one person would like the standard to say nothing on
this issue beyond a statement of the goal that loading a compiled file
should exhibit the same behavior as loading its source file. We have
also considered another approach to the problem that would place more
stringent requirements on conforming programs and fewer requirements
on implementations. Neither of these alternatives seems to have much
support, though.
-------
∂04-Jul-89 0839 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89 08:39:06 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07199; Tue, 4 Jul 89 09:39:35 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00516; Tue, 4 Jul 89 09:39:31 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041539.AA00516@defun.utah.edu>
Date: Tue, 4 Jul 89 09:39:30 MDT
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 8
To: x3j13@sail.stanford.edu
This is the amended version that was passed at last week's meeting.
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION (passed)
Issue EVAL-WHEN-NON-TOP-LEVEL (passed)
Issue LOAD-TIME-EVAL (passed)
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Issue COMPILE-ARGUMENT-PROBLEMS (passed)
Category: CLARIFICATION, CHANGE
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
V3, 10 Feb 1989, Sandra Loosemore (new proposal)
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
with other pending proposals)
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
V6, 30 May 1989, Sandra Loosemore (fix proposal TIGHTEN to
apply only to COMPILE-FILE)
V7, 22 Jun 1989, Sandra Loosemore (restore FLUSH again)
V8, 04 Jul 1989, Sandra Loosemore (amendments from meeting)
Status: Proposal TIGHTEN passed, as amended, June 89
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
There are two proposals, FLUSH and TIGHTEN.
Proposal TIGHTEN presents a simple model of the compilation process. A
minimal compiler could be implemented to perform a code walk to apply
the indicated transformations to the function source code. Of course,
most compilers will perform other transformations as well, such as
translating the Lisp source code into a representation that is more
compact or which can be executed more efficiently.
Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:
(1) Remove the type specifier COMPILED-FUNCTION and the predicate
COMPILED-FUNCTION-P from the language.
(2) Remove the language from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY
that says "it is an error" to try to COMPILE a function that
was defined interpretively in a non-null lexical environment.
Instead, state that if COMPILE cannot compile the function,
it should simply behave as an identity operation.
Rationale:
Some people think the wording of proposal TIGHTEN is too vague and
does not provide an adequate definition of what COMPILED-FUNCTIONs
are. Some people think that since proposal TIGHTEN does not require
COMPILE to produce a COMPILED-FUNCTION, its specification is too
weak to be of much use to users.
Since we are unable to reach concensus on what a COMPILED-FUNCTION
really is, or how to construct one, it seems better to remove it
from the language entirely.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls appearing lexically within the function have
already been expanded and will not be expanded again when the
function is called. (See CLtL p. 143.) The process of
compilation effectively turns MACROLET and SYMBOL-MACROLET
constructs into PROGNs with all instances of the local macros
in the body fully expanded.
- If the function contains lexically nested LOAD-TIME-VALUE forms,
these have already been pre-evaluated and will not be evaluated
again when the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for functions that are
not COMPILED-FUNCTIONs to satisfy the above criteria.
(3) Clarify when functions are defined in a file which is compiled
with COMPILE-FILE, and the compiled file is subsequently LOADed,
objects of type COMPILED-FUNCTION result.
(4) Clarify that COMPILE must produce an object of type
COMPILED-FUNCTION.
Rationale:
This proposal allows users to count on both COMPILE and COMPILE-FILE
always producing objects that are COMPILED-FUNCTION-P.
Some specific properties are assigned to compiled functions. Users
would be able to rely on any function which is of type
COMPILED-FUNCTION having really been (at least partially) compiled.
It also states what many people believe to be the minimum functionality
required of a compiler.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation. It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.
Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
In Utah Common Lisp, COMPILED-FUNCTION-P currently returns true of all
function objects, but there is an internal tag field in the object
which allows real compiled functions to be distinguished from
interpreted functions.
Cost to implementors:
Unknown, but probably not too great. Many implementations will
probably have to make some minor changes to representation of
functions and/or to the definition of COMPILED-FUNCTION-P, but
probably most of those changes are necessary to support the
FUNCTION-TYPE proposal anyway.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
This writeup originally contained an additional proposal,
TIGHTEN-COMPILE. A straw vote at the March 1989 meeting indicated
that an earlier version of proposal TIGHTEN had the most support.
However, a number of people still have a strong preference for
proposal FLUSH.
Recent mail on the cl-compiler list has indicated that Moon, Loosemore
and MacLachlan favor flushing COMPILED-FUNCTION; White and Burke have
no objection to doing so; and that Pitman would like to see the type
retained with both COMPILE and COMPILE-FILE required to produce
compiled functions. Nobody has explicitly stated a preference for
proposal TIGHTEN in this round of discussion.
Loosemore would also prefer to see the type retained, but thinks that
since we have been unable to reach a consensus on what the
compiled-function type means or how to construct an object of this
type, we are much better off not saying anything about it at all in
the standard, than standardizing a definition that is too vague to
be of any use to users, or that some people believe is wrong.
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One use of the COMPILED-FUNCTION type is in declarations. A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION. However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION.
Moon says:
I much prefer the option FLUSH...
This type has no portable meaning and never should have existed.
Pierson says:
What I (and believe Kent) want is a guarantee that [COMPILE] won't
signal an error; if nothing else works COMPILE will simply apply
#'IDENTITY to the symbol's function. Specifically, it should be
legal and safe to attempt to speed up my current program(s) by
doing:
(DO-SYMBOLS (SYM <my-package>)
(WHEN (FBOUNDP SYM) (COMPILE SYM)))
-------
∂04-Jul-89 0925 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 14
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89 09:25:28 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11018; Tue, 4 Jul 89 10:25:56 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00564; Tue, 4 Jul 89 10:25:53 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041625.AA00564@defun.utah.edu>
Date: Tue, 4 Jul 89 10:25:52 MDT
Subject: issue COMPILER-DIAGNOSTICS, version 14
To: x3j13@sail.stanford.edu
This is the amended version that was passed at last week's meeting.
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Issue CONDITION-RESTARTS
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
V9, 26 Jan 1989, Sandra Loosemore (simplify)
V10, 22 Mar 1989, Sandra Loosemore (error terminology)
V11, 11 Apr 1989, Kent Pitman (changes per X3J13)
V12, 21-Jun-89, Moon (changes to point 4 only: return a
status value from COMPILE also, make the status
value provide more detail)
V13, 22-Jun-89, Loosemore (fix one of the fixes)
V14, 04-Jul-89, Loosemore (amendments from June meeting)
Status: Passed V11 March 89
Passed V14 June 89
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
of WARNING.
(2) Clarify that ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) The compiler is permitted to signal diagnostics about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
calls to function with wrong number of arguments
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) State that both COMPILE and COMPILE-FILE are permitted (but not
required) to establish a handler for ERROR. For example, they
might issue a warning, and restart compilation from some
implementation-dependent point in order to let the compilation
proceed without manual intervention.
(4) Specify that COMPILE and COMPILE-FILE return three values. The first
value from COMPILE is not changed by this proposal. The first value
from COMPILE-FILE is the truename of the output file, or NIL if the
file could not be created.
The second value is NIL if no compiler diagnostics were issued, and
true otherwise.
The third value is NIL if no compiler diagnostics other than style
warnings were issued. A non-NIL value indicates that there were
"serious" compiler diagnostics issued, or that other conditions of
type ERROR or WARNING (but not STYLE-WARNING) were signalled during
compilation.
Rationale:
Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.
The second and third return values from COMPILE and COMPILE-FILE give
some indication of whether there were serious problems encountered in
compiling the file.
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
Explicit calls to ERROR don't really justify warnings to be signalled
at compile-time, but we assume implementors have some common sense
about when it's appropriate to do so.
-------
∂04-Jul-89 0931 X3J13-mailer issue PROCLAIM-ETC-IN-COMPILE-FILE, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89 09:31:42 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11610; Tue, 4 Jul 89 10:32:12 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00572; Tue, 4 Jul 89 10:32:09 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041632.AA00572@defun.utah.edu>
Date: Tue, 4 Jul 89 10:32:08 MDT
Subject: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 5
To: x3j13@sail.stanford.edu
This is the amended version that was passed at last week's meeting.
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
References: CLtL p. 182 [package functions],
p. 156 [PROCLAIM], p. 439 [COMPILE-FILE];
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue IN-PACKAGE-FUNCTIONALITY
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, CHANGE, ADDITION
Edit History: 15 Sep 88, V1 by David Gray
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
11 Mar 89, V3 by Sandra Loosemore (rewrite)
13 Mar 89, V4 by Sandra Loosemore (discussion)
04 Jul 89, V5 by Sandra Loosemore (amendment from June mtg)
Status: Proposal NEW-MACRO passed June 89
Problem Description:
Should the compiler treat top-level calls to PROCLAIM specially?
Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
to the following package functions as though they were wrapped in an
(EVAL-WHEN (COMPILE LOAD EVAL) ...):
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
CLtL is silent on whether top-level calls to PROCLAIM should also be
evaluated at compile-time, which presumably means they shouldn't be.
However, some implementations do evaluate PROCLAIM at compile-time.
In the model of how COMPILE-FILE works that is presented in issues
EVAL-WHEN-NON-TOP-LEVEL and DEFINING-MACROS-NON-TOP-LEVEL, the special
form EVAL-WHEN is the only thing that can cause compile-time evaluation
to occur. The compile-time side-effects of macros such as DEFMACRO
and DEFPACKAGE are explained by having them include EVAL-WHEN in their
expansions. Any functions that are treated specially, however, must
be included as special cases in the compiler.
Proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO would remove the
requirement that the package functions be treated specially. Do we
wish to make an exception to the model for PROCLAIM?
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
Add a new macro:
DECLAIM &rest decl-specs [Macro]
This macro PROCLAIMs the given <decl-specs>, which are not
evaluated. If a call to this macro appears at top-level in a file
being processed by the file compiler, the proclamations are also
made at compile-time. As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DECLAIM persist after the file has been compiled.
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation,
or use the macro DECLAIM.
Rationale:
The macro makes the proclamations available to the compiler in such
a way that does not require any special exceptions to be made in
the model of how COMPILE-FILE works.
Current Practice:
The TI explorer apparently implements proposal YES, except that
(EVAL-WHEN (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything.
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
Lisps developed at Utah (UCL, A-Lisp, PSL/PCLS) do not give PROCLAIM
any special compile-time handling.
Lucid does not evaluate calls to PROCLAIM at compile-time.
The IIM compiler has special top-level handling for PROCLAIM when
the argument is a constant. The information is recorded in the remote
environment.
Cost to implementors:
Since implementations are already required to have a mechanism for
compile-time handling of the package functions, it would probably
only require minor adjustments to add handling for PROCLAIM.
Cost to users:
Some users would probably have to make minor changes to their code.
Benefits:
Users will know what to expect when they use PROCLAIM.
Costs of Non-Adoption:
Users will not know what to expect when they use PROCLAIM.
Aesthetics:
At least two people consider requiring magic behavior for certain
top-level function calls to be "semantically bletcherous". Removing
all special cases for functions that are implicitly evaluated at
compile-time would simplify the model of how COMPILE-FILE works.
Programs look cleaner if EVAL-WHEN is only needed for unusual cases
instead of being required for the normal cases.
Discussion:
The first version of this writeup also included REQUIRE with PROCLAIM,
but we have now voted to remove REQUIRE from the language entirely.
It also specified that OPTIMIZE proclamations should only have a local
effect within the file being compiled. This was removed for
consistency with other compile-time side-effects (such as those from
DEFMACRO), where their persistence is explicitly left unspecified.
-------
∂04-Jul-89 1005 X3J13-mailer passed cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89 10:05:47 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14834; Tue, 4 Jul 89 11:06:15 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00645; Tue, 4 Jul 89 11:06:11 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041706.AA00645@defun.utah.edu>
Date: Tue, 4 Jul 89 11:06:09 MDT
Subject: passed cl-compiler issues
To: x3j13@sail.stanford.edu
I have put copies of all the passed cl-compiler issues where they can be
gotten at via anonymous FTP. The files are on host cs.utah.edu (that's
128.110.4.21 if your machine only knows about number-style addresses)
in directory pub/cl-compiler/passed.
-Sandra
-------
∂04-Jul-89 0954 X3J13-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 11
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89 09:54:17 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA13758; Tue, 4 Jul 89 10:54:42 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA00593; Tue, 4 Jul 89 10:54:38 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041654.AA00593@defun.utah.edu>
Date: Tue, 4 Jul 89 10:54:37 MDT
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 11
To: x3j13@sail.stanford.edu
This is the amended version that was passed at last week's meeting.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
CLtL Chapter 9: Declarations,
Issue COMPILE-FILE-ENVIRONMENT,
Issue DEFINING-MACROS-NON-TOP-LEVEL,
Issue DESTRUCTURING-BIND,
Issue EVAL-WHEN-NON-TOP-LEVEL,
Issue GET-SETF-METHOD-ENVIRONMENT,
Issue FUNCTION-NAME,
Issue FUNCTION-TYPE,
Issue MACRO-ENVIRONMENT-EXTENT,
Issue MACRO-FUNCTION-ENVIRONMENT,
Issue PROCLAIM-LEXICAL,
Issue PACKAGE-CLUTTER
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
Version 7, 7-Apr-89, Moon & Barrett (more revisions)
Version 8, 9-Jun-89, Kim A. Barrett (add DEFDECLARE)
Version 9, 13-Jun-89, Moon (small corrections)
Version 10, 22-Jun-89, Loosemore (more clarifications,
primarily relating to DEFDECLARE)
Version 11, 04-Jul-89, Loosemore (amendments from June mtg)
Status: Proposal SMALL passed June 89
Problem description:
When macro forms are expanded, the expansion function is called with two
arguments: the form to be expanded, and the environment in which the form was
found. The environment argument is of limited utility. The only use
sanctioned currently is as an argument to MACROEXPAND or MACROEXPAND-1 or
passed directly as an argument to another macro expansion function. Recently
passed cleanup issues allow it as an argument to MACRO-FUNCTION and to
GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle local
macro and function definitions, due to insufficient access to the information
contained in environments and the inability to augment environments with local
definitions.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic environment
objects. In all of these functions the argument named ENV is an environment
of the sort received by the &ENVIRONMENT argument to a macro or as the
environment argument for EVALHOOK. (It is not required that implementations
provide a distinguished representation for such objects.) Optional "env"
arguments default to NIL, which represents the local null lexical environment
(containing only global definitions and proclamations that are present in the
runtime environment). All of these functions should signal an error of type
TYPE-ERROR if the value of an environment argument is not a syntactic
environment.
The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION-INFORMATION retrieve information about declarations that are in
effect in the environment. Since implementations are permitted to ignore
declarations (except for SPECIAL declarations and OPTIMIZE SAFETY
declarations if they ever compile unsafe code), these accessors are required
only to return information about declarations that were explicitly added to
the environment using AUGMENT-ENVIRONMENT. They might also return
information about declarations recognized and added to the environment by the
interpreter or the compiler, but that is optional at the discretion of the
implementer. Implementations are also permitted to canonicalize
declarations, so the information returned by the accessors might not be
identical to the information that was passed to AUGMENT-ENVIRONMENT.
VARIABLE-INFORMATION variable &optional env [Function]
This function returns information about the interpretation of the symbol
VARIABLE when it appears as a variable within the lexical environment ENV.
The following three values are returned.
The first value indicates the type of definition or binding which is apparent
in ENV:
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT, or VARIABLE is a keyword symbol.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result will also
refer to variables proclaimed lexical.]
The second value indicates whether there is a local binding of the name. If
the name is locally bound, the second value is true. Otherwise, NIL is
returned.
The third value is an a-list containing information about declarations
that apply to the apparent binding of the variable. The keys in the a-list
are symbols which name declaration-specifiers, and the format of the
corresponding value in the CDR of each pair depends on the particular
declaration name involved. The standard declaration names
that might appear as keys in this a-list are:
DYNAMIC-EXTENT a non-NIL value indicates that the variable has been
declared DYNAMIC-EXTENT. If the value is NIL, the pair
might be omitted.
IGNORE a non-NIL value indicates that the variable has been declared
IGNORE. If the value is NIL, the pair might be omitted.
TYPE a type specifier associated with the variable by a TYPE
declaration or an abbreviated declaration such as (FIXNUM VAR).
If no explicit association exists, either by PROCLAIM or
DECLARE, then the type specifier is T. It is permissible for
implementations to use a type specifier that is equivalent
to or a supertype of the one appearing in the original
declaration. If the value is T, the pair might be
omitted.
If an implementation supports additional declaration-specifiers that
apply to variable bindings, those declaration names might also
appear in the a-list. However, the corresponding key must not
be a symbol that is external in any package defined in the standard
or that is otherwise accessible in the USER package.
The a-list might contain multiple entries for a given key.
The consequences of destructively modifying the list
structure of this a-list or its elements (except for values that
appear in the a-list as a result of DEFINE-DECLARATION) are undefined.
Programmers are reminded that the global binding might differ from the
local one, and can be retrieved by calling VARIABLE-INFORMATION
again with a null lexical environment.
FUNCTION-INFORMATION function &optional env [Function]
This function returns information about the interpretation of the function
name FUNCTION when it appears in a functional position within lexical
environment ENV. The following three values are returned.
The first value indicates the type of definition or binding of the function
name which is apparent in ENV:
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
Some function names can refer to both a global macro and a global special
form. In such a case, the macro takes precedence, and :MACRO is returned as
the first value.
The second value specifies whether the definition is local or global. If
local, the second value is true, and it is false when the definition is
global.
The third value is an a-list containing information about declarations
that apply to the apparent binding of the function. The keys in the a-list
are symbols which name declaration-specifiers, and the format of the
corresponding values in the CDR of each pair depends on the particular
declaration name involved. The standard declaration names
that might appear as keys in this a-list are:
INLINE one of the symbols INLINE, NOTINLINE, or NIL to indicate
whether the function name has been declared INLINE, has been
declared NOTINLINE, or neither. If the value is NIL, the
pair might be omitted.
FTYPE the type specifier associated with the function name in the
environment, or the symbol FUNCTION if there is no functional
type declaration or proclamation associated with the function
name. This value might not include all the apparent FTYPE
declarations for the function name. It is permissible for
implementations to use a type specifier that is equivalent
to or a supertype of the one that appeared in the original
declaration. If the value is FUNCTION, the pair might be
omitted.
DYNAMIC-EXTENT a non-NIL value indicates that the function has been
declared DYNAMIC-EXTENT. If the value is NIL, thie pair
might be omitted.
If an implementation supports additional declaration-specifiers that
apply to function bindings, those declaration names might also
appear in the a-list. However, the corresponding key must not be
a symbol that is external in any package defined in the standard or
that is otherwise accessible in the USER package.
The a-list might contain multiple entries for a given key.
In this case the value associated with the first entry has
precedence. The consequences of destructively modifying the list
structure of this a-list or its elements (except for values
that appear in the a-list as a result of DEFINE-DECLARATION) are
undefined.
Programmers are reminded that the global binding might differ from the local
one, and can be retrieved by calling FUNCTION-INFORMATION again with a null
lexical environment.
DECLARATION-INFORMATION decl-name &optional env [Function]
This function returns information about declarations named by the
symbol DECL-NAME that are in force in the environment ENV.
Only declarations that do not apply to function or variable bindings
can be accessed with this function. The format of the information
that is returned depends on the DECL-NAME involved.
It is required that this function recognize OPTIMIZE and DECLARATION as
DECL-NAMEs. The values returned for these two cases are as follows:
OPTIMIZE a list whose entries are of the form (quality value), where
"quality" is one of the optimization qualities defined by the
standard (SPEED, SAFETY, COMPILATION-SPEED, SPACE, and DEBUG)
or some implementation-specific optimization quality, and
"value" is an integer in the range 0 to 3. The returned list
always contains an entry for each of the standard qualities and
for each of the implementation-specific qualities. In the
absence of any previous declarations, the associated values are
implementation-dependent. The list might contain multiple
entries for a quality, in which case the first such entry
specifies the current value.
The consequences of destructively modifying this list or
its elements are undefined.
DECLARATION a list of the declaration names which have been proclaimed as
valid through the use of the DECLARATION proclamation.
The consequences of destructively modifying this list or
its elements are undefined.
If an implementation has been extended to recognize additional
declaration specifiers in DECLARE or PROCLAIM, it is required that
either the DECLARATION-INFORMATION function should also recognize those
declarations, or that the implementation provide an accessor that is
specialized for that declaration specifier. If DECLARATION-INFORMATION
is used to return the information, the corresponding DECL-NAME must not
be a symbol that is external in any package defined in the standard or
that is otherwise accessible in the USER package.
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a new environment containing the information present in
ENV, augmented with the information provided by the keyword arguments. It is
intended to be used by program analyzers that perform a code walk.
The arguments are supplied as follows:
:VARIABLE A list of symbols which shall be visible as bound variables in
the new environment. Whether each binding is to be interpreted
as special or lexical depends on SPECIAL declarations recorded
in the environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, specified as a list of
(name definition) lists (that is, in the same format as the
CADR of a SYMBOL-MACROLET special form). The new environment
will have local symbol-macro bindings of each symbol to the
corresponding expansion, so that MACROEXPAND will be able to
expand them properly. A type declaration in the :DECLARE
argument which refers to a name in this list implicitly
modifies the definition associated with the name. The effect
is to wrap a THE form mentioning the type around the
definition.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, specified as a list of (name
definition) lists. Each definition must be a function of two
arguments (a form and an environment). The new environment
will have local macro bindings of each name to the
corresponding expander function, which will be returned by
MACRO-FUNCTION and used by MACROEXPAND.
:DECLARE A list of decl-specs. Information about these declarations can
be retrieved from the resulting environment using the
VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION-INFORMATION accessors.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list. An error is
signaled if any of the symbols naming macros in the :SYMBOL-MACRO alist are
also included in a SPECIAL decl-spec in the :DECLARE argument. An error is
signalled if any of the names of macros in the :MACRO alist are also included
in the :FUNCTION list. The consequences of destructively modifying the list
structure of any of the arguments to this function are undefined.
The condition type of each of these errors is PROGRAM-ERROR.
The extent of the returned environment is the same as the extent of the
argument environment. The result might share structure with the argument
environment, but the argument environment is not modified.
While an environment argument from EVALHOOK is permitted to be used as the
environment argument for this function, the reverse is not true. If an
attempt is made to use the result of AUGMENT-ENVIRONMENT as the environment
argument for EVALHOOK, the consequences are undefined. The environment
returned by AUGMENT-ENVIRONMENT can only be used for syntactic analysis, ie.
the functions specified by this proposal and functions such as MACROEXPAND.
DEFINE-DECLARATION decl-name lambda-list &body body [Macro]
Define a handler for the named declaration. This is the mechanism by which
AUGMENT-ENVIRONMENT is extended to support additional declaration
specifiers. The function defined by this macro will be called with two
arguments, a decl-spec whose CAR is decl-name, and the ENV argument to
AUGMENT-ENVIRONMENT. Two values must be returned by the function. The
first value must be one of the following keywords:
:VARIABLE the declaration applies to variable bindings.
:FUNCTION the declaration applies to function bindings.
:DECLARE the declaration does not apply to bindings.
For the case where the first value indicates the declaration applies to
bindings, the second value is a list, the elements of which are lists of the
form (binding-name key value). If the corresponding information
function (either VARIABLE-INFORMATION or FUNCTION-INFORMATION) is applied to
the binding name and the augmented environment, the a-list which is
the third value returned by the information function will contain the value
under the specified key.
When the first value is :DECLARE, the second value is a cons whose CAR is a
key and whose CDR is the associated value. The function
DECLARATION-INFORMATION, when applied to the key and the augmented
environment, will return the associated value.
DEFINE-DECLARATION causes DECL-NAME to be proclaimed to be a
declaration (it is as if its expansion included a call (PROCLAIM
'(DECLARATION decl-name))). As is the case with standard
declaration specifiers, the evaluator and compiler are permitted,
but not required, to add information about declaration specifiers
defined with DEFINE-DECLARATION to the macroexpansion and evalhook
environments.
The consequences are undefined if DECL-NAME is a symbol which can
appear as the CAR of any declaration specifier defined in the standard.
The consequences are also undefined if the return value from a
declaration handler defined with DEFINE-DECLARATION includes a key name
that is used by the corresponding accessor to return information about
any declaration specifier defined in the standard. (For example, if
the first return value from the handler is :VARIABLE, the second return
value may not use the symbols DYNAMIC-EXTENT, IGNORE, or TYPE as key
names.)
The DEFINE-DECLARATION macro does not have any special compile-time
side-effects.
PARSE-MACRO name lambda-list body &optional env [Function]
This function is used to process a macro definition in the same way
as DEFMACRO and MACROLET. It returns a lambda-expression that accepts
two arguments (a form and an environment). The "name", "lambda-list",
and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
definition.
The "lambda-list" argument can include &ENVIRONMENT and &WHOLE. The "name"
argument is used to enclose the "body" in an implicit BLOCK, and might also
be used for implementation-dependent purposes (such as including the name of
the macro in error messages if the form does not match the lambda-list).
ENCLOSE lambda-expression &optional env [Function]
This function returns an object of type FUNCTION that is equivalent to what
would be obtained by evaluating `(FUNCTION ,LAMBDA-EXPRESSION) in syntactic
environment ENV. The LAMBDA-EXPRESSION is permitted to reference only the
parts of the environment argument ENV that are relevant only to syntactic
processing, specifically declarations and the definitions of macros and
symbol-macros. The consequences are undefined if the LAMBDA-EXPRESSION
contains any references to variable or function bindings that are
lexically visible in ENV; any GO to a tag that is lexicaly visible in
the environment ENV; or any RETURN-FROM a block name that is lexically
visible in the environment ENV.
Rationale:
This proposal defines a minimal set of accessors (VARIABLE-INFORMATION,
FUNCTION-INFORMATION, and DECLARATION-INFORMATION) and a constructor
(AUGMENT-ENVIRONMENT) for environments.
All of the standard declaration specifiers, with the exception of SPECIAL,
can be defined fairly easily using DEFINE-DECLARATION. It also
seems to be able to handle most extended declarations.
The PARSE-MACRO function is provided so that users don't have to write their
own code to destructure macro arguments. With the addition of
DESTRUCTURING-BIND to the language, this function is not entirely necessary.
However, it is probably worth including anyway, since any program-analyzing
program is going to need to define it, and the definition isn't completely
trivial.
ENCLOSE is needed to allow expander functions to be defined in a non-NULL
lexical environment, as required by DEFINING-MACROS-NON-TOP-LEVEL:ALLOW. It
also provides a mechanism by which the forms in an (EVAL-WHEN (COMPILE) ...)
can be executed in the enclosing environment (see Issue
EVAL-WHEN-NON-TOP-LEVEL).
Making declarations from an &ENVIRONMENT or EVALHOOK environment optional
continues to allow implementations the freedom simply to ignore all such
declarations in the compiler or interpreter.
Examples:
#1: This example illustrates the first two values returned by the function
VARIABLE-INFORMATION.
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (KIND BINDINGP)
(VARIABLE-INFORMATION VAR ENV)
`(LIST ',VAR ',KIND ',BINDINGP)))
(DEFVAR A)
(DEFCONSTANT B 43)
(DEFUN TEST ()
(LET (C)
(LET (D)
(DECLARE (SPECIAL D))
(SYMBOL-MACROLET ((E ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E)
(KIND-OF-VARIABLE F))))))
(TEST) -> ((A :SPECIAL NIL)
(B :CONSTANT NIL)
(C :LEXICAL T)
(D :SPECIAL T)
(E :SYMBOL-MACRO T)
(F NIL NIL))
#2: This example illustrates the first two values returned by the function
FUNCTION-INFORMATION.
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
(MULTIPLE-VALUE-BIND (KIND BINDINGP)
(FUNCTION-INFORMATION FUNCTION-NAME ENV)
`(LIST ',FUNCTION-NAME ',KIND ',BINDING)))
(DEFUN A ())
(DEFUN (SETF A) (V))
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(LIST (KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION (SETF A))
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> ((A :FUNCTION NIL)
(B :MACRO NIL)
(QUOTE :SPECIAL-FORM NIL)
((SETF A) :FUNCTION NIL)
(C :FUNCTION T)
(D :MACRO T)
(E NIL NIL))
#3: This example shows how a code-walker might walk a MACROLET special form.
It assumes that the revised MACROLET semantics described in proposal
DEFINING-MACROS-NON-TOP-LEVEL:ALLOW are in effect.
(DEFUN WALK-MACROLET (FORM ENV)
(LET ((MACROS (MAKE-MACRO-DEFINITIONS (CADR FORM) ENV)))
(MULTIPLE-VALUE-BIND (BODY DECLS) (PARSE-BODY (CDDR FORM))
(WALK-IMPLICIT-PROGN
BODY
(AUGMENT-ENVIRONMENT ENV :MACRO MACROS :DECLARE DECLS)))))
(DEFUN MAKE-MACRO-DEFINITIONS (DEFS ENV)
(MAPCAR #'(LAMBDA (DEF)
(LET ((NAME (CAR DEF)))
(LIST NAME
(ENCLOSE (PARSE-MACRO NAME (CADR DEF) (CDDR DEF) ENV)
ENV))))
DEFS))
Cost to Implementors:
Most implementations already record some of this information in some form.
Providing these functions should not be too difficult, but it is a more than
trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable Common
Loops defines a subset of this functionality for its code walker and
implements it on a number of diffent versions of Common Lisp.
Discussion:
The first version of this proposal expressly did not deal with the objects
which are used as environments by EVALHOOK. This version is extended to
support them in the belief that such environments share a lot of functionality
with the syntactic environments needed by a compiler. While the two types of
environments might have very different implementations, there are many
operations which are reasonable to perform on either type, including all of
the accessor functions described by this proposal.
There has been discussion about a macro called WITH-AUGMENTED-ENVIRONMENT,
either in addition to or instead of AUGMENT-ENVIRONMENT. The point of this
would be to say that the extent of the augmented environment is the dynamic
extent of the WITH-AUGMENTED-ENVIRONMENT form. There was some concern that
there might be cases where the macro was awkward to use. Such a macro is not
included in this proposal. If AUGMENT-ENVIRONMENT is provided, then such a
macro is trivially written in terms of the function. There are places in the
processing of sequential binding forms where using such a macro might be more
difficult than using the specified function.
Some people have indicated they think that the :MACRO argument (and the
:SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an a-list of the
form ((name . definition)...) rather than the form ((name definition)...).
Some people have indicated they think that implementations must never discard
any declarations, even if they are not otherwise used by the interpreter or
compiler. Proposal SMALL is consistent with what CLtL says (implementations
are free to ignore all declarations except SPECIAL declarations), but the
DECLARATION-INFORMATION function might not be particularly useful unless it is
guaranteed to do something. Requiring implementations to keep track of
declarations they'd otherwise ignore would involve some implementation cost
and also might incur a performance penalty.
ENCLOSE happens to subsume the extension to COERCE for converting a lambda
expression into a function (see Issue FUNCTION-TYPE, passed in June 1988).
Perhaps the extension to COERCE should be backed out?
There have been some suggestions for related functionality that have not
been included in this proposal because we haven't had the time to give
them adequate consideration, and some of them might be controversial.
These suggestions include:
- Adding a function to canonicalize type specifiers.
- Extending VARIABLE-INFORMATION to return a value indicating whether there
is a special binding of the variable in the environment, regardless of
whether or not it has been shadowed by a lexical or symbol-macro binding
of the same name.
- A function to map over all names that are defined in the lexical
environment:
MAP-ENVIRONMENT fn key &optional env
KEY must be one of the symbols :FUNCTION, :VARIABLE, or :DECLARATION.
when key is :FUNCTION,
for every symbol S for which (FUNCTION-INFORMATION s ENV)
would return the values X, true, Y, for any X and Y,
FN is applied to the arguments S, X, and Y.
when key is :VARIABLE,
for every symbol S for which (VARIABLE-INFORMATION s ENV)
would return the values X, true, Y, for any X and Y,
FN is applied to the arguments S, X, and Y.
when key is :DECLARATION,
for every symbol S for which (VARIABLE-INFORMATION s ENV)
would return a non-nil value L
FN is applied to the arguments S and L.
- Adding additional accessors and keyword arguments to AUGMENT-ENVIRONMENT
for BLOCK and TAGBODY labels.
-------
∂04-Jul-89 2123 X3J13-mailer Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jul 89 21:23:18 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06051g; Tue, 4 Jul 89 21:20:40 PDT
Received: by bhopal id AA12355g; Tue, 4 Jul 89 21:22:53 PDT
Date: Tue, 4 Jul 89 21:22:53 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907050422.AA12355@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, X3J13@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 22 Jun 89 19:01 EDT <19890622230138.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
Kent, I consider the issue ADJUST-ARRAY-NOT-ADJUSTABLE a dead horse.
But commentaries sent out by you and Barry in the few days before the
last X3J13 meeting show so much misunderstanding of "portability" that
they must be rebutted. In particular, you say:
Date: Thu, 22 Jun 89 15:24:58 PDT
From: Jon L White <jonl@lucid.com>
... Let's review the ground rules on what one means by "non-portable" and
"break". If FOO is a primitive specified in the language, and X refers
to some data object calculated by a program, the one would expect
(FOO X) to evaluate the same on two different implementations. The
"same" for type predicates simply means that either both implementations
return true, or both return false.
No, wrong on two points.
For example,
(DEFUN FOO (X) "Determines if FOO is a fixnum." (TYPEP X 'FIXNUM))
might be portable, and yet might yield a different result on different
implementations.
Furthermore, you are not using the working definition of portable for CLtL
. . .
For example, it is currently (under CLtL) conforming for
(SUBTYPEP X anything)
to always return NIL,NIL. As such, any program which ever seriously
expects SUBTYPEP to return T is not portable because there might be a
conforming implementation that violates this assumption.
Just how do claim that FOO "might be portable"? It most certainly isn't
when it uses a construct **** that the X3J13 body has already
determined to be non-portable **** (remember the issue FIXNUM-NON-PORTABLE).
And don't you remember just why we spent so much time arguing and fixing up
the issue SUBTYPEP-TOO-VAGUE? because SUBTYPEP is indeed non-portable!
Perhaps you are thinking that "non-portable" means that it must return
a wrong answer in *all* cases? or that it must "break" when ported to
every conceivable implementation? Compare this to the simple definition
that it is non-portable if there are user-visible variations in the
specification; and note for example how this "simple" definition shows
the type INTEGER to be portable and the type FIXNUM to be non-portable.
Possibly you (and Barry) have overlooked the fact that virtually all CL
implementations except Symbolics' interpreted the definition of
SIMPLE-ARRAY on CLtL p.28 such that my little test case
(typep (make-array 5 :adjustable t) 'simple-array)
is truly portable, even by my simple but stringent definition. [and yes
I know that TI changed their implementation about a year ago to have
the same characteristics on this score as Symbolics -- but their
previous version had it "correct"]
Given that widespread understanding of the type SIMPLE-ARRAY, then one
would only expect to see complaints when porting such code from a Symbolics
implementation to another. Lucid has actual bug reports on file wherein
a person porting some application from running on the 3600 to running on
a Sun3 had precisely this sort of problem -- that the type SIMPLE-ARRAY
acted differntly and disrupted his program. Note well that not every
program so ported from a 3600 to a Sun3 tripped up on this difference;
lots of code just doesn't depend on the contested point.
Unfortunately, Barry seems to have missed this point entirely, since he
dismisses such evidence as "mud-slinging"; surely we can do better than
that!
Finally -- as I have stated so many many times before -- neither Lucid
nor probably any other CL vendor will do anything different as a result
of this proposal. The *only* effect will be that the mechanisms offered
by companies that do depend on the type SIMPLE-ARRAY will be defined to
be in what you called the "gray area" of portability, whereas previously
they were in what we at Lucid (and virtually every other vendor) claimed
was "portable" Common Lisp code. I know that Dick Gabriel understands
this too. Lucid's vote on the "hokey-pokey" issue was a compromise; I
hope the matter can rest there.
-- JonL --
∂05-Jul-89 0027 X3J13-mailer Re: Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Jul 89 00:27:37 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 05 JUL 89 00:25:37 PDT
From: masinter.pa@Xerox.COM
Date: 5 Jul 89 0:23:09 PDT
Subject: Re: Portability? [i.e., not about hokey-pokey ADJUST-ARRAY]
In-reply-to: jonl@lucid.com's message of Tue, 4 Jul 89 21:22:53 PDT,
<8907050422.AA12355@bhopal>
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.com, barmar@Think.com,
Moon@STONY-BROOK.SCRC.Symbolics.com, X3J13@sail.stanford.edu
Message-ID: <890705-002537-5822@Xerox>
I think we need to get straight about "hokey-pokey" vs. "hokum". The
"hokey-pokey" is a kind of a dance. When you "do the hokey-pokey", you have
to perform various motions as called by the "caller", such as "putting the
right foot in".
I presume we can leave to the editorial process to define exactly which
foot is the right foot (is it the "correct foot"? or the "not-the-left-one
foot"? or the "twelve-inch-90-degree-angle foot", as some have
implemented?), but the confusion between "hokey-pokey", which, as I have
said, is a kind of a dance, with "hokum", which I believe, is the kind of
stuff that "snake-oil" salesmen try to sell you -- well, we have to get
this clarified.
"hokum" is that stuff that, in todays electronic culture , might be related
to "bogons", the fundamental element of bogosity. "hokum" must be sold to
be hokum, otherwise, it is mere idle stuff. I don't know if it possible to
swallow hokum, but it sounds plausable. I might even guess that you think
X3J13 had done so, from your, er, tone.
I used to think hokum was also some kind of sticky stuff used by plumbers
to temporarily stop leaks, but I'm pretty sure that's another word for our
glossary. I think it is related only weakly to "howcum", which is " a
reason why". The weak relationship might be found in a sentence such as
"howcum you believe that hokum?" Now, there's a similar relation between
"hokum" and "hokey-pokey" in that you must swallow some amount of "hokum"
to be willing to "do" the "hokey-pokey". At least if you are over the age
of 4. But it isn't a portable relation. You can't carry it from one place
to another.
In any case, unless you want all of X3J13 to "shake it all about", please
get this straight. Is adjusting a non-adjustable array the equivalent of
"putting the left foot in", or is it more like "putting the whole self
out"?
How would ISO respond to a "hokey-pokey" language? Is it too culturally
dependent? Is there a French version of the "hokey-pokey"?
Numerous other questions spring to mind, all of which might be grounds for
further cleanups that we can table indefinitely...
Regards,
Larry
∂05-Jul-89 0206 X3J13-mailer call for participation
Received: from decwrl.dec.com (decwrl.pa.dec.com) by SAIL.Stanford.EDU with TCP; 5 Jul 89 02:06:23 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05186; Wed, 5 Jul 89 02:06:51 PDT
Message-Id: <8907050906.AA05186@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05186; Wed, 5 Jul 89 02:06:51 PDT
From: chapman@aitg.enet.dec.com
Date: 5 Jul 89 04:55
To: x3j13@sail.stanford.edu
Subject: call for participation
The drafting committee is seeking expert reviewers for the standard
in order to produce a draft that reflects the spirit of the industry,
not just a few X3J13 participants. If you or some people you work with
are interested in reviewing a relatively small subset of the standard,
AND you feel that you (or the other person/persons) have the
proper background to review for the following, please let me know
your name, when the best (calendar) time for reviewing is, and your area of
expertise.
Most important reviewing goals:
1. Consistency with X3J13 decisions
2. Technical accuracy
3. Technical consistency
We are looking for two reviewers per section, so state more than one
area of expertise (your favorite first) if applicable.
THE GOODNESS (OR BADNESS) OF THE STANDARD DEPENDS ON YOU!
kathy
∂05-Jul-89 1331 X3J13-mailer Re: Portability?
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 5 Jul 89 13:31:30 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa09014; 5 Jul 89 21:16 BST
Date: Wed, 5 Jul 89 21:22:48 BST
Message-Id: <5337.8907052022@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Portability?
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
KMP@stony-brook.scrc.symbolics.com, barmar@think.com
In-Reply-To: Jon L White's message of Tue, 4 Jul 89 21:22:53 PDT
Cc: Moon@stony-brook.scrc.symbolics.com, X3J13@sail.stanford.edu
> But commentaries sent out by you and Barry in the few days before the
> last X3J13 meeting show so much misunderstanding of "portability" that
> they must be rebutted. In particular, you say:
> [...]
>
> For example,
>
> (DEFUN FOO (X) "Determines if FOO is a fixnum." (TYPEP X 'FIXNUM))
>
> might be portable, and yet might yield a different result on different
> implementations.
I don't think the disagreement is really about "portability" as a
concept so much as about whether certain particular constructs are
portable. But it's quite that simple, because "portable" might
be used in different ways.
Consider the (TYPEP X 'FIXNUM). Is it "portable"? Well, yes. If
someone asks "what is a portable way to test whether X is a fixnum",
"(TYPEP X 'FIXNUM)" would be a reasonable answer. It would be (at
least) less reasonable to answer "there's no portable way to test
whether something is a FIXNUM".
And a non-portable test (in this sense of portable) might be
(sys:is-it-a-fixnum-p x)
What this sense of "portable" seems to amount to is "works correctly
in any conforming implementation of Common Lisp". Portable code, in
this sense, might be able to use nonuniform entities (well, we have to
call them something) such as fixnums if the code is sufficiently
careful.
FOO, considered in isolation, is portable in this sense. But code
using FOO (or fixnums generally) might or might not be portable in
this sense.
The other example was:
> For example, it is currently (under CLtL) conforming for
> (SUBTYPEP X anything)
> to always return NIL,NIL. As such, any program which ever seriously
> expects SUBTYPEP to return T is not portable because there might be a
> conforming implementation that violates this assumption.
If we keep the same definition of portable, this statement appears
to be false. (Ie, portable code can use SUBTYPEP if it takes into
account all of the variations of behavior allowed in conforming
implementations.) Perhaps it depends on what "seriously" is supposed
to imply.
In any case, JonL seems to have something stronger in mind.
Date: Thu, 22 Jun 89 15:24:58 PDT
From: Jon L White <jonl@lucid.com>
... Let's review the ground rules on what one means by "non-portable"
and "break". If FOO is a primitive specified in the language, and X
refers to some data object calculated by a program, the one would
expect (FOO X) to evaluate the same on two different implementations.
The "same" for type predicates simply means that either both
implementations return true, or both return false.
I'm not sure this is well-defined as it stands, because it's not clear
how to tell whether X is the same object in different implementations.
But, when applied to code, the idea seems to be that it's not enough
for the code to meet its specification in every conforming CL -- it
has to get the same result.
Moreover, if we apply this notion to careful code that manipulates
fixnums, it looks like JonL would want us to say it isn't portable
even if, considered as a whole, it gets the same result in every CL,
because it gets different results along the way.
I think this interpretation is consistent with what JonL says in
his 4 July message as well:
> Just how do claim that FOO "might be portable"? It most certainly
> isn't when it uses a construct **** that the X3J13 body has already
> determined to be non-portable **** (remember the issue FIXNUM-NON-
> PORTABLE). And don't you remember just why we spent so much time
> arguing and fixing up the issue SUBTYPEP-TOO-VAGUE? because SUBTYPEP
> is indeed non-portable!
But then JonL writes:
> Perhaps you are thinking that "non-portable" means that it must return
> a wrong answer in *all* cases? or that it must "break" when ported to
> every conceivable implementation? Compare this to the simple definition
> that it is non-portable if there are user-visible variations in the
> specification; and note for example how this "simple" definition shows
> the type INTEGER to be portable and the type FIXNUM to be non-portable.
I think this definition of "non-portable" might not be equivalent to
the "evaluate the same" definition, but it has the advantage of being
easier to work with. (Even thought it's not entirely clear what it
means for a type (as opposed to some code) to be portable.)
Unfortunately, a great many things will be non-portable in this sense,
because there are many places where CLtL allows variations that could
be detected by the user. We'd have to say UNION is non-portable,
for example.
But what it comes down to, however, is not precisely what "portable"
means but whether
> (typep (make-array 5 :adjustable t) 'simple-array)
runs into one of the user-visible variations or not.
Followups to rec.philosophy.misc.
-- Jeff
∂07-Jul-89 0046 X3J13-mailer Portability?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jul 89 00:46:37 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA02303g; Fri, 7 Jul 89 00:43:31 PDT
Received: by bhopal id AA04169g; Fri, 7 Jul 89 00:45:44 PDT
Date: Fri, 7 Jul 89 00:45:44 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907070745.AA04169@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
Cc: KMP@stony-brook.scrc.symbolics.com, barmar@think.com,
Moon@stony-brook.scrc.symbolics.com, X3J13@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Wed, 5 Jul 89 21:22:48 BST <5337.8907052022@aiai.ed.ac.uk>
Subject: Portability?
I rather agree with your analysis and conclusion [just for the record ...].
-- JonL --
∂11-Jul-89 1302 X3J13-mailer issue DEFINE-COMPILER-MACRO
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 89 13:02:47 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29886; Tue, 11 Jul 89 14:03:10 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05354; Tue, 11 Jul 89 14:03:05 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907112003.AA05354@defun.utah.edu>
Date: Tue, 11 Jul 89 14:03:02 MDT
Subject: issue DEFINE-COMPILER-MACRO
To: jonl@lucid.com, smh@franz.com
Cc: x3j13@sail.stanford.edu
The version of this that was passed at the last meeting requires that
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1 not attempt to expand
the compiler macro if the name is shadowed by a local function or
macro definition in the optional environment argument, and also if the
name is declared NOTINLINE in that environment. However, the
description of COMPILER-MACRO-FUNCTION only mentions the shadowing and
says nothing about NOTINLINE declarations. Was this discrepancy
deliberate or an oversight? I would argue that the same constraints
should apply consistently to all three functions.
Also, I am still confused about another subissue. One of the parts of
the amendment Steve had written on the slide was to clarify whether or
not a compiler can ever ignore compiler-macros in other circumstances,
particularly whether the decision could be affected by OPTIMIZE
declarations. (The amendment said it was the responsibility of the
compiler macro function, not the compiler, to check these declarations
in deciding what to return.) This paragraph was unfortunately deleted
by a subsequent amendment, leaving my question unanswered. If the
compiler sees a call that COMPILER-MACROEXPAND would expand, must the
compiler always apply the compiler macro?
-Sandra
-------
∂11-Jul-89 1716 X3J13-mailer issue DEFINE-COMPILER-MACRO
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 11 Jul 89 17:16:31 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA00916; Tue, 11 Jul 89 20:16:44 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA02697; Tue, 11 Jul 89 16:57:39 PDT
Received: by aurora.Franz.COM (3.2/FI-1.0)
id AA02537; Tue, 11 Jul 89 16:54:48 PDT
Date: Tue, 11 Jul 89 16:54:48 PDT
From: smh@Franz.COM (Steve Haflich)
Message-Id: <8907112354.AA02537@aurora.Franz.COM>
To: sandra%defun@cs.utah.edu
Cc: jonl@lucid.com, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 11 Jul 89 14:03:02 MDT <8907112003.AA05354@defun.utah.edu>
Subject: issue DEFINE-COMPILER-MACRO
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
The version of this that was passed at the last meeting requires that
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1 not attempt to expand
the compiler macro if the name is shadowed by a local function or
macro definition in the optional environment argument, and also if the
name is declared NOTINLINE in that environment. However, the
description of COMPILER-MACRO-FUNCTION only mentions the shadowing and
says nothing about NOTINLINE declarations. Was this discrepancy
deliberate or an oversight? I would argue that the same constraints
should apply consistently to all three functions.
This was an oversight. Noticing NOTINLINE declarations is properly
the job of COMPILER-MACRO-FUNCTION. If JonL agrees, I'd say
"editorial clarification."
Also, I am still confused about another subissue. One of the parts of
the amendment Steve had written on the slide was to clarify whether or
not a compiler can ever ignore compiler-macros in other circumstances,
particularly whether the decision could be affected by OPTIMIZE
declarations. (The amendment said it was the responsibility of the
compiler macro function, not the compiler, to check these declarations
in deciding what to return.) This paragraph was unfortunately deleted
by a subsequent amendment, leaving my question unanswered. If the
compiler sees a call that COMPILER-MACROEXPAND would expand, must the
compiler always apply the compiler macro?
Unfortunately, I didn't walk away from the meeting with the exact copy
of the text voted. (I believe Mary recorded it.) The intention of
the proposal was that the compiler *must* expand compiler macros, and
that the interpreter *may* expand them. (Permission for interpreters
to expand compiler macros is intended to only apply if that is the
natural thing for a particular implementation to do, say, a
compiler-only implementation.) I believe it would be unfortunate if
the amendments have weakened the requirement on the compiler, but it
would not be a fatal flaw. Since several important and knowledgeable
application developers have expressed string desire for compiler
macros, a compiler that effectively ignored them might find itself
competitively disadvantaged.
∂11-Jul-89 1827 X3J13-mailer issue DEFINE-COMPILER-MACRO
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jul 89 18:27:36 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA14464g; Tue, 11 Jul 89 18:22:07 PDT
Received: by bhopal id AA12092g; Tue, 11 Jul 89 18:22:49 PDT
Date: Tue, 11 Jul 89 18:22:49 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907120122.AA12092@bhopal>
To: sandra%defun@cs.utah.edu
Cc: smh@franz.com, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 11 Jul 89 14:03:02 MDT <8907112003.AA05354@defun.utah.edu>
Subject: issue DEFINE-COMPILER-MACRO
re: The version of this that was passed at the last meeting requires that
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1 not attempt to expand
the compiler macro if the name is shadowed by a local function or
macro definition in the optional environment argument, and also if the
name is declared NOTINLINE in that environment. However, the
description of COMPILER-MACRO-FUNCTION only mentions the shadowing and
says nothing about NOTINLINE declarations. Was this discrepancy
deliberate or an oversight? I would argue that the same constraints
should apply consistently to all three functions.
I'm not sure how deliberate this discrepancy was, but it probably resulted
from the following "goals":
(1) COMPILER-MACRO-FUNCTION should return the expander function that
is appropriate for this lexical environment; since compiler macros
are global, then local function/macro bindings "shadow" the global
definition. This definition holds regardless of whether or not
the form under consideration is being compiled.
(2) The compiler should always expand macro calls (and of course a
global macro definition might be shadowed by a lexical function
or macro) EXCEPT when there is a NOTINLINE declaration on that
name. If COMPILER-MACROEXPAND doesn't filter out INLINE cases,
then the compiler's usages should be so required to do so.
I wonder what the state with ordinary (global) macros is? I'm sure that
we passed issues relating to an &environment argument for MACRO-FUNCTION,
CLtL specifically mentions local macros for MACROEXPAND, but doesn't
mention INLINE declarations; was this matter ever brought up in the
Cleanup committee? I can't remember.
Possibly one might strive for consistency between MACROEXPAND and
COMPILER-MACROEXPAND, but I'm not so sure that MACROEXPAND ought
to pay attention to INLINE declarations.
re: If the compiler sees a call that COMPILER-MACROEXPAND would expand,
must the compiler always apply the compiler macro?
I thought this got answered in the affirmative [but I have neither the
original slide text (which I presented) nor the ammending text (which
Steve presented)]. Again, the usual exception for any special compiler
handling is when the name is declared NOTINLINE. Apart from that, isn't
it true that the compiler can't selectively decide not to expand ordinary
macros? I thought we had a "mimimalist" definition of compilation
that required at least that much.
-- JonL --
∂11-Jul-89 2006 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 89 20:06:34 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10300; Tue, 11 Jul 89 21:07:04 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05623; Tue, 11 Jul 89 21:07:02 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907120307.AA05623@defun.utah.edu>
Date: Tue, 11 Jul 89 21:07:00 MDT
Subject: Re: issue DEFINE-COMPILER-MACRO
To: jonl@lucid.com, smh@franz.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 11 Jul 89 18:22:49 PDT
> From: smh@Franz.COM (Steve Haflich)
>
> Unfortunately, I didn't walk away from the meeting with the exact copy
> of the text voted. (I believe Mary recorded it.) The intention of
> the proposal was that the compiler *must* expand compiler macros, and
> that the interpreter *may* expand them.
> From: Jon L White <jonl@lucid.com>
>
> re: If the compiler sees a call that COMPILER-MACROEXPAND would expand,
> must the compiler always apply the compiler macro?
>
> I thought this got answered in the affirmative [but I have neither the
> original slide text (which I presented) nor the ammending text (which
> Steve presented)].
Here is the relevant text from the slide, from the copy of the minutes I found
on arisia:
Page 3 - Add after paragraph 2:
Note that if the expansion/nonexpansion of a compiler macro is to be
controlled by the compilation optimize declarations, it is up to the
compiler macro to consult these declarations (using the
DECLARATION-INFORMATION function).
(...)
JonL moved, and Barry seconded, an amendment to the amendment to remove
the first paragraph added after paragraph 2. The amendment passed 8-4.
I don't understand why this clarification was removed, since both of
you now seem to be in agreement that the original spirit of the
proposal was that invocation of the compiler macro function by the
compiler is unconditional.
Conditionalizing optimizations based on OPTIMIZE declarations seems
like something users would commonly want to do. For example, it could
be used as a mechanism for bypassing explicit error checking in
"unsafe" code. Also, it would be reasonable for the OPTIMIZE DEBUG
declaration to inhibit inline coding (or other compiler magic) in
order to make more traceback information available for debugging. I
don't care much whether the responsibility for this rests with the
compiler or with individual compiler macro functions, but I think the
standard ought to be clear one way or the other.
Since nobody seems to have both the hardcopy proposal and the
amendments other than myself, I guess I'm nominated to type up the new
version for the archives. :-(
-Sandra
-------
∂12-Jul-89 0023 X3J13-mailer passed cl-compiler issues
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jul 89 00:23:35 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA19966; Wed, 12 Jul 89 00:22:36 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA16589; Wed, 12 Jul 89 00:23:54 PDT
Message-Id: <8907120723.AA16589@masunter.parc.xerox.com>
Date: Wed, 12 Jul 89 00:23:54 PDT
From: <masinter@arisia.Xerox.COM>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 4 Jul 89 11:06:09 MDT <8907041706.AA00645@defun.utah.edu>
Reply-To: masinter@arisia.Xerox.COM
Subject: passed cl-compiler issues
I've copied the passed compiler issues to arisia.xerox.com also;
I've been asked to set up an archive of other "passed" items in addition
to the cleanups...
I'd like copies of:
The "Loop" proposal
The "pretty-print-interface" proposal as finally modified
The "condition system" (I'll pull this off the file KMP mailed)
The passed issues in the character proposal.
I'm missing a couple of cleanup issues, but otherwise
arisia.xerox.com:clcleanup is pretty much up to date.
∂12-Jul-89 0944 X3J13-mailer re: issue DEFINE-COMPILER-MACRO
To: sandra%defun@CS.UTAH.EDU, jonl@LUCID.COM, smh@FRANZ.COM
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from sandra%defun@cs.utah.edu sent Tue, 11 Jul 89 14:03:02 MDT.]
My take on this is that it is unspecified whether the function or the
compiler macro will be used by the compiler if a compiler macro is
present. This oversight(?) was what caused me to favor the proposal. I was
worried that people would ignore maintaining either the function or the
compiler macro once both were working. This way, no programmer can ever be
sure which will be used in a porting situation, so both must always be
maintained.
-rpg-
∂12-Jul-89 0919 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jul 89 09:19:26 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29882; Wed, 12 Jul 89 10:19:57 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06014; Wed, 12 Jul 89 10:19:55 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907121619.AA06014@defun.utah.edu>
Date: Wed, 12 Jul 89 10:19:53 MDT
Subject: issue DEFINE-COMPILER-MACRO, version 2
To: x3j13@sail.stanford.edu
Here is the version of DEFINE-COMPILER-MACRO that was passed at the
meeting, including the amendments. I have fixed some obvious typos
(and probably introduced a few more of my own) as I retyped this, but
have not otherwise attempted to clean up the language.
Forum: Cleanup
Issue: DEFINE-COMPILER-MACRO
Related Issues: Issue DEFINE-OPTIMIZER
Issue SYNTACTIC-ENVIRONMENT-ACCESS
Issue LISP-SYMBOL-REDEFINITION
References: CLtL p. 151, p. 152
Category: ADDITION
Edit-History: 28-Jun-89, Version 1 by JonL WHite and Steve Haflich
12-Jul-89, Version 2 by Loosemore
Status: Passed, as amended, at June 89 meeting.
Problem Description:
Occasionally one would like to define a macro which is expanded only
"in the compiler", but which would not normally affect the actions of
the interpreter. For example, the OSS/Generator proposal has several
functions for which it would like to specify some alternative source
code sequences for the compiler to compiler, rather than just
compiling a closed-call to the function.
Also, it is occasionally desirable for a macro expansion to be
different based on the various compiler optimization qualities (e.g.,
SPEED, SAFETY, and so on); but if the expansion is for the interpreter
rather than the compiler, then such variation based on compiler
optimizers is not needed.
So-called "compiler optimizers" are just a special case of macro-like
expansions, which are limited to being done "in the compiler" and
which are generally required to produce semantically equivalent code
to replace an apparent function call. There is a need for a facility
that at least covers this capability.
Proposal: (DEFINE-COMPILER-MACRO:NEW-FACILITY)
Introduce a new facility by additions as follows:
Macro:
DEFINE-COMPILER-MACRO name lambda-list {doc-string} {declarations}* {form}*
This is just like DEFMACRO except the definition isn't stored in the
symbol function cell of 'name', and isn't seen by MACROEXPAND-1 (but
is seen by COMPILER-MACROEXPAND-1 -- see below). Like DEFMACRO, the
lambdalist may include &ENVIRONMENT and &WHOLE. The definition is
"global"; there is no explicit provision for defining local compiler
macros in the way that MACROLET defines local macros.
A toplevel call to DEFINE-COMPILER-MACRO in a file being compiled by
COMPILE-FILE has an effect on the compilation environment similar to
what a call to DEFMACRO would have, except it is noticed as a
"compiler macro".
Function:
COMPILER-MACRO-FUNCTION name &OPTIONAL env
If 'name' is a symbol that has been defined as a compiler macro, then
calling COMPILER-MACRO-FUNCTION on it returns the macro expansion
function; otherwise it returns NIL. 'name' must be a symbol. The
local lexical environment may override a global definition for 'name'
by defining a local function or local macro (such as by FLET,
MACROLET, etc.), in which case NIL is returned; the optional argument
'env' is provided so that clients may pass in &environment objects for
this purpose.
SETF may be used with COMPILER-MACRO-FUNCTION to install a function as
the expansion function for the compiler macro 'name', analogously to
using SETF on MACRO-FUNCTION. SETF'ing to NIL removes any existing
compiler macro definition. Like MACRO-FUNCTION, the SETF value (if not
NIL) must be a function of two arguments: the entire macro call, and
the environment. The second argument to COMPILER-MACRO-FUNCTION must
be omitted when it is SETFed.
Functions:
COMPILER-MACROEXPAND form &OPTIONAL env
COMPILER-MACROEXPAND-1 form &OPTIONAL env
This is just like MACROEXPAND and MACROEXPAND-1 (see CLtL p.151)
except that the expander function is obtained as if by a call to
COMPILER-MACRO-FUNCTION on the CAR of 'form' rather than by a call to
MACRO-FUNCTION. There are three cases wherein no expansion happens:
(1) There is no compiler macro definition for the CAR of 'form';
(2) There is such a definition but there is also a NOTINLINE
declaration, either globally or in the lexical environment 'env';
(3) A global compiler macro definition is shadowed by a local
function or macro definition (such as by FLET, LABELS, or MACROLET).
Note that if there is not expansion, the original form is returned as
the first value, and NIL as the second value.
When COMPILER-MACROEXPAND-1 discovers that there is to be an expansion
it does it by calling the function in *MACROEXPAND-HOOK* (see CltL p.152).
The purpose of this facility is to permit selective source-code
transformations based on whether the compiler is processing the code.
When the compiler is about to compile a nonatomic form, it first calls
COMPILER-MACROEXPAND-1 repeatedly until there is no more expansion
(there might not be any to begin with). Then it continues its
remaining processing, which may include calling MACROEXPAND-1 etc.
The compiler is required to expand compiler macros; it is unspecified
whether the interpreter does so. The intention is that only the
compiler will do so, but the range of possible "compiled-only"
implementation strategies precludes any firm specification.
Note that a compiler macro may decline to provide any expansion merely
by returning the original form; this is useful when using the facility
to put "compiler optimizers" on various function names. For example,
here is a compiler macro that "optimizes" the 0- and 1-argument cases of
a function called PLUS:
(define-compiler-macro plus (&whole form &rest args)
(case (length args)
(0 0)
(1 (car args))
(t form)))
The issue LISP-SYMBOL-REDEFINITION precludes user definition of any
compiler macros for symbols external in the Lisp package that have a
definition as a function, macro, or special form.
Note that compiler macros do not appear in information returned by
FUNCTION-INFORMATION; they are global, and their interaction
with other lexical and global definitions can be reconstructed by
COMPILER-MACRO-FUNCTION. It is up to code-walking programs to decide
whether to invoke compiler macro expansion.
Rationale:
Many implementations have it. Many users have requested a way to add
source-code "optimizers" to the compiler.
Other than INLINE declarations for functions there is no other way to
customize how calls to a specific function are compiled. DEFMACRO is
not usable for this purpose since it requires use of the
symbol-function cell, which would prevent the functional definition
from being active in the compilation environment.
Current Practice:
Lucid, Franz, and Symbolics have very similar facilities. Hunoz about
the others?
Cost to Implementors:
Minor: implement a method for storing named expansion functions, and
tweak the compiler in one or two places.
Cost to Users:
None. This is an upward-compatible addition.
Benefits:
Increased portability for clients of the existing facilities.
Discussion:
There has been extensive discussion under the issue DEFINE-OPTIMIZER.
-------
∂12-Jul-89 1003 X3J13-mailer re: issue DEFINE-COMPILER-MACRO, version 2
To: sandra%defun@CS.UTAH.EDU, x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from sandra%defun@cs.utah.edu sent Wed, 12 Jul 89 10:19:53 MDT.]
I don't believe this is a fair copy. I believe it was left unspecified
whether the compiler would expand any compiler macros. I recall that the
reason for this apparently strange behavior was so that the compiler could
determine whether the SIZE attribute overruled the use of too-large code.
Possibly this interpretation is pedantically valid in your rewrite because
the compiler must expand the macro, but it might discard the expansion.
The provision I do remember was that if the compiler expanded any compiler
macros, it would expand them all. This was included to allow compiler
macros to communicate among themselves. This issue was the crucial one for
me, so patching it over like this is not acceptable. If you want to change
the proposal, I think a cleanup is in order.
-rpg-
∂12-Jul-89 1024 X3J13-mailer re: issue DEFINE-COMPILER-MACRO, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jul 89 10:24:15 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02553; Wed, 12 Jul 89 11:24:44 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06070; Wed, 12 Jul 89 11:24:41 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907121724.AA06070@defun.utah.edu>
Date: Wed, 12 Jul 89 11:24:40 MDT
Subject: re: issue DEFINE-COMPILER-MACRO, version 2
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: x3j13@SAIL.Stanford.EDU
In-Reply-To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, 12 Jul 89 1003 PDT
> Date: 12 Jul 89 1003 PDT
> From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
>
> I don't believe this is a fair copy. I believe it was left unspecified
> whether the compiler would expand any compiler macros. I recall that the
> reason for this apparently strange behavior was so that the compiler could
> determine whether the SIZE attribute overruled the use of too-large code.
> Possibly this interpretation is pedantically valid in your rewrite because
> the compiler must expand the macro, but it might discard the expansion.
Perhaps I wasn't clear enough when I mailed this out. Version 2 was
not a "rewrite". I retyped the hardcopy of version 1 that was
distributed at the meeting and added the amendments that were in
Mary's minutes. I did not make any additional changes or
interpolations of my own other than fixing a few typos, as I noted.
I don't remember if the other points you mentioned were discussed at
the meeting or not. They weren't recorded in the minutes, anyway.
-Sandra
-------
∂12-Jul-89 1359 X3J13-mailer issue DEFINE-COMPILER-MACRO
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 12 Jul 89 13:59:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 624319; 12 Jul 89 17:00:08 EDT
Date: Wed, 12 Jul 89 17:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-COMPILER-MACRO
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Steve Haflich <smh@Franz.COM>,
Jon L White <jonl@lucid.com>, Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8907112003.AA05354@defun.utah.edu>,
<8907112354.AA02537@aurora.Franz.COM>,
<8907120122.AA12092@bhopal>,
<8907120307.AA05623@defun.utah.edu>,
<8907121619.AA06014@defun.utah.edu>,
<RrXSX@SAIL.Stanford.EDU>,
<jrXeM@SAIL.Stanford.EDU>,
<8907121724.AA06070@defun.utah.edu>
Message-ID: <19890712210002.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
[enclosed messages have been edited for brevity]
There are two main issues here, as well as a few remarks of less importance.
One issue is whether to change the specification so that
COMPILER-MACRO-FUNCTION is disabled by NOTINLINE declarations. I argue
that the status quo is correct.
The second issue is in what circumstances the expansion returned by a
compiler macro is guaranteed to be used instead of the original form. I
argue that there should be no such circumstances, and that the proposal
as we voted on it appeared (to some of us) to say that, but turns out to
be ambiguous. There appears to be disagreement here, although it's hard
to be sure since the issue has been stated in various ambiguous ways,
and we must reach some concensus.
Date: Tue, 11 Jul 89 14:03:02 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
The version of this that was passed at the last meeting requires that
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1 not attempt to expand
the compiler macro if the name is shadowed by a local function or
macro definition in the optional environment argument, and also if the
name is declared NOTINLINE in that environment. However, the
description of COMPILER-MACRO-FUNCTION only mentions the shadowing and
says nothing about NOTINLINE declarations. Was this discrepancy
deliberate or an oversight?
I'm sure it's deliberate. Certainly if the proposal had said that the
COMPILER-MACRO-FUNCTION is disabled by NOTINLINE declarations, I would
have proposed an amendment to remove that misfeature.
COMPILER-MACRO-FUNCTION should tell you whether the compiler macro is
defined, which is different from whether the compiler is supposed to use
it. There has to be a way to find out whether it's defined. I don't
think there is any real discrepancy or inconsistency here.
Also, I am still confused about another subissue. One of the parts of
the amendment Steve had written on the slide was to clarify whether or
not a compiler can ever ignore compiler-macros in other circumstances,
particularly whether the decision could be affected by OPTIMIZE
declarations. (The amendment said it was the responsibility of the
compiler macro function, not the compiler, to check these declarations
in deciding what to return.) This paragraph was unfortunately deleted
by a subsequent amendment, leaving my question unanswered. If the
compiler sees a call that COMPILER-MACROEXPAND would expand, must the
compiler always apply the compiler macro?
There are two issues here, one is whether the compiler must always apply
the compiler macro, and the second is whether the compiler is required to
do anything specific with what the compiler macro returns. What I thought
I was voting for when I voted for this was that the compiler must apply
the compiler macro, but it is unspecified whether, when you disassemble
the compiled code, you see the original function call or see instructions
resulting from the compiler-macro expansion.
I see that the amended writeup, like the original, is ambiguous and
could be read either in the way that I paraphrased above, or could be
read as saying that the compiler must compile code based on the
compiler-macro expansion. We need to decide which it is. I think that
if interested parties can come to a concensus on the intent, the words
could be made unambiguous by the drafting committee.
Date: Tue, 11 Jul 89 16:54:48 PDT
From: smh@Franz.COM (Steve Haflich)
This was an oversight. Noticing NOTINLINE declarations is properly
the job of COMPILER-MACRO-FUNCTION.
I very strongly disagree. I think if you think about it more, you'll
most likely change your mind. The superficial consistency of making
COMPILER-MACRO-FUNCTION look for NOTINLINE can mislead one into not
thinking further about why the COMPILER-MACRO-FUNCTION function exists.
The intention of
the proposal was that the compiler *must* expand compiler macros, and
that the interpreter *may* expand them. (Permission for interpreters
to expand compiler macros is intended to only apply if that is the
natural thing for a particular implementation to do, say, a
compiler-only implementation.)
I'm not sure which way the above statement stands on the ambiguity I noted
above.
Of course, we really want to avoid saying the interpreter does one thing
and the compiler does something else, so I dislike the particular choice
of words you use. I would much rather say that it is unspecified
whether a language processor obeys compiler macros, but the intention is
that they will be obeyed when it is more optimal to do so, where the
definition of "optimal" of course is implementation-dependent, but might
be guided by the OPTIMIZE declaration. This is consistent with
everything else about compilation. Does that make sense?
Date: Tue, 11 Jul 89 18:22:49 PDT
From: Jon L White <jonl@lucid.com>
re: If the compiler sees a call that COMPILER-MACROEXPAND would expand,
must the compiler always apply the compiler macro?
I thought this got answered in the affirmative...
I'm not sure which way the above statement stands on the ambiguity I noted
above.
Apart from that, isn't
it true that the compiler can't selectively decide not to expand ordinary
macros? I thought we had a "mimimalist" definition of compilation
that required at least that much.
That's a separate issue, because evaluation cannot occur without expanding
an ordinary macro, therefore they will always be expanded eventually, if the
form is evaluated, and we need only talk about -when- they get expanded.
With compiler macros, we can talk about -whether- they get expanded, because
there are two possible ways to evaluate the form, either via the compiler
macro or just by calling the function, and both ways produce correct results.
Date: Tue, 11 Jul 89 21:07:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Conditionalizing optimizations based on OPTIMIZE declarations seems
like something users would commonly want to do.
I certainly agree.
Date: Wed, 12 Jul 89 10:19:53 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Here is the version of DEFINE-COMPILER-MACRO that was passed at the
meeting, including the amendments. I have fixed some obvious typos
(and probably introduced a few more of my own) as I retyped this, but
have not otherwise attempted to clean up the language.
I noticed a few typos in this but they don't affect the sense, so I won't
comment on them now. Thanks for taking the trouble to type this in.
By the way, the issue name should not have been changed from DEFINE-OPTIMIZER.
Even though the name of the defining form was changed, we normally retain
the same issue name so as to retain the history of discussion for the
benefit of later historians. So this issue should be published as
version 8 of DEFINE-OPTIMIZER (version 7 would be the version prior to
the amendments). Also the forum is compiler, not cleanup. Note that the
answer to the second issue was quite clear back in version 6. I don't
know if the major rewrite that created version 7 was intended to change
this, or only changed it accidentally.
Date: 12 Jul 89 0944 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
My take on this is that it is unspecified whether the function or the
compiler macro will be used by the compiler if a compiler macro is
present.
That's what I thought we were voting for also.
Date: 12 Jul 89 1003 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I recall that the
reason for this apparently strange behavior was so that the compiler could
determine whether the SIZE attribute overruled the use of too-large code.
Possibly this interpretation is pedantically valid in your rewrite because
the compiler must expand the macro, but it might discard the expansion.
That (the last sentence) is what I thought was said during the discussion at
the meeting.
The provision I do remember was that if the compiler expanded any compiler
macros, it would expand them all. This was included to allow compiler
macros to communicate among themselves.
I don't know how to define the scope of "all", I don't think compiler macros
communicating among themselves is good practice, and there isn't anything
about this in the proposal as amended, so I suggest that we just drop any
concept of interactions among distinct compiler macro invocations.
This issue was the crucial one for
me
Which issue? Compiler macro intercommunication, or allowing the compiler to
decide whether or not to use a compiler macro expansion? The latter, I hope.
That's the crucial one for me also.
∂12-Jul-89 1435 X3J13-mailer issue DEFINE-COMPILER-MACRO
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:35:17 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA20904g; Wed, 12 Jul 89 14:32:29 PDT
Received: by bhopal id AA14129g; Wed, 12 Jul 89 14:34:36 PDT
Date: Wed, 12 Jul 89 14:34:36 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907122134.AA14129@bhopal>
To: sandra%defun@cs.utah.edu
Cc: smh@franz.com, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 11 Jul 89 21:07:00 MDT <8907120307.AA05623@defun.utah.edu>
Subject: issue DEFINE-COMPILER-MACRO
re: Since nobody seems to have both the hardcopy proposal and the
amendments other than myself, I guess I'm nominated to type up the new
version for the archives. :-(
I had presumed that the minutes would reflect the final copy voted
upon in Palo Alto. I certainly don't remember my motion to strike
a certain clause of the amendments as applying to the part that
certified that the compiler must expand compiler-macros; to me, this
goes hand-in-hand with the expectation that the compiler must
expand (regular) macros, and I'm sure the discussion in Palo Alto
reflected that. This is one of the very certain distinctions of
compiler-macros over "optimizers".
-- JonL --
∂12-Jul-89 1459 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jul 89 14:59:10 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA13353; Wed, 12 Jul 89 15:58:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06269; Wed, 12 Jul 89 15:58:44 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907122158.AA06269@defun.utah.edu>
Date: Wed, 12 Jul 89 15:58:43 MDT
Subject: Re: issue DEFINE-COMPILER-MACRO
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Steve Haflich <smh@Franz.COM>, Jon L White <jonl@lucid.com>,
Dick Gabriel <RPG@SAIL.Stanford.EDU>, masinter.pa@xerox.com,
x3j13@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 12 Jul 89 17:00 EDT
Let me try to summarize briefly what the current state of this issue is.
There seem to be four unresolved questions:
(1) Under what circumstances does COMPILER-MACRO-FUNCTION return non-NIL?
(2) Under what circumstances does COMPILER-MACROEXPAND invoke the compiler
macro function and return its result?
(3) Under what circumstances does the compiler invoke the compiler macro
function?
(4) Under what circumstances does the compiler actually use the expansion
returned by invoking the compiler macro function?
The actual proposal we voted on is vague and/or contradictory on all
four of these questions. I think the most productive thing to do at
this point is to agree that it's broken and try to fix it, instead of
arguing over what the current wording says or was intended to say,
since everybody seems to have their own interpretation. Maybe we need
another self-selected committee to clean up the remaining problems
with this issue, like we did for the prettyprinter issue? I don't
think it's practical to wait until the next meeting in November to
resolve this.
Incidentally, this issue is indeed a cleanup issue regardless of the
name change, since it was transferred there from the compiler
committee before it was re-opened. If Larry wants to transfer it back
to compiler now, though, I wouldn't blame him.... :-(
-Sandra
-------
∂12-Jul-89 1550 X3J13-mailer passed cl-compiler issues
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jul 89 15:50:16 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA21869g; Wed, 12 Jul 89 15:47:45 PDT
Received: by bhopal id AA14443g; Wed, 12 Jul 89 15:49:57 PDT
Date: Wed, 12 Jul 89 15:49:57 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907122249.AA14443@bhopal>
To: masinter@arisia.Xerox.COM
Cc: sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
In-Reply-To: <masinter@arisia.Xerox.COM>'s message of Wed, 12 Jul 89 00:23:54 PDT <8907120723.AA16589@masunter.parc.xerox.com>
Subject: passed cl-compiler issues
I have no reasonable electronic copy of the LOOP proposal. Cathy has
already altered the format substantially in her copies, and I've proofread
two versions of it already. Presumably, some final version of _her_ editing
is what you would want anyway.
-- JonL --
∂13-Jul-89 0757 X3J13-mailer re: issue DEFINE-COMPILER-MACRO
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
sandra%defun@CS.UTAH.EDU, smh@FRANZ.COM, jonl@LUCID.COM
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Wed, 12 Jul 89 17:00 EDT.]
Upon reflection, I agree with Moon: compiler macros should always be expanded
by the compiler, but it should left unspecified what happens with the form
returned.
Steele had an interesting idea. He thought that compiler macros (which
require an additional namespace) are a hack in place there being a generic
function named something like COMPILE-FORM-1 whose default method
considers whether the form is a special form, macro call, or function
call, doing the proper thing. User-defined methods could shadow that
behavior. Note that this alternative solution makes it clear that
special forms can be overridden.
-rpg-
∂13-Jul-89 0903 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jul 89 09:03:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 624717; 13 Jul 89 12:02:43 EDT
Date: Thu, 13 Jul 89 12:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINE-COMPILER-MACRO
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Steve Haflich <smh@Franz.COM>, Jon L White <jonl@lucid.com>, Dick Gabriel <RPG@SAIL.Stanford.EDU>,
masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <8907122158.AA06269@defun.utah.edu>
Message-ID: <19890713160237.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 12 Jul 89 15:58:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Let me try to summarize briefly what the current state of this issue is.
There seem to be four unresolved questions:
(1) Under what circumstances does COMPILER-MACRO-FUNCTION return non-NIL?
(2) Under what circumstances does COMPILER-MACROEXPAND invoke the compiler
macro function and return its result?
(3) Under what circumstances does the compiler invoke the compiler macro
function?
(4) Under what circumstances does the compiler actually use the expansion
returned by invoking the compiler macro function?
To be constructive, here are my opinions on what the answers to these
four questions should be. An interesting question is whether others
have contradictory opinions, or whether (aside from wording) we actually
all agree now.
(1) Same as MACRO-FUNCTION; looks for shadowing definitions, but does
not look for NOTINLINE declarations. This is what the proposal as
amended and passed says.
(2) When the COMPILER-MACRO-FUNCTION is non-NIL and there is no
NOTINLINE declaration. This is what the proposal as amended and passed
says. This one is not controversial, I believe.
(3) Unspecified circumstances, since we do not want to draw distinctions
between the compiler and the interpreter. However, the proposal as
amended and passed says "The compiler is required to expand compiler
macros; it is unspecified whether the interpreter does so."
(4) Unspecified circumstances. The proposal as amended and passed is
unclear on this point.
The actual proposal we voted on is vague and/or contradictory on all
four of these questions.
Only on 3 and 4, as far as I can see.
Maybe we need
another self-selected committee to clean up the remaining problems
with this issue, like we did for the prettyprinter issue?
That would be okay with me, as long as everyone who seems likely to
complain about the result is co-opted by being made a member of the
committee.
Incidentally, this issue is indeed a cleanup issue regardless of the
name change, since it was transferred there from the compiler
committee before it was re-opened.
OK, I had missed that.
∂13-Jul-89 0958 X3J13-mailer issue DEFINE-COMPILER-MACRO
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 13 Jul 89 09:58:22 PDT
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 12:58:40 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 12:56:55 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 12:56:40 EDT
Date: Thu, 13 Jul 89 12:56:40 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8907131656.AA13108@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: sandra%defun@cs.utah.edu, smh@franz.com, jonl@lucid.com,
RPG@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 12 Jul 89 17:00 EDT <19890712210002.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DEFINE-COMPILER-MACRO
My recollection of what was passed at the meeting agrees with
the interpretations recalled by Moon and RPG. I agree with
what Moon has said.
--Guy
∂13-Jul-89 1030 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jul 89 10:29:56 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10300; Thu, 13 Jul 89 11:29:42 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06791; Thu, 13 Jul 89 11:29:39 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907131729.AA06791@defun.utah.edu>
Date: Thu, 13 Jul 89 11:29:37 MDT
Subject: Re: issue DEFINE-COMPILER-MACRO
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Steve Haflich <smh@Franz.COM>, Jon L White <jonl@lucid.com>,
Dick Gabriel <RPG@SAIL.Stanford.EDU>, masinter.pa@xerox.com,
x3j13@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 13 Jul 89 12:02 EDT
> Date: Thu, 13 Jul 89 12:02 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> (1) Same as MACRO-FUNCTION; looks for shadowing definitions, but does
> not look for NOTINLINE declarations. This is what the proposal as
> amended and passed says.
>
> (2) When the COMPILER-MACRO-FUNCTION is non-NIL and there is no
> NOTINLINE declaration. This is what the proposal as amended and passed
> says. This one is not controversial, I believe.
Wrong: I believe very strongly that the answers to questions (1) and
(2) should be the same. I think the actual wording of the proposal is
indeed somewhat contradictory on this, because it also says that
COMPILER-MACROEXPAND is *just like* MACROEXPAND except that it uses
COMPILER-MACRO-FUNCTION instead of MACRO-FUNCTION. (I don't think
anybody disputes that MACROEXPAND uses the same rules as
MACRO-FUNCTION now that they both accept an environment argument; see
the writeup for issue MACRO-FUNCTION-ENVIRONMENT.)
If we don't want to make COMPILER-MACRO-FUNCTION look for NOTINLINE
declarations, I'd be just as happy making NOTINLINE ignored in both
situations and leaving it up to the individual compiler macros to test
for them, as well as for OPTIMIZE declarations. Alternatively, we
could make the testing for NOTINLINE declarations something specific
to the compiler (move it to situations 3 and/or 4).
> (3) Unspecified circumstances, since we do not want to draw distinctions
> between the compiler and the interpreter. However, the proposal as
> amended and passed says "The compiler is required to expand compiler
> macros; it is unspecified whether the interpreter does so."
I don't have any problems with either the current wording or leaving
it unspecified. The compilation model already requires the compiler
to do particular kinds of processing that can differ from what the
interpreter does, so I don't see the harm in adding one more thing.
> (4) Unspecified circumstances. The proposal as amended and passed is
> unclear on this point.
Again, I have no strong feelings on this question, although I think
that if you give compilers permission *not* to expand compiler macros
in the first place, implementations are very unlikely to go through
the work of expanding the compiler macro only to throw away the
result.
-Sandra
-------
∂13-Jul-89 1224 CL-Cleanup-mailer issue DEFINE-COMPILER-MACRO
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Jul 89 12:23:29 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA15589g; Thu, 13 Jul 89 12:19:58 PDT
Received: by bhopal id AA16436g; Thu, 13 Jul 89 12:22:05 PDT
Date: Thu, 13 Jul 89 12:22:05 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907131922.AA16436@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, smh@Franz.COM, RPG@SAIL.Stanford.EDU,
masinter.pa@xerox.com, x3j13@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 13 Jul 89 12:02 EDT <19890713160237.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DEFINE-COMPILER-MACRO
Like you, I think Sandra's questions (1) and (2) really are moot, in
the context of the passed proposal.
But I'm a bit unclear about her question (3) -- "Under what circumstances
does the compiler invoke the compiler macro function?" -- is this a
roundabout way of saying "When does the compiler actually call the expander
function, regardless of whether it is going to use the result or not?" If
so, then it may be the same pedantic point that we have never actually
settled for normal macros, and I don't see any value to trying to solve it
for compiler macros but leaving it unsettled for regular macros.
And about question (4) -- Under what circumstances may the compiler ignore
the result of compiler-macro expansion, and simply emit, say, a function
call -- I don't agree that the proposal is silent on this issue. It may
not cover every conceivable circumstance, but it certainly makes very clear
that NOTINLINE overrides use of the result, and that there is a special
distinguished value that the expander function may return which effectively
means "ignore the existence of this compiler-macro definition."
Actually, I don't see much to be gained by continuing a public discussion
on these minor points. Rather than see yet another self-selected committee
pop up to continue the debate, I would suggest that, you, Dave Moon, as a
member of the drafting committee simply "clarify" any points you feel are
ambiguous and troublesome. My only input is the guidelines which I think
are either implicitly or explicitly stated in the proposal and verbal
discussion at Palo Alto:
**** Compiler-macros should be a close in spirit to regular macros
as possible, except for the points just below, to reduce the
intellectual overload of yet-another-idiosyncratic-feature;
The explicit differences (drawn from the current standard
practice at Lucid, and maybe Symbolics and Franz?) are:
(1) compiler-macros do not share the symbol-function cell with
functions and regular macros; thus one may have both a
function/macro definition as well as a compiler-macro defintion
on a name, and the general rule of applicability is whether
or not the expansion is "for compiling".
(2) There is distinguished return value which if returned by a compiler
macro expansion function effective means "ignore this compiler
macro definition".
(3) Interpreters, for implementations that have distinct interpreter
and compiler, will not expand (or use) compiler macros.
Although we agree that NOTINLINE declarations override the use of
compiler macro expansion, I hope very much that this isn't a difference
from regular macro semantics. [Have we at least stated somewhere that
NOTINLINE overrides the use or regular macro expansions?]
*** It is reasonable to leave it unspecified whether or not high
safety or low speed settings in the compiler disable the use
of compiler macro expansions [actually, I mean to say, whether
or not the compiler causes a implicit NOTINLINE declarations to
occur whenever some optimize quality is active]. This was the
point I thought I was championing by moving to delete a certain
part of Steve's proposed amendments.
*** I think it would be disastrous if the compiler were permitted to
"flip a coin" to determine whether or not to use the results of
macro expansion (compiler or otherwise). The programmer ought to
have resonable control, such as through explicit NOTINLINE or
OPTIMIZE declarations. But I don't care very much what syntax
is necessary to exercise that control.
I you agree in spirit with these guidelines, and are willing to take
on the task for the drafting committee, then I will have nothing further
to say.
-- JonL --
∂13-Jul-89 1539 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jul 89 15:39:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 625187; 13 Jul 89 18:40:22 EDT
Date: Thu, 13 Jul 89 18:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINE-COMPILER-MACRO
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Steve Haflich <smh@Franz.COM>, Jon L White <jonl@lucid.com>, Dick Gabriel <RPG@SAIL.Stanford.EDU>,
masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <8907131729.AA06791@defun.utah.edu>
Message-ID: <19890713224024.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 13 Jul 89 11:29:37 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I think
that if you give compilers permission *not* to expand compiler macros
in the first place, implementations are very unlikely to go through
the work of expanding the compiler macro only to throw away the
result.
Not at all. You may have missed this because it was embedded in a
larger discussion, but a compiler might well call a compiler macro,
compare the estimated size and estimated speed of what it returns to those
estimated characteristics of the original form, and choose which one to
compile based on what it was told to optimize.
I'll respond to the rest later.
I guess it's really past time to get this lengthy discussion off the
x3j13 list.
∂13-Jul-89 2013 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Jul 89 20:13:05 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA07901; Thu, 13 Jul 89 10:05:15 PDT
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA00359; Thu, 13 Jul 89 10:02:47 PDT
Received: by clam.sun.com (4.0/SMI-4.0)
id AA07543; Thu, 13 Jul 89 10:02:07 PDT
Date: Thu, 13 Jul 89 10:02:07 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8907131702.AA07543@clam.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu
Subject: Re: issue DEFINE-COMPILER-MACRO
Cc: RPG@SAIL.Stanford.EDU, masinter.pa@xerox.com, x3j13@sail.stanford.edu
> Maybe we need
> another self-selected committee to clean up the remaining problems
> with this issue, like we did for the prettyprinter issue?
>
> That would be okay with me, as long as everyone who seems likely to
> complain about the result is co-opted by being made a member of the
> committee.
If you make a smaller group please keep me on the list of
addressees.
Thanks.
-Cris
∂14-Jul-89 1202 X3J13-mailer minutes? dates?
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 14 Jul 89 12:02:22 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa09757; 14 Jul 89 19:47 BST
Date: Fri, 14 Jul 89 19:45:04 BST
Message-Id: <23090.8907141845@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: minutes? dates?
To: x3j13@sail.stanford.edu
Have the minutes of the Palo Alto meeting been sent out?
If so, I haven't seen them.
Also, when and where is the next meeting?
-- Jeff
∂16-Jul-89 1227 X3J13-mailer minutes? dates?
Received: from arisia (arisia.Xerox.COM) by SAIL.Stanford.EDU with TCP; 16 Jul 89 12:27:47 PDT
Received: from pooh.parc.Xerox.COM by arisia with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA10209; Sun, 16 Jul 89 12:27:55 -0700
Received: by pooh.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA02812; Sun, 16 Jul 89 12:28:01 PDT
Message-Id: <8907161928.AA02812@pooh.parc.xerox.com>
Date: Sun, 16 Jul 89 12:28:01 PDT
From: Larry Masinter <masinter@arisia>
To: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Fri, 14 Jul 89 19:45:04 BST <23090.8907141845@subnode.aiai.ed.ac.uk>
Subject: minutes? dates?
I have Mary's draft minutes from the june meeting on arisia.xerox.com
under clcleanup/jun89.minutes. (Arisia seems to be down at the moment,
however.) The minutes had a couple of errors that I noticed, and there
were some votes that seem to be missing from the file, so I'm hoping
this isn't the final draft of the minutes.
According to the minutes, the next meeting is in November in Palo Alto.
(I wasn't present when this was discussed.)
∂17-Jul-89 0621 X3J13-mailer Re: minutes? dates?
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 17 Jul 89 06:21:39 PDT
Date: 17 Jul 1989 09:22-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: Re: minutes? dates?
From: ROSENKING@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]17-Jul-89 09:22:32.ROSENKING>
In-Reply-To: <8907161928.AA02812@pooh.parc.xerox.com>
Can someone please state if the minutes have been sent out ( I have not seen
them ) and if they are in final format, which means we should ftp them from
arisia. Also an updated future meeting schedule would be handy; I thought the
next meeting was tentatively slated for Sept. 5-7 in Fairfax.
∂17-Jul-89 0709 X3J13-mailer Re: minutes? dates?
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 17 Jul 89 07:09:34 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 626265; 17 Jul 89 10:10:07 EDT
Date: Mon, 17 Jul 89 10:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: minutes? dates?
To: ROSENKING@A.ISI.EDU
cc: X3J13@SAIL.Stanford.EDU
In-Reply-To: <[A.ISI.EDU]17-Jul-89 09:22:32.ROSENKING>
Message-ID: <19890717140949.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
To the best of my knowledge, the minutes are available in draft form only
at this time (by FTP from Arisia). A few people, myself included, are still
actively working on comparing their notes to the draft minutes to make sure
everything is complete, accurate, etc.
Plans for a September meeting were cancelled, in order to allow people
more time to focus on proofreading the draft.
You should wait for official confirmation of this before booking plane
reservations, but my notes say the next meeting is slated for Mon-Wed
November 6-8, 1989 at Xerox PARC in Palo Alto. (There was originally
discussion of having it be Wed-Fri, but it was moved back because Gregor
said only if we had it Mon-Wed could we get the ``big room'' at PARC.)
∂17-Jul-89 1002 X3J13-mailer Re: minutes? dates?
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 17 Jul 89 10:02:10 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa07346; 17 Jul 89 17:14 BST
Date: Mon, 17 Jul 89 17:29:28 BST
Message-Id: <17271.8907171629@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: minutes? dates?
To: Larry Masinter <masinter@arisia>
In-Reply-To: Larry Masinter's message of Sun, 16 Jul 89 12:28:01 PDT
Cc: x3j13@sail.stanford.edu
> I have Mary's draft minutes from the june meeting on arisia.xerox.com
> under clcleanup/jun89.minutes. (Arisia seems to be down at the moment,
> however.) The minutes had a couple of errors that I noticed, and there
> were some votes that seem to be missing from the file, so I'm hoping
> this isn't the final draft of the minutes.
Thanks, but I'm afraid I can't copy from the Internet these days.
Were the minutes mailed to x3j13?
-- Jeff
∂28-Jul-89 1710 X3J13-mailer cs proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 28 Jul 89 17:06:59 PDT
Date: Fri, 28 Jul 89 16:44:32 PDT
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890728.164432.baggins@almvma>
Subject: cs proposal
I've revised the character proposal per the Palo Alto meeting.
At this point, I consider the Character subcommittee's work
completed and thank everyone who has contributed to
this effort.
Regards,
Thom Linden
-----------------------------------------------------------------
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{July 25, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newtheorem{prop}{Proposal}[section]
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
\section{Preface}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from L. Masinter and other members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
This document has undergone several revisions based upon Character
Subcommittee and full X3 J13 Committee meetings.
This final version is annotated with the voting positions
of X3 J13 at the March and June 1989 meetings. The proposals
marked {\em Passed} will be incorporated into the X3 J13 Draft Common
Lisp Standard. Proposals {\em 2.4.4, 2.4.5,} and
{\em 2.5.1} (not passed)
may be viewed as
recommendations to implementations providing extended support
for international character sets. Insufficient implementation
experience and the uncertainty related to the formation of new
ISO Working Groups were the primary reasons these specific proposals
were not incorporated into the Draft at this time.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
To universally identify each character, we utilize a
universal registry of characters which incorporates a
collection of repertoires called {\em character scripts}
as a partitioning of all characters.
That is, each character is included
in one and only one character script.
\footnote{The practical starting point of this registry is the
Draft ISO 10646 Coded Character Set Standard. \cite{iso10646}}
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character script and a character label.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
All other character data objects are classified
as {\em non-graphic} (or {\em control}).
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities. For example, while Common LISP is free to
define unique manipulation facilities for characters, character scripts
and coded character sets, it should
not define standard coded character sets nor standard
character scripts.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
A final purpose is to serve as a basis for terminology within the
standard language specification.
\begin{prop}[Passed 03/89]
The terminology introduced in this proposal will be included
in the language specification at the discretion of the editor.
\end{prop}
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices.
The notion of attributes of character
objects within Common LISP has proven to be either not used or
not portable. The essential aspect of the following proposals is
to what extent attributes continue to be supported by the
language specifications.
\begin{prop}[Alternative A, Passed as Modified 03/89]
Remove all discussion of attributes from
the language specification. Add the following discussion:
\begin{quote}
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects. These and other
supported attributes are considered implementation-defined
attributes and if supported by an implementation effect the
action of selected functions.
\end{quote}
All types, constants and functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified as follows:
\begin{itemize}
\item Modify {\clkwd char-=}: If two characters differ in any
implementation-defined attributes, then they are not {\clkwd char-=}.
\item Modify {\clkwd char-<}: If two characters have identical
implementation-defined attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item Modify {\clkwd char-equal}:
The effect, if any, on {\clkwd char-equal} of each
implementation-defined attribute has to be specified as part of
the definition of that attribute (and similarly for
{\clkwd char-not-equal, char-lessp, char-greaterp,
char-not-greaterp, char-not-lessp}).
\item Modify {\clkwd char-upcase} and {\clkwd char-downcase}:
The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve implementation-defined attributes.
\item Modify {\clkwd read}: It is implementation dependent which
attributes are removed from symbol names.
It is implementation dependent which attributes are removed
from characters within double quotes.
\item Modify {\clkwd intern}: It is implementation dependent
which implementation-defined attributes are removed.
\item Modify {\clkwd digit-char}: remove the optional {\em font}
argument.
\item Modify {\clkwd code-char}: remove the optional {\em font}
and {\em bits} arguments.
\item Remove {\clkwd char-font-limit}
\item Remove {\clkwd char-bits-limit}
\item Remove {\clkwd int-char}
\item Remove {\clkwd char-int}
\item Remove {\clkwd char-bits}
\item Remove {\clkwd char-font}
\item Remove {\clkwd make-char}
\item Remove {\clkwd char-control-bit}
\item Remove {\clkwd char-meta-bit}
\item Remove {\clkwd char-super-bit}
\item Remove {\clkwd char-hyper-bit}
\item Remove {\clkwd char-bit}
\item Remove {\clkwd set-char-bit}
\item Remove {\clkwd string-char} and {\clkwd string-char-p}
\item Modify readtable: If implementation-defined attributes
are supported, an implementation need not (but may) allow
for such characters to have syntax descriptions in the readtable.
Otherwise, all characters are representable in the readtable.
\end{itemize}
\end{prop}
\begin{prop}[Alternative B, Passed as Modified 03/89]
This is identical to all of Alternative A (above) except that
the function {\clkwd char-int} is retained.
{\clkwd char-int} returns a non-negative integer encoding the
character object. The manner in which the integer is computed
is implementation dependent. In contrast to {\clkwd sxhash},
the result is not guaranteed independent of the particular
"incarnation" or "core image".
\end{prop}
With the elimination of {\em font} and {\em bits} from the
specification the usefulness of {\clkwd char-code} and {\clkwd
code-char} is diminished. They are no longer needed for constructing
characters.
The portable mechanisms for hashing are provided by
{\clkwd char-int} and {\clkwd sxhash}.
In addition, using {\clkwd char-code-limit} to iterate over
characters is extremely inefficient in implementations that
support large or user-defined repertoires.
\begin{prop}[Alternative C, Failed 03/89]
This an amendment to Alternative B (above).
\begin{itemize}
\item Remove {\clkwd char-code-limit}
\item Remove {\clkwd char-code}
\item Remove {\clkwd code-char}
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Standard and Semi-Standard Characters}
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional mechanisms,
such as in \cite{kurokawa88}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\begin{prop}[Passed 03/89]
The discussion of standard characters is
replaced by the following:
Common LISP requires all implementations to support
and document a {\em standard}
character subrepertoire.
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic Id categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
Id & Glyph & Name or description
& Id & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\end{prop}
The definition of semi-standard characters has been of minimum
practical use since implementations may or may not support any
of these characters. The essential feature is that, when
supported, they have a predictable treatment by the reader.
\begin{prop}[Failed 03/89]
Remove all discussion of semi-standard characters.
Add that in implementations supporting non-graphic characters other
than \#$\backslash${\clkwd Newline}, the {\clkwd read} function
is required to treat those as
whitespace characters.
\end{prop}
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements need to
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to allow specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarly for the {\clkwd simple-string}
type specifier). This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
\begin{prop}[Passed as Modified 03/89] The following type
definitions are added:
Define {\clkwd base-character} as {\clkwd
(upgraded-array-element-type 'standard-char)} and
{\clkwd extended-character} as type {\clkwd
(and character (not base-character))}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
extended-character)}
are referred to as {\em extended characters}.
\end{prop}
This establishes the relationship between the string encoding and
array upgrading strategies of the implementation and
the important character types.
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
\item
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}
\end{itemize}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, may
be privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However,
the proposal emphasizes that whether a character is "base" to
Common LISP depends on the way that an implementation represents
strings, and not any other properties of the implementation or the
host operating system. Imagine two implementations, one of which
encodes all strings as 16-bit characters, and another which has
two kinds of strings: 8-bit strings and 16-bit strings. In the
first implementation, the {\clkwd base-character} is
{\clkwd character}: there's only one kind of string. In the
second implementation, the {\clkwd base-character} would be those
that could be stored in an 8-bit string, and it would be a proper
sub-type of {\clkwd character}.
\subsection{String Type}
\begin{prop}[Passed 03/89]
The {\clkwd string} type
is defined as
a union type. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of {\clkwd character}.
{\clkwd string} used as a type specifier for object creation
means {\clkwd (vector character)}.
\end{prop}
\begin{prop}[Passed as Modified 03/89]
The following string
subtypes are
distinguished with standardized names.
\begin{itemize}
\item {\clkwd base-string} is equivalent to {\clkwd (vector
base-character)}.
Strings of type {\clkwd base-string} are referred to as {\em base
strings}.
\item {\clkwd base-string} is valid as a type specifier that
abbreviates.
\end{itemize}
\end{prop}
\begin{prop}[Passed as Modified 03/89]
Define {\clkwd simple-string} as a union type.
A simple
string is a specialized simple
one dimensional array whose elements are of type
{\clkwd character} or a subtype of character.
{\clkwd simple-string} used as a type specifier for object creation
means {\clkwd (simple-array character ({\em size}))}.
\end{prop}
\begin{prop}[Passed as Modified 03/89]
The following simple string
subtypes are
distinguished with standardized names:
\begin{itemize}
\item {\clkwd simple-base-string} is equivalent to {\clkwd
(simple-array base-character (*)). simple-base-string} is a subtype
of {\clkwd base-string}.
\item {\clkwd simple-base-string} is
valid as a type specifier that abbreviates.
\end{itemize}
\end{prop}
A base string is the most efficient string which can hold
the standard characters.
All Common LISP functions defined to operate on strings treat
all strings strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coercion to an extended string.}
An implementation may support string subtypes in addition
to {\clkwd base-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic characters
might provide as extended characters:
\begin{itemize}
\item {\clkwd string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd string}.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
\begin{prop}[Passed 03/89]
Extend the {\clkwd make-string} function to allow an
{\clkwd element-type} keyword argument:
\begin{itemize}
\item {\clkwd make-string} {\em size}
{\clkwd \&key :initial-element :element-type} [Function]
This returns a simple string of length {\em size}, each
of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be
initialized in an implementation-dependent way. The
{\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type. If
{\clkwd :element-type} is omitted, the type {\clkwd character}
is the default.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Character Naming}
A Common LISP program should be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of character script is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character script, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
\begin{prop}[Passed 03/89]
Common LISP character codes are composed from a character script and
a character label. The convention by which a character label and
character script compose a character code is implementation
dependent.
\end{prop}
The naming and content of the standard character scripts
is left unspecified by this proposal.
\footnote{The only constraint is that character scripts and
labels be named using only the Latin capital letters A-Z, hyphen and
digits 0-9.}
Below are some candidate character script names:
\begin{itemize}
\item latin
\item extended-latin
\item international-african-alphabet
\item extended-symbols
\item diacritics
\item cyrillic-for-major-languages
\item cyrillic-for-minor-languages
\item greek
\item arabic
\item armenian
\item georgian
\item hebrew
\item hiragana-symbols
\item katakana
\item control (meaning the collection of standard text communication
control codes)
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive.
\footnote{In fact, they are simply 15 of the scripts represented
within
\cite{iso10646}}
The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?). It is application
programs which require a reliable definition of the
script names and their constituents. The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.
\begin{prop}[Passed as Modified 06/89]
An implementation must document the scripts it supports.
For each script supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions. Character labels must be uniquely
named using only Latin capital letters A-Z, hyphen and digits 0-9.
\item Effect of {\clkwd char-upcase} and {\clkwd char-downcase}.
\item Reader canonicalization and format directives.
\footnote{Any mechanisms by which the {\clkwd read} function treats
distinct characters as equivalent.}
\item Effect of character predicates. In particular,
\begin{itemize}
\item {\clkwd char-equal} and other case-insensitive character
predicates.
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
supported are documented.
\end{itemize}
\end{prop}
\begin{prop}[Passed as Modified 06/89]
Every character repertoire name is a type specifier and a subtype of
type character.
\end{prop}
\begin{prop}[Failed 06/89]
The following functions are added to allow application determination
of implementation supported character repertoires.
\begin{itemize}
\item {\clkwd all-character-script-names} {\em [Function]}
The value of {\clkwd all-character-script-names} is a list
of all character script names (symbols) supported by
the implementation. All character scripts are repertiores.
\item {\clkwd all-character-language-names} {\em [Function]}
The value of {\clkwd all-character-language-names} is a list
of all character language names (symbols) supported by
the implementation. All character languages are repertoires.
\footnote{International agreement is also necessary to
establish language repertoires (eg. Canadian-French) and
their respective sorting algorithms, date formats, etc.
\cite{ison622}, \cite{ison623}}
\item {\clkwd char-label} {\em char [Function]}
{\clkwd char-label} returns a string representing the character
label of {\em char}. It is an error if the argument is
not a character object.
\item {\clkwd char-script-name} {\em char [Function]}
{\clkwd char-script-name} returns a string representing the character
script to which {\em char} belongs. It is an error if the
argument is not a character object.
\item {\clkwd find-char} {\em script label [Function]}
{\clkwd find-char} returns a character object. The arguments
{\em script} and {\em label} are names (symbols) of
a character script and label. {\em label} uniquely
identifies a character within the character script named
{\em script}. If the implementation does not support the
specified character, {\clkwd nil} is returned.
\end{itemize}
\end{prop}
\begin{prop}[Withdrawn 06/89]
Character
names accepted and constructed by {\clkwd char-name, name-char}, and
{\clkwd \#$\backslash$} are extended to include character script
names of the form {\em script:label}.
\end{prop}
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
There are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
Given that multiple coded character sets exist, it is useful
to provide portable mechanisms based on their definitions.
\begin{prop}[Failed 06/89]
Add the following functions:
\begin{itemize}
\item {\clkwd all-external-coded-character-set-names} {\em [Function]}
{\clkwd all-external-coded-character-set-names} returns a
list of names (symbols) of all external coded character sets
supported by the implementation.
\item {\clkwd char-external-code} {\em char name [Function]}
{\clkwd char-external-code} returns the non-negative integer
representing the encoding of the character {\em char} in the
coded character set named by {\em name}, a symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain a character of the
specified index,
{\clkwd nil} is returned.
\item {\clkwd external-code-char} {\em name index [Function]}
{\clkwd external-code-char} returns a character object.
The argument {\em index} is a non-negative integer
representing the encoding of a character in the
coded character set named by {\em name}, a symbol. If
the implementation does not support the specified coded
character set, {\clkwd nil} is returned. If the named
coded character set does not contain a character of the
specified index,
{\clkwd nil} is returned.
\end{itemize}
\end{prop}
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
Which coded character sets and encoding schemes
are supported by the overall computing system and the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.
\begin{prop}[Passed as Modified 06/89]
Add an additional keyword argument to {\clkwd open} and
a new function to query external file format:
\begin{itemize}
\item {\clkwd :external-format} keyword argument on {\clkwd open}
which specifies an implementation recognized scheme for
representing characters in files.
The default value is {\clkwd :default} and is
implementation defined but must support the
base characters.
If the argument is not recognized by the implementation,
an error is signaled.
This argument is provided for input, output, and
bidirectional streams.
It is an error to write a character which cannot
be represented using the given file format.
(This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)
\item {\clkwd stream-external-format} {\em stream [Function]}
{\clkwd stream-external-format} returns the implementation
recognized format of the specified file.
\end{itemize}
\end{prop}
The existing default for the {\clkwd :element-type} argument of
{\clkwd open} is {\clkwd string-char}. This is no longer appropriate
given the elimination of {\clkwd string-char} within the
standard specification.
\begin{prop}[Withdrawn 03/89]
Modify the {\clkwd :element-type} argument to {\clkwd open} as follows:
\begin{itemize}
\item Add {\clkwd base-character} as a valid type.
\item Remove {\clkwd string-char} as a valid type.
\end{itemize}
\end{prop}
The following alternative is consistent with the general
premise that portability is emphasized over efficiency.
\begin{prop}[Alternative A, Passed 06/89]
The default for the {\clkwd :element-type} argument of {\clkwd open}
is {\clkwd character}.
\end{prop}
The following alternative (B), allows implementations to match
the behavior of {\clkwd open} to the expected behavior of
their file systems.
\begin{prop}[Alternative B, Withdrawn 06/89]
The default for the {\clkwd :element-type} argument of {\clkwd open}
is implementation defined as a super-type
of {\clkwd base-character}
and a sub-type of {\clkwd character}.
\end{prop}
\begin{prop}[Passed as Modified 06/89]
Modify the following functions:
\begin{itemize}
\item {\clkwd with-output-to-string}. A new keyword argument
{\clkwd :element-type} is added which defaults to {\clkwd character}.
If a string argument is provided, the {\clkwd :element-type}
argument is ignored.
A string argument of {\clkwd nil} means no initial string
argument is provided.
If no string argument is
provided, produces a stream that accepts all characters of the
indicated type and returns
a string of the indicated element type.
\item {\clkwd make-string-output-stream}. A new keyword argument
{\clkwd :element-type} is added which defaults to {\clkwd character}.
{\clkwd make-string-output-stream} returns an output stream that
accepts all characters of the
indicated type and returns
(via {\clkwd get-output-stream-string})
a string of the indicated type.
\end{itemize}
\end{prop}
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
This function is necessary
to determine if strings can be written to fixed length
fields in databases. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
\begin{prop}[Passed as Modified 06/89]
Add the following function:
\begin{itemize}
\item {\clkwd file-string-length}
{\em file-stream object} [Function]
{\clkwd file-string-length} returns a non-negative integer
which represents the difference between what {\clkwd
(file-position {\em file-stream})} would be after writing the object
and its current value, or {\clkwd nil} if this cannot be
determined. {\em object} must be a string or character.
This return value depends on the current state of the stream,
that is, two calls to {\clkwd file-string-length} with the same
stream and object may return different values.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
\section{Miscellaneous}
In the process of creating this document, some comments were found
within CLtL which seem appropriate to modify independently of
the other proposals mentioned previously. For each, we identify
the existing statement of CLtL and the recommended change.
\begin{prop}[Passed 03/89]
Chapter 2 Data Types (Page 12)
\begin{itemize}
\item {\bf replace}
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\item {\bf with}
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\end{itemize}
\end{prop}
\begin{prop}[Passed as Modified 03/89]
Chapter 2 Symbols (Page 25)
\begin{itemize}
\item {\bf clarify}
\cltxt
A symbol may have any character in its print name.
\end{itemize}
\end{prop}
\begin{prop}[Passed 03/89]
Chapter 10 Symbols (Page 163)
\begin{itemize}
\item {\bf replace}
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\item {\bf with}
\cltxt
It is an error to alter a symbol's print name.
\end{itemize}
\end{prop}
\begin{prop}[Passed 03/89]
Chapter 10 The Print Name (Page 168)
\begin{itemize}
\item {\bf replace}
\cltxt
It is an extremely bad idea to modify a string being used
as the print name of a symbol.
\item {\bf with}
\cltxt
It is an error to modify a string being used
as the print name of a symbol.
\end{itemize}
\end{prop}
\begin{prop}[Passed 03/89]
Chapter 14 Simple Sequence Functions (Page 249, make-sequence)
\begin{itemize}
\item{\bf append}
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\end{itemize}
\end{prop}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO DP 10646]{iso10646} ISO,
{\em
Draft Proposal Information processing -- Multiple octet coded
character set
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[ISO N622R]{ison622} ISO,
{\em
Requirements for Characters in Programming Languages
},
Joint meeting of ISO SC2, SC22, SC21/WG3, Geneva 26-28 (1989).
\bibitem[ISO N623R]{ison623} ISO,
{\em
Requirements for Character Handling in Progamming Languages
},
Joint meeting of ISO SC2, SC22, SC21/WG3, Geneva 26-28 (1989).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂07-Aug-89 0925 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Aug 89 09:25:43 PDT
Received: from MERLIN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 246218; Mon 7-Aug-89 12:26:33 EDT
Date: Mon, 7 Aug 89 12:26 EDT
From: Richard C. Waters <dick@AI.MIT.EDU>
Subject: support for PRETTY-PRINT-INTERFACE:XP version 5
To: x3j13@sail.stanford.edu
Message-ID: <19890807162625.3.DICK@MERLIN.AI.MIT.EDU>
On June 27 it was voted 12 to 4 in a plenary session of X3J13 that
an add hoc subcommittee on pretty printing be created with the charter
of ironing out the final details of the pretty print interface and
that if this committee could come to a unanimous decision on the
interface, the interface would become part of the draft Common Lisp
standard without the need of a further vote by the full committee.
As of this day, the add hoc committee has come to a unanimous
decision on the interface (described in two separate messages). With
this message, I signify that I support PRETTY-PRINT-INTERFACE:XP
version 5. Each of the other subcommittee members (Steve Haflich,
Joachim laubsch, Sandra Loosemore, Dan Pierson, and Walter van
Roggen) will be sending a similar message.
To the members of the editorial committee, I would like to
volunteer to do anything they would consider helpful with regard to
the pretty printer. I certainly volunteer to read drafts of
everything they produce. Beyond that, given examples of the style
they want, I volunteer to produce a first draft of the pretty
printer part of the report if they would like me to. I probably
could not do that until October, but I could do it then.
Dick Waters.
∂07-Aug-89 1000 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 7 Aug 89 10:00:46 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA02635; Mon, 7 Aug 89 13:04:20 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA17100; Mon, 7 Aug 89 12:59:25 EDT
Message-Id: <8908071659.AA17100@mist.>
To: x3j13@sail.stanford.edu
Subject: support for PRETTY-PRINT-INTERFACE:XP version 5
Date: Mon, 07 Aug 89 12:59:23 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
I support PRETTY-PRINT-INTEFACE:XP version 5
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com
∂07-Aug-89 1218 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 7 Aug 89 12:18:37 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA20642; Mon, 7 Aug 89 15:19:14 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA02163; Mon, 7 Aug 89 12:14:30 PDT
Received: by feast (5.5/3.14)
id AA00378; Mon, 7 Aug 89 14:52:59 EDT
Date: Mon, 7 Aug 89 14:52:59 EDT
From: smh@Franz.COM (Steven M. Haflich)
Message-Id: <8908071852.AA00378@feast>
To: sail.stanford.edu!x3j13@Franz.COM
In-Reply-To: Richard C. Waters's message of Mon, 7 Aug 89 12:26 EDT <19890807162625.3.DICK@MERLIN.AI.MIT.EDU>
Subject: support for PRETTY-PRINT-INTERFACE:XP version 5
A yes vote from me too.
I also want to thank Dick for all the conscientious hard work he has
put into this proposal, not to mention the implementation.
∂07-Aug-89 1253 X3J13-mailer Re: support for PRETTY-PRINT-INTERFACE:XP version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89 12:53:46 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.2-cs)
id AA03712; Mon, 7 Aug 89 13:54:25 -0600
Received: by defun.utah.edu (5.61/utah-2.2-leaf)
id AA03437; Mon, 7 Aug 89 13:54:23 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8908071954.AA03437@defun.utah.edu>
Date: Mon, 7 Aug 89 13:54:21 MDT
Subject: Re: support for PRETTY-PRINT-INTERFACE:XP version 5
To: x3j13@sail.stanford.edu
In-Reply-To: Richard C. Waters <dick@AI.MIT.EDU>, Mon, 7 Aug 89 12:26 EDT
I support PRETTY-PRINT-INTERFACE:XP.
-Sandra
-------
∂07-Aug-89 1358 X3J13-mailer Support for PRETTY-PRINT-INTERFACE:XP version 5
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 7 Aug 89 13:58:01 PDT
Received: from hpljl.HPL.HP.COM (hpljl.hpl.hp.com) by hplms2.hp.com; Mon, 7 Aug 89 13:58:29 pdt
Received: by hpljl.HPL.HP.COM; Mon, 7 Aug 89 13:58:17 pdt
Date: Mon, 7 Aug 89 13:58:17 pdt
From: Joachim Laubsch <laubsch%hpljl@hplabs.hp.com>
Full-Name: Joachim Laubsch
Message-Id: <8908072058.AA04631@hpljl.HPL.HP.COM>
To: x3j13@sail.stanford.edu
Subject: Support for PRETTY-PRINT-INTERFACE:XP version 5
I support PRETTY-PRINT-INTEFACE:XP version 5.
Also, I would like to thank Dick Waters for his constructive work.
-*- Joachim (email: laubsch@hplabs.hp.com tel: 415-857-7695).
∂08-Aug-89 0016 X3J13-mailer Re: support for PRETTY-PRINT-INTERFACE:XP version 5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Aug 89 00:16:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02301; Tue, 8 Aug 89 00:16:43 PDT
Message-Id: <8908080716.AA02301@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02301; Tue, 8 Aug 89 00:16:43 PDT
From: vanroggen@aitg.enet.dec.com
Date: 7 Aug 89 21:14
To: x3j13@sail.stanford.edu
Subject: Re: support for PRETTY-PRINT-INTERFACE:XP version 5
Although I haven't read the very latest version, I believe it to be
in good shape, and am willing to support it.
---Walter
∂08-Aug-89 2110 X3J13-mailer ANSI ANTICS REVISITED
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 8 Aug 89 21:10:18 PDT
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Wed, 9 Aug 89 00:11:40 EDT
Received: by kulla.think.com; Wed, 9 Aug 89 00:10:25 EDT
Date: Wed, 9 Aug 89 00:10:25 EDT
From: barmar@Think.COM
Message-Id: <8908090410.AA25509@kulla.think.com>
To: x3j13@sail.stanford.edu
Subject: ANSI ANTICS REVISITED
I saw the following in comp.lang.c. Anyone care to write an X3J13
version (my guess is that Gabriel is to X3J13 as Plauger is to X3J11,
so perhaps he should be nominated).
"A Modest Proposal for Encoding Debate"
(C) Copyright 1986 P.J. Plauger - All Rights Reserved
We have had enough experience with the deliberations of X3J11
that I feel we can now introduce a number of abbreviations in place
of frequently used arguments. An interesting discovery I made
in the process of summarizing these popular arguments is that, like
elementary particles, each is accompanied by its anti-argument,
[which] has as much claim to being fundamental as its anti-anti.
An equally interesting discovery is that certain members of the
Committee are adept at using both sides of a complementary pair,
depending upon which flavor supports the desired outcome
of a given issue ...
1+ It's in the base document.
1- It's a flaw in the base document that must be corrected.
2+ It's not in the base document.
2- It's an oversight in the base document that must be corrected.
3+ Dennis Ritchie agrees with me.
3- Dennis Ritchie's opinion is irrelevant now.
4+ UNIX does it that way. 4- How UNIX does it is irrelevant now.
5+ AT&T isn't going to like this. 5- Who cares what AT&T thinks?
6+ Whitesmiths had [sic] done it that way for years.
6- What's a whitesmith?
7+ Most of the C compilers sold are under UNIX.
7- Most of the C compilers used are not under UNIX.
8+ These are the facts upon which I base my opinions.
8- These are the opinions on which I base my facts.
9+ I like it; it must be good. 9- I don't like it; it must be bad.
10+ It will break working code. 10- The working code shouldn't have
been written that way in the first place.
11+ It's an important addition to the language.
11- It's a major perturbation to an otherwise stable document.
12+ It only affects a small area.
12- It's a needless tweak to an otherwise stable document.
13+ It will affect a large fraction of existing code, in my opinion.
13- It will affect a small fraction of existing code, in my opinion.
14+ Current practice is right; the base document is wrong.
14- Current practice is wrong; the base document is right.
15+ Current practice is mixed in this area. 15- There is one
obvious right way to do it, regardless of current practice.
16+ Zero should behave just like any other number.
16- Zero is a special case, different from any number.
17+ We should stay out of the way of sophisticated programmers.
17- We should protect innocent programmers.
18+ C is a quick and dirty language; that's its heritage.
18- C must become a safe language; that's its future.
19+ That's impossible to implement. 19- Anything can be implemented.
20+ That's inefficient. 20- Efficiency is not a consideration.
21+ That's impossible to understand.
21- Anything confusing can be hidden inside a macro.
22+ If my system can't handle it directly,
it shouldn't be in the Standard.
22- If you can lie to your system somehow, it belongs in the Standard.
23+ The user community will laugh us out of town on this one.
23- The user community must be educated on this one.
24+ That's gone unchallenged for two years. Why bring it up now?
24- That's been broken for two years. It's high time we addressed it.
25+ Ada does it that way. 25- Ada does it that way.
Respectfully submitted in partial fulfillment, P.J. Plauger
∂11-Aug-89 1025 X3J13-mailer support for PRETTY-PRINT-INTERFACE:XP version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Aug 89 10:25:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 640340; 11 Aug 89 13:26:55 EDT
Date: Fri, 11 Aug 89 13:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: support for PRETTY-PRINT-INTERFACE:XP version 5
To: Richard C. Waters <dick@AI.MIT.EDU>
cc: x3j13@sail.stanford.edu
In-Reply-To: <19890807162625.3.DICK@MERLIN.AI.MIT.EDU>
Message-ID: <19890811172725.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 7 Aug 89 12:26 EDT
From: Richard C. Waters <dick@AI.MIT.EDU>
As of this day, the add hoc committee has come to a unanimous
decision on the interface (described in two separate messages).
Those two messages have not yet arrived here. Have they not been
sent yet, or did they get lost in the network?
∂14-Aug-89 0714 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89 07:14:04 PDT
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA02466; Mon, 14 Aug 89 10:14:36 EDT
From: dick@ai.mit.edu (Richard C. Waters)
Received: by rice-chex (4.0/AI-4.10) id AA13747; Mon, 14 Aug 89 10:14:19 EDT
Date: Mon, 14 Aug 89 10:14:19 EDT
Message-Id: <8908141414.AA13747@rice-chex>
To: x3j13@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE:XP version 5
The following is being recent, because it apparently did not get through.
THE ISSUE DESCRIBED HERE IS TOO LARGE TO FIT IN A SINGLE MESSAGE. AS A
RESULT, IT IS DIVIDED INTO TWO PARTS SENT IN TWO MESSAGES. THIS IS PART
ONE, WHICH IS IN THE STANDARD CLEANUP ISSUE FORMAT AND CONTAINS COMMENTARY
ON THE PROPOSAL. THE FULL DETAILED PROPOSAL ITSELF IS IN PART TWO.
--------------------
Version 3 (by Guy Steele Jr) supersedes version 2 and is changed from
version 1 as follows: adds a functional interface to supplement the
interface through FORMAT, and reflects comments by Barrett and
Pierson.
Version 4 (by Dick Waters) is changed from version 3 as follows: The
short summary is updated to reflect the functional interface. The
functional interface is changed following suggestions made by Dave Moon.
The proposal is amended in a few minor ways to increase the
compatibility with variable width fonts. Additional discussion has been
added with regard to the advantages of XP with respect to handling
detection and abbreviation, the interaction with CLOS, and
the extended type specifier CONS used by XP.
Version 5 (by Waters, Haflich, Laubsch, Loosemore, Pierson, and van Roggen).
On June 27 it was voted 12 to 4 in a plenary session of X3J13 that an add
hoc committee on pretty printing be created containing the above members
with the charter of ironing out the final details of the pretty print
interface and that if this committee could come to a unanimous decision on
the interface, the interface would become part of the draft Common Lisp
standard without the need of a further vote by the full committee. The
unanimity of the add hoc committee has been signaled by having each member
of the committee send a message to X3J13 to this effect.
In addition to the main vote above, five straw polls were taken. Three
of these votes were overwhelming; however, two appeared too close to be
definitive. In order of the clarity of the outcome the straw votes were:
16-0 in favor of the basic functional interface,
10-4 against the inclusion of #"...",
12-7 in favor of having some way to convert a FORMAT string into a function,
11-8 in favor of allowing FORMAT to take a function as well as a string,
10-8 against the pretty printer extensions of FORMAT.
The subcommittee followed these recommendations except for the last.
(See the end of the discussion section.)
Version 5 is changed from version 4 as follows: The names of the
functions and variables have been changed to better reflect that (for the
most part) they are a group that applies only to pretty printing. The
variables *DEFAULT-RIGHT-MARGIN* and *LAST-ABBREVIATED-PRINTING* have been
eliminated. The readmacro construct #"..." has been eliminated and a new
macro FORMATTER introduced in its place. The way *PRINT-LINES*
abbreviation is indicated has been improved to ensure that the delimiters
will be balanced in the output and to ensure that the reader will complain
if you later try to read the output. The macros LOGICAL-BLOCK-POP and
LOGICAL-BLOCK-COUNT have been eliminated and the functionality they
supported provided in a slightly different form by two new macros
PPRINT-POP and PPRINT-EXIT-IF-LIST-EXHAUSTED. The macro
DEFINE-PRINT-DISPATCH has been replaced by a function SET-PPRINT-DISPATCH.
The proposal has been reorganized to show that the functional interface is
more fundamental than the FORMAT interface, to clarify exactly what happens
in error situations, and to indicate that the examples are merely examples
and not part of the proposal.
Issue: PRETTY-PRINT-INTERFACE
References: Description of XP by Dick Waters (attached)
*PRINT-PRETTY* (CLtL p. 371)
WRITE (CLtL p. 382)
PPRINT (CLtL p. 383)
FORMAT (CLtL pp. 385-407)
FORMAT ~T directive (CLtL pp. 398-399)
FORMAT ~< directive (CLtL pp. 404-406)
Related issues:
Category: CLARIFICATION CHANGE ADDITION
Edit history: Version 1, 24-Feb-89 by Steele
Version 2, 15-Mar-89 by Steele and Waters
Version 3, 15-Mar-89 by Steele
Version 4, 22-Mar-89 by Waters
Version 5, 20-Jul-89 by Waters et al
Problem description:
At present, Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it. In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.
Proposal (PRETTY-PRINT-INTERFACE:XP):
Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached document. Here is a very brief summary
of the proposal.
New variables: *PRINT-PPRINT-DISPATCH*
*PRINT-MISER-WIDTH*
*PRINT-RIGHT-MARGIN*
*PRINT-LINES*
New functions: COPY-PPRINT-DISPATCH
SET-PPRINT-DISPATCH
PPRINT-DISPATCH
PPRINT-NEWLINE
PPRINT-TAB
PPRINT-INDENT
PPRINT-FILL
PPRINT-LINEAR
PPRINT-TABULAR
New macros: PPRINT-LOGICAL-BLOCK
PPRINT-POP
FORMATTER
New FORMAT directives: ~W ~_ ~I ~:T ~/name/ ~<...~:>
The function WRITE is extended to accept four additional keyword arguments
:PPRINT-DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to
the four new variables.
The function FORMAT is extended so that it can accept a function instead of
a FORMAT string. (This change is also made in the other functions that
accept FORMAT strings such as ERROR and WARN.)
Examples: See attached document.
Rationale:
There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.
Current practice:
XP son of PP son of GPRINT son of #PRINT is the latest in a line of pretty
printers that goes back 13 years. All of these printers use essentially
the same basic algorithm and conceptual interface. Further, except for
#PRINT, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use. XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months. PP
has been the pretty printer in DEC Common Lisp for the past 3 years. Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp. In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)
Cost to Implementors: A fair amount of effort (several man-weeks at most).
Source code for XP is available to all comers from Dick Waters. It has
been arranged with MIT for anyone who wants to to get a non-exclusive
royalty-free license for XP from MIT. The system is documented in great
detail in:
Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102a,
Massachusetts Institute of Technology, Cambridge MA, July 1989.
Cost to Users: None (I think). This is an upward-compatible extension.
Cost of non-adoption: Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.
Performance impact: XP is claimed to be quite fast.
Benefits: User control of pretty-printing in a portable manner.
Aesthetics:
Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>. However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT. Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have a
directive that looks like matching brackets of some sort.
Dan Pierson comments: You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).
Discussion:
Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem. If so, another suggestion for naming
this directive would be appreciated.
The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal. However, it should be noted that the proposal for
~/.../ here is simpler than, and incompatible with, the current Zatalisp
practice.
Guy Steele and Dick Waters strongly support this proposal. (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)
---
Dan Pierson comments: You can add me to the list of strong supporters of
this proposal. While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments.
The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed. This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space.
The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right. The current proposal just
mentions them as a minor feature of XP.
At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level. STREAM-INFO
permitted people to use XP, but not to count on it. This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in. [End of comments by Pierson]
---
It has been noted by Guy Steele that some places in the initial document
where it says that circularity detection is handled correctly, this is
true a fortiori following the decision on PRINT-CIRCLE-STRUCTURE.
However, Waters notes that the vote on PRINT-CIRCLE-STRUCTURE said
nothing about the handling of *PRINT-LEVEL*. Therefore, the fact that
XP handles *PRINT-LEVEL* correctly is an improvement.
In addition, PRINT-CIRCLE-STRUCTURE is also silent on what is supposed
to happen if a user program decomposes a list itself (e.g., with DOLIST
or ~{~}) rather than calling a print function. Assumedly *PRINT-CIRCLE*
etc. is not handled in this case. In contrast, if one uses
PPRINT-LOGICAL-BLOCK or ~<~:>, then *PRINT-CIRCLE*, *PRINT-LEVEL*, and
*PRINT-LENGTH* are all automatically handled correctly.
For example, (format nil "-~1{~A ~A ~A ~A ~A ~}-" '#1=(1 #1# 2 . #1#))
produces "-1 #1=(1 #1# 2 . #1#) 2 1 #1=(1 #1# 2 . #1#) -"
even under PRINT-CIRCLE-STRUCTURE and
(format nil "-~1{~A ~}-" '#1=(1 #1# 2 . #1#))
causes infinite looping. However, in XP,
(format nil "-~:<~W ~W ~W ~W ~W~:>-" '#1=(1 #1# 2 . #1#))
produces "-#1=(1 #1# 2 . #1#)-".
This proves to be very useful when writing pretty printing functions for
things. Note also that ~<~:> supports *PRINT-LEVEL* and *PRINT-LENGTH*
correctly. All the same things can be said about the functional interface
and using PPRINT-LOGICAL-BLOCK rather than traversing a list yourself in
some fashion.
All in all, Waters claims that PRINT-CIRCLE-STRUCTURE covers at most 1/4
of what XP does in support of *PRINT-CIRCLE* and does not cover anything
of what XP does to support *PRINT-LEVEL*, *PRINT-LENGTH*, and
robustness in the face of malformed arguments. These are vital
features for writing printing functions that really work right all the time.
---
It has been suggested that objects should be looked up in pprint dispatch
tables by looking for the most specific type specifier that applies, rather
than looking for the highest priority type specifier that applies. There
are two problems with this. First, it is possible for two type specifiers
to apply without one being more specific than the other. For example,
consider the type specifiers (OR INTEGER FLOAT) and (OR INTEGER RATIONAL)
or the type specifiers (NOT COMPLEX) and (NOT INTEGER).
A much more serious problem is that the only way to tell whether one type
specifier is more specific than another is to use SUBTYPEP. Unfortunately,
even with the clarifications and extensions introduced by X3J13 with regard
to SUBTYPEP in particular and the type system in general, SUBTYPEP is not
very dependable. There are critical situations where it cannot reasonably
work in any implementation (e.g., when a type specifier contains SATISFIES)
and many other situations where it can vary from one implementation to
another. Unfortunately, pprint dispatch tables are expected to contain
type specifiers containing SATISFIES on a regular basis. In addition, the
variability in SUBTYPEP would reduce the portability of user-defined pprint
dispatch tables if dispatching through them depended on SUBTYPEP. All in
all, it seems much better for the pretty printing to rely on priorities
rather than on SUBTYPEP
---
It has been noted by Dave Moon that things would be much more elegant if
SET-PPRINT-DISPATCH could be expressed directly as a CLOS DEFMETHOD for
an appropriate generic function. Dick Waters agrees with this. However,
SET-PPRINT-DISPATCH depends on type specifiers that are more complex than
the ones CLOS deals with and ones that do not have clear subtype/supertype
relationships, compensating for the latter problem by supporting numerical
priorities to disambiguate things. (The defaulting behavior is a key
feature of the pretty printer.) At the very least, this means that
SET-PPRINT-DISPATCH will not fit into CLOS in a simple way.
Given the problems, Moon suggests that "it does seem that right now it
might be best to keep a separate SET-PPRINT-DISPATCH macro, with the
idea that the expansion is implementation-dependent at the moment, but
might some day be changed to be defined to expand into DEFMETHOD. I
haven't looked to see whether any syntactic changes would be appropriate
to make that transition smoother."
(Waters also worries that the overhead needed to locate the right CLOS
method would seriously degrade the pretty printer, because the printer
has to do this for every part of every object printed. This dispatching is
currently done by very fast code that is tuned to take advantage of the
observed distribution of kinds of objects that have special pretty
printers attached to them. Even with this special purpose code,
dispatching takes a significant part of the pretty printer's time.)
---
Dave Moon also comments that it is not good to have something that looks
like a type specifier (i.e., the extended form of the CONS type specifier
used by SET-PPRINT-DISPATCH) and yet is not a real type specifier. He
suggests that we should either amend Common Lisp to accept the extended
form of the CONS type specifier, or stop having SET-PPRINT-DISPATCH use it.
Many of the members of the ad hoc pretty printing subcommittee agree that
(CONS car-type cdr-type) should be made a full fledged type specifier. In
fact it has been suggested that there should be a much wider variety of
ways to talk about lists and their contents than currently exists.
However, the subcommittee feels that it would be going significantly beyond
our charter to change anything about the type system.
Therefore, we opted for the opposite tack of making it very clear in this
proposal that while the function SET-PPRINT-DISPATCH accepts the form
(CONS car-type cdr-type), this form is not a type specifier.
---
To a considerable extent, the design of the XP interface is completely
neutral about the issue of variable- versus fixed- width fonts. In
particular, most of the discussion of how the formating proceeds either
talks about absolute positions of zero or talks about something being
in the same horizontal position as something else. These statements are
all font-independent. (Further, although Waters' current implementation
does not support variable-width fonts, the algorithms used could be
extended to support them without radical changes.)
Nevertheless, there are 8 places where users specify explicit non-zero
lengths: the variables *PRINT-RIGHT-MARGIN* and *PRINT-MISER-WIDTH*,
the numeric arguments to ~T, ~I, and ~/pprint-tabular/ and their associated
functions PPRINT-TAB, PPRINT-INDENT, and PPRINT-TABULAR.
It is proposed that all of these lengths be in the same units, and that
this unit be ems (the length of an "m" in the font currently being used
to output characters to the relevant output stream at the moment that
the command is encountered or a variable is consulted).
It is further proposed that users and implementors be advised to set things
up so that explicit lengths do not have to be specified. For implementors,
this means making streams smart enough that they know how wide they are.
(This avoids the use of *PRINT-RIGHT-MARGIN*.) For users, this means
relying on streams knowing their own widths (which is a good idea for
adaptability in any case) and using ~:I (instead of just ~I) to specify
indentations wherever possible. Further, it should be noted that since
*PRINT-MISER-WIDTH* is essentially heuristic in nature, it does not
matter if its value is only an approximate length and users will only need
to change the value of *PRINT-MISER-WIDTH* in unusual situations.
This leaves only tabbing as an area where explicit lengths have to be
specified on a regular basis. Fortunately, approximate lengths are often
acceptable in this situation as well.
---
The currently proposed syntax for PPRINT-LOGICAL-BLOCK was suggested by
Dave Moon based on his experience with similar constructs at Symbolics.
Waters had originally suggested using a standard binding pair to specify
the underlying stream separately from the variable used to hold the special
stream used within the logical block. However, this invites user mistakes.
The problem is that peculiar results will be obtained if any I/O is sent
directly to the underlying stream from within the logical block. By
arranging the syntax as proposed, the same variable is always used for the
special stream within the logical block as is used for the underlying
stream outside of the block. As a result, it is syntactically impossible
to directly access the underlying stream (unless it is stored in two
different variables) and the user is painlessly saved from making mistakes.
Also, the PPRINT-LOGICAL-BLOCK macro is rendered more compact.
---
Another interesting issue is the interaction between pretty-printing and
*PRINT-READABLY*. Note first, that WITH-STANDARD-IO-SYNTAX binds
*PRINT-PRETTY* to NIL. In general one should expect that maximum machine
readability will be achieved when *PRINT-PRETTY* is nil. However, in
analogy with issue DATA-IO, it is reasonable to require that
PPRINT-DISPATCH functions must obey *PRINT-READABLY*. Note that XP
supports a number of features (e.g., automatic handling of malformed lists)
that are explicitly designed to make it easier to write pprint functions
that reliably produce machine readable output.
---
Steve Haflich comments that the macro FORMATTER provides an opportunity at
some later time to do something about making FORMAT control strings more
readable. Specifically, when using FORMATTER, one should not hesitate to
insert lots of newlines, because they will not waste any space since the
FORMAT string will be converted into a function in any case. Second, it
would be nice to add some feature to format strings that would allow
comments to appear in a FORMAT string. (This is what ~; probably should
have been reserved to mean.)
---
Walter van Roggen notes that the automatic handling of *PRINT-LEVEL* by XP
obsoletes the need for the third argument to print functions for
structures. (This argument was very seldom used in any case.) It might be
appropriate at some future time to get rid of the third argument to print
functions for structures. However, this would not be an upward compatible
change.
---
The pretty printer control interface is included in this proposal for two
key reasons:
(A) Something like the following is probably a key part of the argument
against the pretty-printer-control FORMAT interface in the minds of those
that oppose it. "Including the pretty-printer-control FORMAT interface
might be a gain or a loss for Common Lisp, but nothing could possibly be
lost by not including it. You can always just use FORMAT as it is now, and
you can get pretty printing control with the new functions." However, this
argument is not quite true.
As can be seen in the example below, pretty printer control information has
to be highly intertwined with the rest of the output functions. As a
practical matter, this means that if there is no pretty-printer-control
FORMAT interface you cannot make much if any use of FORMAT when specifying
output that contains pretty-printer-control information. (For instance in
the 20 line example below, there is not even one place where there are two
printing operations in a row that could be combined into a call on FORMAT
if there were no pretty-printer-control FORMAT interface. This means that
there would be no benefit to using FORMAT anywhere in this example.)
The consequence of the above is that, even though pretty printer control
and FORMAT inherently have nothing to do with each other, adding pretty
printer control facilities without adding a pretty-printer-control FORMAT
interface, effectively requires people to choose between FORMAT and pretty
printer control. In order to allow people to separately decide whether
they do or do not want to user FORMAT and do or do not want to get involved
with controlling the pretty printer, you have to provide a
pretty-printer-control FORMAT interface.
This issue is intensified given a pretty printer such as XP that is
within epsilon of just as fast as the ordinary non-pretty printer,
because many people choose to set *PRINT-PRETTY* to T all of the time.
They are therefore naturally led to wanting to specify at least some
pretty printing control information whenever defining a print function
for a structure, or an error message, or in fact essentially any kind
of output. If there is no pretty-printer-control FORMAT interface,
then this would effectively bar the use of FORMAT for these users.
In summary, rather than pushing FORMAT into new territory, the
pretty-printer-control FORMAT interface is required to prevent FORMAT from
sliding into obsolescence.
(B) Although it probably is not convincing to those that do not like
FORMAT, a additional reason for having a pretty-printer-control FORMAT
interface is exactly the same as the reason for having FORMAT at all:
compactness. For example, as shown in the main proposal, the format string:
"~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~1I~@{~↑ ~_~W~}~:>"
is the same as the expression:
(pprint-logical-block (nil list :prefix "(" :suffix ")")
(write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :fill)))
(pprint-indent :block 1)
(loop (pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)
(write (pprint-pop)))))
It is of course also true that a line of FORMAT control string is a
lot harder to read than a line of Lisp code. However, FORMAT has
become a permanent fixture of Common Lisp, because a line of FORMAT
control string is a lot easier to read and work with than 20 lines of
Lisp code.
(C) It should also be noted that the way the XP proposal was first written
up made the FORMAT interface look a lot more complex than it is. Only six
things are being added. Two of these just fix problems with FORMAT and do
not have anything to do with pretty printing. Of the remaining four, three
are very simple. Only ~<...~:> could be called complex.
~A and ~S both force the value of *PRINT-ESCAPE*. ~W is needed in
order to write FORMAT strings that obey *PRINT-ESCAPE*.
~/.../ restores (in a simplified form) a feature of FORMAT that was
lost in the first version of Common Lisp. A number of people have
commented that this is something that they like, having nothing to do
with pretty printing. (Note that ~/PPRINT-LINEAR/, ~/PPRINT-FILL/,
and ~/PPRINT-TABULAR/ are not new directives, they are just a
consequence of the fact that ~/.../ can call the functions
PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR.)
[end of part one of PRETTY-PRINT-INTERFACE:XP]
∂14-Aug-89 0717 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89 07:16:17 PDT
Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA02503; Mon, 14 Aug 89 10:16:15 EDT
From: dick@ai.mit.edu (Richard C. Waters)
Received: by rice-chex (4.0/AI-4.10) id AA13769; Mon, 14 Aug 89 10:16:05 EDT
Date: Mon, 14 Aug 89 10:16:05 EDT
Message-Id: <8908141416.AA13769@rice-chex>
To: x3j13@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE:XP version 5
The following is being recent, because it apparently did not get through.
THE ISSUE DESCRIBED HERE IS TOO LARGE TO FIT IN A SINGLE MESSAGE. AS A
RESULT, IT IS DIVIDED INTO TWO PARTS, SENT IN TWO MESSAGES. THIS IS PART
TWO, WHICH IS THE FULL DETAILED PROPOSAL ITSELF. THE STANDARD
CLEANUP-ISSUE-STYLE DESCRIPTION IS IN PART 1 AND CONTAINS SIGNIFICANT
AMOUNTS OF ADDITIONAL COMMENTARY.
--------------------
Proposal (PRETTY-PRINT-INTERFACE:XP):
Full description of XP accompanying version 5 of the proposal
--------------------
Pretty Printing
Richard C. Waters
Pretty printing has traditionally been a black box process, displaying
program code using a set of fixed layout rules. Its utility can be greatly
enhanced by opening it up to user control.
By providing direct access to the mechanisms within the pretty printer that
make dynamic decisions about layout, the macros and functions
PPRINT-LOGICAL-BLOCK, PPRINT-NEWLINE, and PPRINT-INDENT make it possible to
specify pretty printing layout rules as a part of any function that
produces output. They also make it very easy for the detection of
circularity and sharing, and abbreviation based on length and nesting depth
to be supported by the function. The function SET-PPRINT-DISPATCH makes it
possible to associate a user-defined pretty printing function with any type
of object. Together, these facilities enable users to redefine the way
code is displayed and allow the full power of pretty printing to be applied
to complex combinations of data structures.
Pretty Printing Control Variables
*PRINT-RIGHT-MARGIN* [variable]
A primary goal of pretty printing is to keep the output between a pair of
margins. The left margin is set at the column where the output begins. If
this cannot be determined, the left margin is set to zero.
When *PRINT-RIGHT-MARGIN* is not NIL, it specifies the right margin to use
when making layout decisions. When *PRINT-RIGHT-MARGIN* is NIL (the
initial value), the right margin is set at the maximum line length that can
be displayed by the output stream without wraparound or truncation. If
this cannot be determined, the right margin is set to an implementation
dependent value.
To allow for the possibility of variable-width fonts, *PRINT-RIGHT-MARGIN*
is interpreted in terms of ems---the length of an "m" in the font being
used to display characters on the relevant output stream at the moment when
the variables are consulted.
*PRINT-MISER-WIDTH* [variable]
If *PRINT-MISER-WIDTH* is not NIL, the pretty printer switches to a compact
style of output (called miser style) whenever the width available for
printing a substructure is less than or equal to *PRINT-MISER-WIDTH* ems.
The initial value of *PRINT-MISER-WIDTH* is implementation-dependent.
*PRINT-LINES* [variable]
When given a value other than its initial value of NIL, *PRINT-LINES*
limits the number of output lines produced when something is pretty
printed. If an attempt is made to go beyond *PRINT-LINES* lines, "
.." is printed at the end of the last line followed by all of the
suffixes (closing delimiters) that are pending to be printed.
(let ((*print-right-margin* 25) (*print-lines* 3))
(pprint '(progn (setq a 1 b 2 c 3 d 4))))
(PROGN (SETQ A 1
B 2
C 3 ..))
(The symbol ".." is printed out to ensure that a reader error will occur
if the output is later read. A symbol different than "..." is used to
indicate that a different kind of abbreviation has occurred.)
*PRINT-PPRINT-DISPATCH* [variable]
When *PRINT-PRETTY* is not NIL, printing is controlled by the `pprint
dispatch table' stored in the variable *PRINT-PPRINT-DISPATCH*. The
initial value of *PRINT-PPRINT-DISPATCH* is implementation dependent and
causes traditional pretty printing of Lisp code. The last section of this
proposal explains how the contents of this table can be changed.
The function WRITE accepts keyword arguments :PPRINT-DISPATCH,
:RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to
*PRINT-PPRINT-DISPATCH*, *PRINT-RIGHT-MARGIN*, *PRINT-LINES*, and
*PRINT-MISER-WIDTH*.
Dynamic Control of the Arrangement of Output
The following functions and macros support precise control of what should
be done when a piece of output is too large to fit in the space available.
Three concepts underlie the way these operations work---`logical blocks',
`conditional newlines', and `sections'. Before proceeding further, it is
important to define these terms.
The first line of Figure 1 shows a schematic piece of output. The
characters in the output are represented by "-"s. The positions of
conditional newlines are indicated by digits. The beginnings and ends of
logical blocks are indicated by "<" and ">" respectively.
The output as a whole is a logical block and the outermost section. This
section is indicated by the 0's on the second line of Figure 1. Logical
blocks nested within the output are specified by the macro
PPRINT-LOGICAL-BLOCK. Conditional newline positions are specified by calls
on PPRINT-NEWLINE. Each conditional newline defines two sections (one
before it and one after it) and is associated with a third (the section
immediately containing it).
The section after a conditional newline consists of: all the output up to,
but not including, (a) the next conditional newline immediately contained
in the same logical block; or if (a) is not applicable, (b) the next
newline that is at a lesser level of nesting in logical blocks; or if (b)
is not applicable, (c) the end of the output.
The section before a conditional newline consists of: all the output back
to, but not including, (a) the previous conditional newline that is
immediately contained in the same logical block; or if (a) is not
applicable, (b) the beginning of the immediately containing logical block.
The last four lines in Figure 1 indicate the sections before and after the
four conditional newlines.
The section immediately containing a conditional newline is the shortest
section that contains the conditional newline in question. In Figure 1,
the first conditional newline is immediately contained in the section
marked with 0's, the second and third conditional newlines are immediately
contained in the section before the fourth conditional newline, and the
fourth conditional newline is immediately contained in the section after
the first conditional newline.
<-1---<--<--2---3->--4-->->
000000000000000000000000000
11 111111111111111111111111
22 222
333 3333
44444444444444 44444
Figure 1: Example of logical blocks, conditional newlines, and sections.
Whenever possible, the pretty printer displays the entire contents of a
section on a single line. However, if the section is too long to fit in
the space available, line breaks are inserted at conditional newline
positions within the section.
PPRINT-NEWLINE kind &OPTIONAL (stream *STANDARD-OUTPUT*) [Function]
STREAM (which defaults to *STANDARD-OUTPUT*) follows the standard
conventions for stream arguments to printing functions (i.e., NIL stands
for *STANDARD-OUTPUT* and T stands for *TERMINAL-IO*). The KIND argument
specifies the style of conditional newline. It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY. An error is signalled if any other value is
supplied. If STREAM is a pretty printing stream created by
PPRINT-LOGICAL-BLOCK, a line break is inserted in the output when the
appropriate condition below is satisfied. Otherwise, PPRINT-NEWLINE has no
effect. The value NIL is always returned.
If KIND is :LINEAR, it specifies a `linear-style' conditional newline. A
line break is inserted if and only if the immediately containing section
cannot be printed on one line. The effect of this is that line breaks are
either inserted at every linear-style conditional newline in a logical
block or at none of them.
If KIND is :MISER, it specifies a `miser-style' conditional newline. A
line break is inserted if and only if the immediately containing section
cannot be printed on one line and miser style is in effect in the
immediately containing logical block. The effect of this is that
miser-style conditional newlines act like linear-style conditional
newlines, but only when miser style is in effect. Miser style is in effect
for a logical block if and only if the starting position of the logical
block is less than or equal to *PRINT-MISER-WIDTH* from the right margin.
If KIND is :FILL, it specifies a `fill-style' conditional newline. A line
break is inserted if and only if either (a) the following section cannot be
printed on the end of the current line, (b) the preceding section was not
printed on a single line, or (c) the immediately containing section cannot
be printed on one line and miser style is in effect in the immediately
containing logical block. If a logical block is broken up into a number of
subsections by fill-style conditional newlines, the basic effect is that
the logical block is printed with as many subsections as possible on each
line. However, if miser style is in effect, fill-style conditional
newlines act like linear-style conditional newlines.
If KIND is :MANDATORY, it specifies a `mandatory-style' conditional
newline. A line break is always inserted. This implies that none of the
containing sections can be printed on a single line and will therefore
trigger the insertion of line breaks at linear-style conditional newlines
in these sections.
When a line break is inserted by any type of conditional newline, any
blanks that immediately precede the conditional newline are omitted from
the output and indentation is introduced at the beginning of the next line.
By default, the indentation causes the following line to begin in the same
horizontal position as the first character in the immediately containing
logical block. (The indentation can be changed via PPRINT-INDENT.)
There are a variety of ways unconditional newlines can be introduced into
the output (e.g., via TERPRI or by printing a string containing a newline
character). As with mandatory conditional newlines, this prevents any of
the containing sections from being printed on one line. In general, when
an unconditional newline is encountered, it is printed out without
suppression of the preceding blanks and without any indentation following
it. However, if a per-line prefix has been specified (see
PPRINT-LOGICAL-BLOCK), this prefix will always be printed no matter how a
newline originates.
PPRINT-LOGICAL-BLOCK (stream-symbol list [Macro]
&KEY :prefix :per-line-prefix :suffix)
&BODY body
This macro causes printing to be grouped into a logical block. The value
NIL is always returned.
STREAM-SYMBOL must be a symbol. If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*. If it is T, it is treated the same as if
it were *TERMINAL-IO*. The run-time value of STREAM-SYMBOL must be a
stream (or NIL standing for *STANDARD-OUTPUT* or T standing for *TERMINAL-IO*).
The logical block is printed into this destination stream.
The BODY can contain any arbitrary Lisp forms. Within the BODY,
STREAM-SYMBOL (or *STANDARD-OUTPUT* if STREAM-SYMBOL is NIL, or
*TERMINAL-IO* if STREAM-SYMBOL is T) is bound to a `pretty printing' stream
that supports decisions about the arrangement of output and then forwards
the output to the destination stream. All the standard printing functions
(e.g., WRITE, PRINC, TERPRI) can be used to print output the pretty
printing stream created by PPRINT-LOGICAL-BLOCK. All and only the output
sent to this pretty printing stream is treated as being in the logical
block.
PPRINT-LOGICAL-BLOCK and the pretty printing stream it creates have dynamic
extent. It is undefined what happens if output is attempted outside of
this extent to the pretty printing stream created. It is unspecified what
happens if, within this extent, any output is sent directly to the
underlying destination stream.
The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that (at
run time) evaluate to strings. :SUFFIX (which defaults to the null string)
specifies a suffix that is printed just after the logical block. The
:PREFIX and :PRE-LINE-PREFIX arguments are mutually exclusive. If neither
:PREFIX or :PER-LINE-PREFIX is specified, a :PREFIX of the null string is
assumed. :PREFIX specifies a prefix to be printed before the beginning of
the logical block. :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block. An
error is signalled if :PREFIX and :PRE-LINE-PREFIX are both used or if the
:SUFFIX, :PREFIX, or :PER-LINE-PREFIX do not evaluate to strings.
LIST is interpreted as being a list that BODY is responsible for
printing. (See PPRINT-EXIT-IF-LIST-EXHAUSTED and PPRINT-POP.) If
LIST does not (at run time) evaluate to a list, it is printed using
WRITE. (This makes it easier to write printing functions that are
robust in the face of malformed arguments.) If *PRINT-CIRCLE* (and
possibly *PRINT-SHARED*) is not NIL and LIST is a circular (or shared)
reference to a cons, then an appropriate #n# marker is printed. (This
makes it easy to write printing functions that provide full support
for circularity and sharing abbreviation.) If *PRINT-LEVEL* is not
NIL and the logical block is at a dynamic nesting depth of greater
than *PRINT-LEVEL* in logical blocks, # is printed. (This makes easy
to write printing functions that provide full support for depth
abbreviation.)
If either of the three conditions above occurs, the indicated output is
printed on STREAM-SYMBOL and the BODY is skipped along with the printing of
the :PREFIX and :SUFFIX. (If the BODY is not responsible for printing a
list, then the first two tests above can be turned off by supplying NIL for
the LIST argument.)
In addition to the LIST argument of PPRINT-LOGICAL-BLOCK, the arguments of
the standard printing functions such as WRITE, PRINT, PPRINT, PRINT1, and
PPRINT, as well as the arguments of the standard FORMAT directives such as
~A, ~S, (and ~W) are all checked (when necessary) for circularity and
sharing. However, such checking is not applied to the arguments of the
functions WRITE-LINE, WRITE-STRING, and WRITE-CHAR or to the literal text
output by FORMAT. A consequence of this is that you must use one of the
latter functions if you want to print some literal text in the output that
is not supposed to be checked for circularity or sharing. (See the
examples below.)
----------------------------------------
Implementation note: detection of circularity and sharing is supported by
the pretty printer by in essence performing requested output twice.
On the first pass, circularities and sharing are detected and the
actual outputting of characters is suppressed. On the second pass, the
appropriate #n= and #n# markers are inserted and characters are output.
A consequence of this two-pass approach to the detection of circularity and
sharing is that the BODY of a PPRINT-LOGICAL-BLOCK must not perform any
side-effects on the surrounding environment. This includes not modifying
any variables that are bound outside of its scope. Obeying this
restriction is facilitated by using PPRINT-POP, instead of an ordinary POP
when traversing a list being printed by the BODY of a
PPRINT-LOGICAL-BLOCK.)
----------------------------------------
PPRINT-EXIT-IF-LIST-EXHAUSTED [Macro]
PPRINT-EXIT-IF-LIST-EXHAUSTED tests whether or not the LIST passed to
PPRINT-LOGICAL-BLOCK has been exhausted (see PPRINT-POP). If this list has
been reduced to NIL, PPRINT-EXIT-IF-LIST-EXHAUSTED terminates the execution
of the immediately containing PPRINT-LOGICAL-BLOCK except for the printing
of the suffix. Otherwise PPRINT-EXIT-IF-LIST-EXHAUSTED returns NIL. An
error message is issued if PPRINT-EXIT-IF-LIST-EXHAUSTED is used anywhere
other than syntactically nested within a call on PPRINT-LOGICAL-BLOCK. It
is undefined what happens if PPRINT-IF-LIST-EXHAUSTED is executed outside
of the dynamic extent of this PPRINT-LOGICAL-BLOCK.
PPRINT-POP [Macro]
PPRINT-POP pops elements one at a time off the LIST passed to
PPRINT-LOGICAL-BLOCK obeying *PRINT-LENGTH*, *PRINT-CIRCLE*, and
*PRINT-SHARED*. An error message is issued if it is used anywhere
other than syntactically nested within a call on PPRINT-LOGICAL-BLOCK.
It is undefined what happens if PPRINT-POP is executed outside of the
dynamic extent of this PPRINT-LOGICAL-BLOCK.
Each time PPRINT-POP is called, it pops the next value off the LIST
passed to PPRINT-LOGICAL-BLOCK and returns it. However, before doing
this, it performs three tests. If the remaining list is not a list
(i.e., a cons or NIL), ". " is printed followed by the remaining list.
(This makes it easier to write printing functions that are robust in
the face of malformed arguments.) If *PRINT-LENGTH* is NIL and
PPRINT-POP has already been called *PRINT-LENGTH* times within the
immediately containing logical block, "..." is printed. (This makes
it easy to write printing functions that properly handle
*PRINT-LENGTH*.) If *PRINT-CIRCLE* (and possibly *PRINT-SHARED*) is
not NIL, and the remaining list is a circular (or shared) reference,
then ". " is printed followed by an appropriate #n# marker. (This
catches instances of cdr circularity and sharing in lists.)
If either of the three conditions above occurs, the indicated output is
printed on the pretty printing stream created by the immediately containing
PPRINT-LOGICAL-BLOCK and the execution of the immediately containing
PPRINT-LOGICAL-BLOCK is terminated except for the printing of the suffix.
If PPRINT-LOGICAL-BLOCK is given a LIST argument of NIL---because it is not
processing a list---PPRINT-POP can still be used to obtain support for
*PRINT-LENGTH* (see the example function PPRINT-VECTOR below). In this
situation, the first and third tests above are disabled and
PPRINT-POP always returns NIL.
PPRINT-INDENT relative-to n &OPTIONAL (stream *STANDARD-OUTPUT*) [Function]
PPRINT-INDENT specifies the indentation to use in a logical block. STREAM
(which defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. N specifies the indentation in
ems. If RELATIVE-TO is :BLOCK, the indentation is set to the horizontal
position of the first character in the block plus N ems. If RELATIVE-TO is
:CURRENT, the indentation is set to the current output position plus N ems.
(For robustness in the face of variable-width fonts, it is advisable to use
:CURRENT with an N of zero whenever possible.)
N can be negative; however, the total indentation cannot be moved left of
the beginning of the line or left of the end of the rightmost per-line
prefix. Changes in indentation caused by PPRINT-INDENT do not take
effect until after the next line break. In addition, in miser mode all
calls on PPRINT-INDENT are ignored, forcing the lines corresponding to the
logical block to line up under the first character in the block.
An error is signalled if a value other than :BLOCK or :CURRENT is supplied
for RELATIVE-TO. If STREAM is a pretty printing stream created by
PPRINT-LOGICAL-BLOCK, PPRINT-INDENT sets the indentation in the innermost
dynamically enclosing logical block. Otherwise, PPRINT-INDENT has no
effect. The value NIL is always returned.
PPRINT-TAB kind colnum colinc &OPTIONAL (stream *STANDARD-OUTPUT*) [function]
PPRINT-TAB specifies tabbing as performed by the standard FORMAT directive
~T. STREAM (which defaults to *STANDARD-OUTPUT*) follows the standard
conventions for stream arguments to printing functions. The arguments
COLNUM and COLINC correspond to the two parameters to ~T and are in terms
of ems. The KIND argument specifies the style of tabbing. It must be one
of :LINE (tab as by ~T) :SECTION (tab as by ~T, but measuring horizontal
positions relative to the start of the dynamically enclosing section),
:LINE-RELATIVE (tab as by ~@T), or :SECTION-RELATIVE (tab as by ~@T, but
measuring horizontal positions relative to the start of the dynamically
enclosing section). An error is signalled if any other value is supplied
for KIND. If STREAM is a pretty printing stream created by
PPRINT-LOGICAL-BLOCK, tabbing is performed. Otherwise, PPRINT-TAB has no
effect. The value NIL is always returned.
PPRINT-FILL STREAM LIST &OPTIONAL (COLON? T) ATSIGN? [function]
PPRINT-LINEAR STREAM LIST &OPTIONAL (COLON? T) ATSIGN? [function]
PPRINT-TABULAR STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16) [function]
These three functions specify particular ways of pretty printing lists.
STREAM follows the standard conventions for stream arguments to printing
functions. Each function prints parentheses around the output if and only
if COLON? (default T) is not NIL. Each function ignores its ATSIGN?
argument and returns NIL. (These two arguments are included in this way so
that these functions can be used via ~/.../ and as SET-PPRINT-DISPATCH
functions as well as directly.) Each function handles abbreviation and the
detection of circularity and sharing correctly, and uses WRITE to print
LIST when given a non-list argument.
The function PPRINT-LINEAR prints a list either all on one line, or with
each element on a separate line. The function PPRINT-FILL prints a list
with as many elements as possible on each line. The function
PPRINT-TABULAR is the same as PPRINT-FILL except that it prints the
elements so that they line up in columns. This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.
---
As an example of the interaction of logical blocks, conditional newlines,
and indentation, consider the function SIMPLE-PPRINT-DEFUN below. This
function prints out lists whose cars are DEFUN in the standard way assuming
that the list has exactly length 4.
(defun simple-pprint-defun (*standard-output* list)
(pprint-logical-block (*standard-output* list :prefix "(" :suffix ")")
(write (first list))
(write-char #\space)
(pprint-newline :miser)
(pprint-indent :current 0)
(write (second list))
(write-char #\space)
(pprint-newline :fill)
(write (third list))
(pprint-indent :block 1)
(write-char #\space)
(pprint-newline :linear)
(write (fourth list))))
Suppose that one evaluates the following:
(simple-pprint-defun *standard-output* '(defun prod (x y) (* x y)))
If the line width available is greater than or equal to 26, then all of the
output appears on one line. If the line width available is reduced to 25,
a line break is inserted at the linear-style conditional newline before the
expression (* X Y), producing the output shown. The (PPRINT-INDENT :BLOCK 1)
causes (* X Y) to be printed at a relative indentation of 1 in the logical block.
(DEFUN PROD (X Y)
(* X Y))
If the line width available is 15, a line break is also inserted at the
fill style conditional newline before the argument list. The call on
(PPRINT-INDENT :CURRENT 0) causes the argument list to line up under the
function name.
(DEFUN PROD
(X Y)
(* X Y))
If *PRINT-MISER-WIDTH* were greater than or equal to 14, the example output
above would have been as follows, because all indentation changes are
ignored in miser mode and line breaks are inserted at miser-style
conditional newlines.
(DEFUN
PROD
(X Y)
(* X Y))
---
As an example of a per-line prefix, consider that evaluating the following
produces the output shown with a line width of 20 and *PRINT-MISER-WIDTH*
of NIL.
(pprint-logical-block (*standard-output* nil :per-line-prefix ";;; ")
(simple-pprint-defun *standard-output* '(defun prod (x y) (* x y))))
;;; (DEFUN PROD
;;; (X Y)
;;; (* X Y))
---
As a more complex (and realistic) example, consider the function PPRINT-LET
below. This specifies how to print a LET in the standard style. It is more
complex than the example above, because it has to deal with nested structure.
Also, unlike the example above it contains complete code to readably print any
possible list that begins with the symbol LET. The outermost
PPRINT-LOGICAL-BLOCK handles the printing of the input list as a whole and
specifies that parentheses should be printed in the output. The second
PPRINT-LOGICAL-BLOCK handles the list of binding pairs. Each pair in the list
is itself printed by the innermost PPRINT-LOGICAL-BLOCK. (A LOOP is used
instead of merely decomposing the pair into two elements so that readable
output will be produced no matter whether the list corresponding to the pair
has one element, two elements, or (being malformed) has more than two
elements.) A space and a fill-style conditional newline are placed after
each pair except the last. The loop at the end of the topmost
PPRINT-LOGICAL-BLOCK prints out the forms in the body of the LET separated by
spaces and linear-style conditional newlines.
(defun pprint-let (*standard-output* list)
(pprint-logical-block (nil list :prefix "(" :suffix ")")
(write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :fill)))
(pprint-indent :block 1)
(loop (pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)
(write (pprint-pop)))))
Suppose that one evaluates the following with *PRINT-LEVEL* 4, and
*PRINT-CIRCLE* T.
(pprint-let *standard-output*
'#1=(let (x (*print-length* (f (g 3)))
(z . 2) (k (car y)))
(setq x (sqrt z)) #1#))
If the line length is greater than or equal to 77, the output produced
appears on one line. However, if the line length is 76, line breaks are
inserted at the linear-style conditional newlines separating the forms in
the body and the output below is produced. Note that, the degenerate
binding pair X is printed readably even though it fails to be a list; a
depth abbreviation marker is printed in place of (G 3); the binding pair
(Z . 2) is printed readably even though it is not a proper list; and
appropriate circularity markers are printed.
#1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
If the line length is reduced to 35, a line break is inserted at one of the
fill-style conditional newlines separating the binding pairs.
#1=(LET (X (*PRINT-PRETTY* (F #))
(Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
Suppose that the line length is further reduced to 22 and *PRINT-LENGTH* is
set to 3. In this situation, line breaks are inserted after both the first
and second binding pairs. In addition, the second binding pair is itself
broken across two lines. Clause (b) of the description of fill-style
conditional newlines prevents the binding pair (Z . 2) from being printed
at the end of the third line. Note that the length abbreviation hides the
circularity from view and therefore the printing of circularity markers
disappears.
(LET (X
(*PRINT-LENGTH*
(F #))
(Z . 2) ...)
(SETQ X (SQRT Z))
...)
---
The function PPRINT-TABULAR could be defined as follows.
(defun pprint-tabular (s list &optional (colon? T) atsign? (tabsize nil))
(declare (ignore atsign?))
(when (null tabsize) (setq tabsize 16))
(pprint-logical-block (s list :prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(pprint-exit-if-list-exhausted)
(loop (write (pprint-pop) :stream s)
(pprint-exit-if-list-exhausted)
(write-char #\space s)
(pprint-tab :section-relative 0 tabsize s)
(pprint-newline :fill s))))
Evaluating the following with a line length of 25 produces the output shown.
(princ "Roads ")
(pprint-tabular *standard-output* '(elm main maple center) nil nil 8)
Roads ELM MAIN
MAPLE CENTER
---
The function below prints a vector using #(...) notation.
(defun pprint-vector (*standard-output* v)
(pprint-logical-block (nil nil :prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (pprint-pop)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(pprint-newline :fill))))))
Evaluating the following with a line length of 15 produces the output shown.
(pprint-vector *standard-output* '#(12 34 567 8 9012 34 567 89 0 1 23))
#(12 34 567 8
9012 34 567
89 0 1 23)
Format Directive Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through the functions above. However, an
additional interface is provided via a set of new format directives.
This is done, because as shown by the examples in this section and the
next, FORMAT strings are typically a much more compact way to specify
pretty printing. In addition, without such an interface, one would have to
abandon the use of FORMAT when interacting with the pretty printer.
~W [format directive]
WRITE -- An arg, any Lisp object, is printed obeying every printer control
variable (as by WRITE). In addition, ~W interacts correctly with depth
abbreviation, by not resetting the depth counter to zero. ~W does not
accept parameters. If given the colon modifier, ~W binds *PRINT-PRETTY* to
T. If given the atsign modifier, ~W binds *PRINT-LEVEL* and *PRINT-LENGTH*
to NIL.
~W provides automatic support for the detection of circularity and
sharing. If *PRINT-CIRCLE* (and possibly *PRINT-SHARED*) is not NIL
and ~W is applied to an argument that is a circular (or shared)
reference, an appropriate #n# marker is inserted in the output instead
of printing the argument.
~_ [format directive]
CONDITIONAL-NEWLINE -- Without any modifiers, ~_ is the same as
(PPRINT-NEWLINE :LINEAR). ~@_ is the same as (PPRINT-NEWLINE :MISER).
~:_ is the same as (PPRINT-NEWLINE :FILL). ~:@_ is the same as
(PPRINT-NEWLINE :MANDATORY).
~<...~:> [format directive]
LOGICAL BLOCK -- If ~:> is used to terminate a ~<...~>, the directive
is equivalent to a call on PPRINT-LOGICAL-BLOCK. The FORMAT argument
corresponding to the ~<...~:> directive is treated in the same way as
the LIST argument to PPRINT-LOGICAL-BLOCK, thereby providing automatic
support for non-list arguments and the detection of circularity,
sharing, and depth abbreviation. The portion of the FORMAT control
string nested within the ~<...~:> specifies the :PREFIX (or
:PER-LINE-PREFIX), :suffix}, and body of the PPRINT-LOGICAL-BLOCK.
The FORMAT string portion enclosed by ~<...~:> can be divided into
segments ~<prefix~;body~;suffix~:> by ~; directives. If the first
section is terminated by ~@;, it specifies a per-line prefix rather
than a simple prefix. The prefix and suffix cannot contain FORMAT
directives. An error is signalled if either the prefix or suffix
fails to be a constant string or if the enclosed portion is divided
into more than three segments.
If the enclosed portion is divided into only two segments, the suffix
defaults to the null string. If the enclosed portion consists of only
a single segment, both the prefix and the suffix default to the null
string. If the colon modifier is used (i.e., ~:<...~:>), the prefix
and suffix default to "(" and ")" (respectively) instead of the null
string.
The body segment can be any arbitrary FORMAT control string. This
FORMAT control string is applied to the elements of the list
corresponding to the ~<...~:> directive as a whole. Elements are
extracted from this list using PPRINT-POP, thereby providing automatic
support for malformed lists, and the detection of circularity,
sharing, and length abbreviation. Within the body segment, ~↑ acts
like PPRINT-EXIT-IF-LIST-EXHAUSTED.
~<...~:> supports a feature not supported by PPRINT-LOGICAL-BLOCK. If
~:@> is used to terminate the directive (i.e., ~<...~:@>), then a
fill-style conditional newline is automatically inserted after each
group of blanks immediately contained in the body (except for blanks
after a ~<newline> directive). This makes it easy to achieve the
equivalent of paragraph filling.
If the atsign modifier is used with ~<...~:>, the entire remaining argument
list is passed to the directive as its argument. All of the remaining
arguments are always consumed by ~@<...~:>, even if they are not all used
by the FORMAT string nested in the directive. Other than the difference in
its argument, ~@<...~:> is exactly the same as ~<...~:> except that
circularity detection is not applied if ~@<...~:> is encountered at top
level in a {\cd format} string. This ensures that circularity detection is
applied only to data lists, not to {\cd format} argument lists.
" . #n#" is printed if circularity or sharing has
to be indicated for its argument as a whole.
To a considerable extent, the basic form of the directive ~<...~> is
incompatible with the dynamic control of the arrangement of output by
~W, ~_, ~<...~:>, ~I, and ~:T. As a result, an error is signalled if
any of these directives is nested within ~<...~>. Beyond this, an
error is also signalled if the ~<...~:;...~> form of ~<...~> is used
in the same FORMAT string with ~W, ~_, ~<...~:>, ~I, or ~:T.
~I [format directive]
INDENT -- ~nI is the same as (PPRINT-INDENT :BLOCK N).
~n:I is the same as (PPRINT-INDENT :CURRENT N). In both cases, N defaults
to zero, if it is omitted.
~:T [format directive]
TABULATE -- If the colon modifier is used with the ~T directive, the
tabbing computation is done relative to the horizontal position where the
section immediately containing the directive begins, rather than with
respect to a horizontal position of zero. The numerical parameters are
both interpreted as being in units of ems and both default to 1.
~n,m:T is the same as (PPRINT-TAB :SECTION N M).
~n,m:@T is the same as (PPRINT-TAB :SECTION-RELATIVE N M).
~/name/ [format directive]
CALL FUNCTION -- User defined functions can be called from within a FORMAT
string by using the directive ~/name/. The colon modifier, the atsign
modifier, and arbitrarily many parameters can be specified with the ~/name/
directive. NAME can be any arbitrary string that does not contain a "/".
All of the characters in NAME are treated as if they were upper case. If
NAME contains a ":" or "::", then everything up to but not including the
first ":" or "::" is taken to be a string that names a package. Everything
after the first ":" or "::" (if any) is taken to be a string that names a
symbol. The function corresponding to a ~/name/ directive is obtained by
looking up the symbol that has the indicated name in the indicated package.
If NAME does not contain a ":" or "::", then the whole name string is
looked up in the USER package.
When a ~/name/ directive is encountered, the indicated function is called
with four or more arguments. The first four arguments are: the output
stream, the FORMAT argument corresponding to the directive, the value T if
the colon modifier was used (NIL otherwise), and the value T if the atsign
modifier was used (NIL otherwise). The remaining arguments consist of any
parameters specified with the directive. The function should print the
argument appropriately. Any values returned by the function are ignored.
The three functions PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR are
specifically designed so that they can be called by ~/.../ (i.e.,
~/PPRINT-LINEAR/, ~/PPRINT-FILL/, and ~/PPRINT-TABULAR/). In particular
they take colon and atsign arguments.
---
As examples of the convenience of specifying pretty printing with FORMAT
strings, consider that the first two functions used as examples in the last
section can be compactly defined as follows. The function PPRINT-VECTOR
cannot be defined using FORMAT, because the data structure it traverses is
not a list. The function PPRINT-TABULAR is inconvenient to define using
FORMAT, because of the need to pass its TABSIZE argument through to a ~:T
directive nested within an iteration over a list.
(defun simple-pprint-defun (*standard-output* list)
(format T "~:<~W ~@_~:I~W ~:_~W~1I ~_~W~:>" list))
(defun pprint-let (*standard-output* list)
(format T "~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~1I~@{~↑ ~_~W~}~:>" list))
Compiling Format Control Strings
The control strings used by FORMAT are essentially programs that perform
printing. The macro FORMATTER provides the efficiency of using a compiled
function for printing without losing the compactness of FORMAT control
strings.
FORMATTER control-string [macro]
CONTROL-STRING must be a literal string. An error is signalled if
CONTROL-STRING is not a valid FORMAT control string. The macro FORMATTER
expands into an expression of the form (FUNCTION (LAMBDA (STREAM &REST
ARGS) ...)) that does the printing specified by CONTROL-STRING. The
LAMBDA created accepts an output stream as its first argument and zero or
more data values as its remaining arguments. The value returned by the
LAMBDA is the tail (if any) of the data values that are not printed out by
CONTROL-STRING. (E.g., if the CONTROL-STRING is "~A~A" the CDDR (if any)
of the data values is returned.)
For instance: (formatter "~%~2@{~S, ~}") is equivalent to
#'(lambda (stream &rest args)
(terpri stream)
(dotimes (n 2)
(if (null args) (return nil))
(prin1 (pop args) stream)
(write-string ", " stream))
args)
In support of the above, FORMAT is extended so that it accepts functions as
its second argument as well as strings. When a function is provided, it
must be a function of the form created by FORMATTER. The function is called
with the appropriate output stream as its first argument and the data
arguments to FORMAT as its remaining arguments. The function should
perform whatever output is necessary and return the unused tail of the
arguments (if any). The directives ~? and ~{~} with no body are also
extended so that they accept functions as well as control strings.
Every other standard function that takes a FORMAT string as an argument
(e.g., ERROR and WARN) are also extended so that they can accept functions
of the form above instead.
Pretty Print Dispatch Tables
When *PRINT-PRETTY* is not NIL, the pprint dispatch table in the variable
*PRINT-PPRINT-DISPATCH* controls how objects are printed. The information
in this table takes precedence over all other mechanisms for specifying how
to print objects. In particular, it overrides user-defined PRINT-OBJECT
methods and print functions for structures. However, if there is no
specification for how to pretty print a particular kind of object, it is then
printed using the standard mechanisms as if *PRINT-PRETTY* were NIL.
Pprint dispatch tables are mappings from keys to pairs of values. The keys
are type specifiers. The values are functions and numerical priorities.
Basic insertion and retrieval is done based on the keys with the equality
of keys being tested by EQUAL. The function to use when pretty printing an
object is chosen by finding the highest priority function from
*PRINT-PPRINT-DISPATCH* that is associated with a type specifier that
matches the object.
COPY-PPRINT-DISPATCH &optional (table *PRINT-PPRINT-DISPATCH*) [function]
A copy is made of TABLE, which defaults to the current pprint dispatch
table. If TABLE is NIL, a copy is returned of the initial value of
*PRINT-PPRINT-DISPATCH*.
PPRINT-DISPATCH object &optional (table *PRINT-PPRINT-DISPATCH*) [function]
This retrieves the highest priority function from a pprint table that is
associated with a type specifier in the table that matches OBJECT. The
function is chosen by finding all the type specifiers in TABLE that match
the object and selecting the highest priority function associated with any
of these type specifiers. If there is more than one highest priority
function, an arbitrary choice is made. If no type specifiers match the
object, a function is returned that prints object with *PRINT-PRETTY* bound
to NIL.
As a second return value, PPRINT-DISPATCH returns a flag that is T if a
matching type specifier was found in TABLE and NIL if not.
TABLE (which defaults to *PRINT-PPRINT-DISPATCH*) must be a pprint dispatch
table. TABLE can be NIL, in which case retrieval is done in the initial
value of *PRINT-PPRINT-DISPATCH*.
When *PRINT-PRETTY* is T, (WRITE OBJECT :STREAM S) is equivalent to
(FUNCALL (PPRINT-DISPATCH OBJECT) S OBJECT).
SET-PPRINT-DISPATCH type-specifier function [function]
&optional (priority 0) (table *PRINT-PPRINT-DISPATCH*)
This puts an entry into a pprint dispatch table and returns NIL.
TYPE-SPECIFIER must be a valid type specifier and is the key of the entry.
The first action of SET-PPRINT-DISPATCH is to remove any pre-existing entry
associated with TYPE-SPECIFIER. This guarantees that there will never be
two entries associated with the same type specifier in a given pprint
dispatch table. Equality of type specifiers is tested by EQUAL.
Two values are associated with each type specifier in a pprint dispatch
table: a function and a priority. FUNCTION must accept two arguments: the
stream to send output to and the object to be printed. FUNCTION should
pretty print the object on the stream. FUNCTION can assume that object
satisfies TYPE-SPECIFIER. Function must obey *PRINT-READABLY* (see issue
DATA-IO). Any values returned by FUNCTION are ignored.
PRIORITY (which defaults to 0) must be a non-complex number. This
number is used as a priority to resolve conflicts when an object
matches more than one entry. An error is signalled if priority fails
to be a non-complex number.
TABLE (which defaults to *PRINT-PPRINT-DISPATCH*) must be a pprint dispatch
table. The specified entry is placed in this table.
It is permissible for FUNCTION to be NIL. In this situation, there will be
no TYPE-SPECIFIER entry in TABLE after SET-PPRINT-DISPATCH is evaluated.
To facilitate the use of pprint dispatch tables for controlling the pretty
printing of Lisp code, the TYPE-SPECIFIER argument of the function
SET-PPRINT-DISPATCH is allowed to contain constructs of the form
(CONS car-type cdr-type)
This signifies that the corresponding object must be a cons cell whose car
matches the type specifier CAR-TYPE and whose cdr matches the type specifier
CDR-TYPE. The CDR-TYPE can be omitted in which case it defaults to T.
The initial value of *PRINT-PPRINT-DISPATCH* is implementation dependent.
However, the initial entries all use a special class of priorities that
have the property that they are less than every priority that can be
specified using SET-PPRINT-DISPATCH. The benefit of this is that it
guarantees that any pretty printing functions users specify will override
everything in the initial value of *PRINT-PPRINT-DISPATCH*.
----------------------------------------------------------------------
Implementation note: The restriction above is very useful to users
without actually limiting what Common Lisp implementors can do. It is
possible for implementors to set up any kind of pretty printing they
desire using the range of priorities available to them.
----------------------------------------------------------------------
Consider the following examples. The first form restores
*PRINT-PPRINT-DISPATCH* to its initial value. The next two forms then set
up a special way to pretty print ratios. Note that the more specific type
specifier has to be associated with a higher priority.
(setq *print-pprint-dispatch* (copy-pprint-dispatch nil))
(set-pprint-dispatch 'ratio
#'(lambda (s obj)
(format s "#.(/ ~W ~W)" (numerator obj) (denominator obj))))
(set-pprint-dispatch '(and ratio (satisfies minusp))
#'(lambda (s obj)
(format s "#.(- (/ ~W ~W))" (- (numerator obj)) (denominator obj)))
5)
(pprint '(1/3 -2/3)) prints: (#.(/ 1 3) #.(- (/ 2 3)))
The following two forms illustrate the definition of pretty printing
functions for types of Lisp code. The first form illustrates how to
specify the traditional method for printing quoted objects using "'"
syntax. Note the care taken to ensure that data lists that happen to begin
with QUOTE will be printed readably. The second form specifies that lists
beginning with the symbol MY-LET should print the same way that lists
beginning with LET print when the initial pprint dispatch table is in effect.
(set-pprint-dispatch '(cons (member quote)) ()
#'(lambda (s list)
(if (and (consp (cdr list)) (null (cddr list)))
(funcall (formatter "'~W") s (cadr list))
(pprint-fill s list)))))
(set-pprint-dispatch '(cons (member my-let)) (pprint-dispatch '(let) nil))
The next example specifies a default method for printing lists that do not
correspond to function calls. Note that, as shown in the definition of
PPRINT-TABULAR above, PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR are
all defined with optional COLON? and ATSIGN? arguments so that they can be
used as pprint dispatch functions as well as ~/.../ functions.
(set-pprint-dispatch '(cons (not (and symbol (satisfies fboundp))))
#'pprint-fill -5)
with a line length of 9, (pprint '(0 b c d e f g h i j k)) prints:
(0 b c d
e f g h
i j k)
This final example shows how to define a pretty printing function for a
user defined data structure.
(defstruct family mom kids)
(set-pprint-dispatch 'family
#'(lambda (s f)
(funcall (formatter "~@<#<~;~W and ~2I~_~/pprint-fill/~;>~:>")
s (family-mom f) (family-kids f))))
The pretty printing function for the structure FAMILY specifies how to
adjust the layout of the output so that it can fit aesthetically into
a variety of line widths. In addition, it obeys the printer control
variables *PRINT-LEVEL*, *PRINT-LENGTH*, *PRINT-LINES*,
*PRINT-CIRCLE*, *PRINT-SHARED* and *PRINT-ESCAPE*, and can tolerate
several different kinds of malformity in the data structure. The
output below shows what is printed out with a right margin of 25,
*PRINT-PRETTY* T, *PRINT-ESCAPE* NIL, and a malformed KIDS list.
(write (list 'principal-family
(make-family :mom "Lucy"
:kids '("Mark" "Bob" . "Dan")))
:right-margin 25 :pretty T :escape nil :miser-width nil)
(PRINCIPAL-FAMILY
#<Lucy and
Mark Bob . Dan>)
Note that a pretty printing function for a structure is different from the
structure's print function. While print functions are permanently
associated with a structure, pretty printing functions are stored in pprint
dispatch tables and can be rapidly changed to reflect different printing
needs. If there is no pretty printing function for a structure in the
current print dispatch table, the print function (if any) is used instead.
[end of part two of PRETTY-PRINT-INTERFACE:XP]
∂14-Aug-89 1013 CL-Error-Handling-mailer Answers to common administrative questions about CL error handling
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 14 Aug 89 10:13:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 641136; 14 Aug 89 12:35:30 EDT
Date: Mon, 14 Aug 89 12:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Answers to common administrative questions about CL error handling
To: CL-Error-Handling@SAIL.Stanford.EDU, X3J13@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890814163516.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I've been getting a lot of queries about the state of the condition system
lately and I wanted to get the community brought up to date...
- Yes, version 18 of the condition system (AI.AI.MIT.EDU:COMMON;COND18 TEXT)
is still `current' in the sense that there has been no version 19.
Version 18 was approved by X3J13 and can only be modified by the cleanup
process. The only coherent conditions document which will follow will be
the full ANSI spec.
- Yes, AI.AI.MIT.EDU is hard to get to. With some help from Larry Masinter,
I have moved the two files holding the condition system to a new home
on ARISIA.XEROX.COM, where you can get them via anonymous FTP...
/cl/conditions/cond18.text
/cl/conditions/cond18.lisp
- Yes, there have been cleanups which have affected the correctness of
version 18. The two most relevant cleanups are CONDTION-RESTARTS and
CLOS-CONDITIONS, also available from ARISIA.XEROX.COM, in the files:
/cl/cleanup/passed/condition-restarts
/cl/cleanup/passed/clos-conditions
- Given that version 18 has been amended and there is no coherent document
to use, what should you take as an authority?
If you are an implementor, you should definitely look at BOTH the
version 18 proposal and all condition-related cleanups. There may
be others which have a smaller impact as well, but the two above are
the most major. Of course, how much you implement and how fast is
really up to you--there is no ANSI spec yet, so strictly speaking
there is not yet anything for you to say you conform to.
If you're a user are are just doing programming in some system
which claims to support the emerging system, my feeling is that
you should look at NEITHER. I recommend instead that you consult
vendor-supplied documentation to find out what your vendor intended
you to be using. Although not really secret, these X3J13 documents
are not public in the sense that they are not easily accessible.
Also, they are prone to change. As such, they are not something you
should rely on as authoritative. Different vendors are providing
different levels of compatibility in the interim, and are tracking
changes at different rates. Only your vendor can tell you what
you can reasonably expect out of their implementation.
I apologize for the broad distribution--I hope this information is helpful
to some of you who are scrambling to bring yourselves up to date. If you
have more questions, feel free to reply to me PRIVATELY. To avoid excess
mail traffic, do NOT direct your replies to the `X3J13' mailing list.
Thanks.
∂16-Aug-89 2001 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5, part 1
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 89 20:01:08 PDT
Received: from MERLIN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 246208; Mon 7-Aug-89 12:15:49 EDT
Date: Mon, 7 Aug 89 12:15 EDT
From: Richard C. Waters <dick@AI.MIT.EDU>
Subject: PRETTY-PRINT-INTERFACE:XP version 5, part 1
To: x3j13@sail.stanford.edu
Message-ID: <19890807161519.1.DICK@MERLIN.AI.MIT.EDU>
THE ISSUE DESCRIBED HERE IS TOO LARGE TO FIT IN A SINGLE MESSAGE. AS A
RESULT, IT IS DIVIDED INTO TWO PARTS SENT IN TWO MESSAGES. THIS IS PART
ONE, WHICH IS IN THE STANDARD CLEANUP ISSUE FORMAT AND CONTAINS COMMENTARY
ON THE PROPOSAL. THE FULL DETAILED PROPOSAL ITSELF IS IN PART TWO.
--------------------
Version 3 (by Guy Steele Jr) supersedes version 2 and is changed from
version 1 as follows: adds a functional interface to supplement the
interface through FORMAT, and reflects comments by Barrett and
Pierson.
Version 4 (by Dick Waters) is changed from version 3 as follows: The
short summary is updated to reflect the functional interface. The
functional interface is changed following suggestions made by Dave Moon.
The proposal is amended in a few minor ways to increase the
compatibility with variable width fonts. Additional discussion has been
added with regard to the advantages of XP with respect to handling
detection and abbreviation, the interaction with CLOS, and
the extended type specifier CONS used by XP.
Version 5 (by Waters, Haflich, Laubsch, Loosemore, Pierson, and van Roggen).
On June 27 it was voted 12 to 4 in a plenary session of X3J13 that an add
hoc committee on pretty printing be created containing the above members
with the charter of ironing out the final details of the pretty print
interface and that if this committee could come to a unanimous decision on
the interface, the interface would become part of the draft Common Lisp
standard without the need of a further vote by the full committee.
As of August 7, the ad hoc subcommittee has reached uanimous approval of
the proposal below. The unanimity of the add hoc committee has been
signaled by having each member of the committee send a message to X3J13 to
this effect.
In addition to the main vote above, five straw polls were taken. Three
of these votes were overwhelming; however, two appeared too close to be
definitive. In order of the clarity of the outcome the straw votes were:
16-0 in favor of the basic functional interface,
10-4 against the inclusion of #"...",
12-7 in favor of having some way to convert a FORMAT string into a function,
11-8 in favor of allowing FORMAT to take a function as well as a string,
10-8 against the pretty printer extensions of FORMAT.
The subcommittee followed these recommendations except for the last.
(See the end of the discussion section.)
Version 5 is changed from version 4 as follows: The names of the
functions and variables have been changed to better reflect that (for the
most part) they are a group that applies only to pretty printing. The
variables *DEFAULT-RIGHT-MARGIN* and *LAST-ABBREVIATED-PRINTING* have been
eliminated. The readmacro construct #"..." has been eliminated and a new
macro FORMATTER introduced in its place. The way *PRINT-LINES*
abbreviation is indicated has been improved to ensure that the delimiters
will be balanced in the output and to ensure that the reader will complain
if you later try to read the output. The macros LOGICAL-BLOCK-POP and
LOGICAL-BLOCK-COUNT have been eliminated and the functionality they
supported provided in a slightly different form by two new macros
PPRINT-POP and PPRINT-EXIT-IF-LIST-EXHAUSTED. The macro
DEFINE-PRINT-DISPATCH has been replaced by a function SET-PPRINT-DISPATCH.
The proposal has been reorganized to show that the functional interface is
more fundamental than the FORMAT interface, to clarify exactly what happens
in error situations, and to indicate that the examples are merely examples
and not part of the proposal.
Issue: PRETTY-PRINT-INTERFACE
References: Description of XP by Dick Waters (attached)
*PRINT-PRETTY* (CLtL p. 371)
WRITE (CLtL p. 382)
PPRINT (CLtL p. 383)
FORMAT (CLtL pp. 385-407)
FORMAT ~T directive (CLtL pp. 398-399)
FORMAT ~< directive (CLtL pp. 404-406)
Related issues:
Category: CLARIFICATION CHANGE ADDITION
Edit history: Version 1, 24-Feb-89 by Steele
Version 2, 15-Mar-89 by Steele and Waters
Version 3, 15-Mar-89 by Steele
Version 4, 22-Mar-89 by Waters
Version 5, 7-Aug-89 by Waters et al
Problem description:
At present, Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it. In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.
Proposal (PRETTY-PRINT-INTERFACE:XP):
Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached document. Here is a very brief summary
of the proposal.
New variables: *PRINT-PPRINT-DISPATCH*
*PRINT-MISER-WIDTH*
*PRINT-RIGHT-MARGIN*
*PRINT-LINES*
New functions: COPY-PPRINT-DISPATCH
SET-PPRINT-DISPATCH
PPRINT-DISPATCH
PPRINT-NEWLINE
PPRINT-TAB
PPRINT-INDENT
PPRINT-FILL
PPRINT-LINEAR
PPRINT-TABULAR
New macros: PPRINT-LOGICAL-BLOCK
PPRINT-POP
FORMATTER
New FORMAT directives: ~W ~_ ~I ~:T ~/name/ ~<...~:>
The function WRITE is extended to accept four additional keyword arguments
:PPRINT-DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to
the four new variables.
The function FORMAT is extended so that it can accept a function instead of
a FORMAT string. (This change is also made in the other functions that
accept FORMAT strings such as ERROR and WARN.)
Examples: See attached document.
Rationale:
There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.
Current practice:
XP son of PP son of GPRINT son of #PRINT is the latest in a line of pretty
printers that goes back 13 years. All of these printers use essentially
the same basic algorithm and conceptual interface. Further, except for
#PRINT, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use. XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months. PP
has been the pretty printer in DEC Common Lisp for the past 3 years. Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp. In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)
Cost to Implementors: A fair amount of effort (several man-weeks at most).
Source code for XP is available to all comers from Dick Waters. It has
been arranged with MIT for anyone who wants to to get a non-exclusive
royalty-free license for XP from MIT. The system is documented in great
detail in:
Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102a,
Massachusetts Institute of Technology, Cambridge MA, July 1989.
Cost to Users: None (I think). This is an upward-compatible extension.
Cost of non-adoption: Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.
Performance impact: XP is claimed to be quite fast.
Benefits: User control of pretty-printing in a portable manner.
Aesthetics:
Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>. However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT. Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have a
directive that looks like matching brackets of some sort.
Dan Pierson comments: You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).
Discussion:
Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem. If so, another suggestion for naming
this directive would be appreciated.
The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal. However, it should be noted that the proposal for
~/.../ here is simpler than, and incompatible with, the current Zatalisp
practice.
Guy Steele and Dick Waters strongly support this proposal. (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)
---
Dan Pierson comments: You can add me to the list of strong supporters of
this proposal. While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments.
The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed. This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space.
The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right. The current proposal just
mentions them as a minor feature of XP.
At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level. STREAM-INFO
permitted people to use XP, but not to count on it. This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in. [End of comments by Pierson]
---
It has been noted by Guy Steele that some places in the initial document
where it says that circularity detection is handled correctly, this is
true a fortiori following the decision on PRINT-CIRCLE-STRUCTURE.
However, Waters notes that the vote on PRINT-CIRCLE-STRUCTURE said
nothing about the handling of *PRINT-LEVEL*. Therefore, the fact that
XP handles *PRINT-LEVEL* correctly is an improvement.
In addition, PRINT-CIRCLE-STRUCTURE is also silent on what is supposed
to happen if a user program decomposes a list itself (e.g., with DOLIST
or ~{~}) rather than calling a print function. Assumedly *PRINT-CIRCLE*
etc. is not handled in this case. In contrast, if one uses
PPRINT-LOGICAL-BLOCK or ~<~:>, then *PRINT-CIRCLE*, *PRINT-LEVEL*, and
*PRINT-LENGTH* are all automatically handled correctly.
For example, (format nil "-~1{~A ~A ~A ~A ~A ~}-" '#1=(1 #1# 2 . #1#))
produces "-1 #1=(1 #1# 2 . #1#) 2 1 #1=(1 #1# 2 . #1#) -"
even under PRINT-CIRCLE-STRUCTURE and
(format nil "-~1{~A ~}-" '#1=(1 #1# 2 . #1#))
causes infinite looping. However, in XP,
(format nil "-~:<~W ~W ~W ~W ~W~:>-" '#1=(1 #1# 2 . #1#))
produces "-#1=(1 #1# 2 . #1#)-".
This proves to be very useful when writing pretty printing functions for
things. Note also that ~<~:> supports *PRINT-LEVEL* and *PRINT-LENGTH*
correctly. All the same things can be said about the functional interface
and using PPRINT-LOGICAL-BLOCK rather than traversing a list yourself in
some fashion.
All in all, Waters claims that PRINT-CIRCLE-STRUCTURE covers at most 1/4
of what XP does in support of *PRINT-CIRCLE* and does not cover anything
of what XP does to support *PRINT-LEVEL*, *PRINT-LENGTH*, and
robustness in the face of malformed arguments. These are vital
features for writing printing functions that really work right all the time.
---
It has been suggested that objects should be looked up in pprint dispatch
tables by looking for the most specific type specifier that applies, rather
than looking for the highest priority type specifier that applies. There
are two problems with this. First, it is possible for two type specifiers
to apply without one being more specific than the other. For example,
consider the type specifiers (OR INTEGER FLOAT) and (OR INTEGER RATIONAL)
or the type specifiers (NOT COMPLEX) and (NOT INTEGER).
A much more serious problem is that the only way to tell whether one type
specifier is more specific than another is to use SUBTYPEP. Unfortunately,
even with the clarifications and extensions introduced by X3J13 with regard
to SUBTYPEP in particular and the type system in general, SUBTYPEP is not
very dependable. There are critical situations where it cannot reasonably
work in any implementation (e.g., when a type specifier contains SATISFIES)
and many other situations where it can vary from one implementation to
another. Unfortunately, pprint dispatch tables are expected to contain
type specifiers containing SATISFIES on a regular basis. In addition, the
variability in SUBTYPEP would reduce the portability of user-defined pprint
dispatch tables if dispatching through them depended on SUBTYPEP. All in
all, it seems much better for the pretty printing to rely on priorities
rather than on SUBTYPEP
---
It has been noted by Dave Moon that things would be much more elegant if
SET-PPRINT-DISPATCH could be expressed directly as a CLOS DEFMETHOD for
an appropriate generic function. Dick Waters agrees with this. However,
SET-PPRINT-DISPATCH depends on type specifiers that are more complex than
the ones CLOS deals with and ones that do not have clear subtype/supertype
relationships, compensating for the latter problem by supporting numerical
priorities to disambiguate things. (The defaulting behavior is a key
feature of the pretty printer.) At the very least, this means that
SET-PPRINT-DISPATCH will not fit into CLOS in a simple way.
Given the problems, Moon suggests that "it does seem that right now it
might be best to keep a separate SET-PPRINT-DISPATCH macro, with the
idea that the expansion is implementation-dependent at the moment, but
might some day be changed to be defined to expand into DEFMETHOD. I
haven't looked to see whether any syntactic changes would be appropriate
to make that transition smoother."
(Waters also worries that the overhead needed to locate the right CLOS
method would seriously degrade the pretty printer, because the printer
has to do this for every part of every object printed. This dispatching is
currently done by very fast code that is tuned to take advantage of the
observed distribution of kinds of objects that have special pretty
printers attached to them. Even with this special purpose code,
dispatching takes a significant part of the pretty printer's time.)
---
Dave Moon also comments that it is not good to have something that looks
like a type specifier (i.e., the extended form of the CONS type specifier
used by SET-PPRINT-DISPATCH) and yet is not a real type specifier. He
suggests that we should either amend Common Lisp to accept the extended
form of the CONS type specifier, or stop having SET-PPRINT-DISPATCH use it.
Many of the members of the ad hoc pretty printing subcommittee agree that
(CONS car-type cdr-type) should be made a full fledged type specifier. In
fact it has been suggested that there should be a much wider variety of
ways to talk about lists and their contents than currently exists.
However, the subcommittee feels that it would be going significantly beyond
our charter to change anything about the type system.
Therefore, we opted for the opposite tack of making it very clear in this
proposal that while the function SET-PPRINT-DISPATCH accepts the form
(CONS car-type cdr-type), this form is not a type specifier.
---
To a considerable extent, the design of the XP interface is completely
neutral about the issue of variable- versus fixed- width fonts. In
particular, most of the discussion of how the formating proceeds either
talks about absolute positions of zero or talks about something being
in the same horizontal position as something else. These statements are
all font-independent. (Further, although Waters' current implementation
does not support variable-width fonts, the algorithms used could be
extended to support them without radical changes.)
Nevertheless, there are 8 places where users specify explicit non-zero
lengths: the variables *PRINT-RIGHT-MARGIN* and *PRINT-MISER-WIDTH*,
the numeric arguments to ~T, ~I, and ~/pprint-tabular/ and their associated
functions PPRINT-TAB, PPRINT-INDENT, and PPRINT-TABULAR.
It is proposed that all of these lengths be in the same units, and that
this unit be ems (the length of an "m" in the font currently being used
to output characters to the relevant output stream at the moment that
the command is encountered or a variable is consulted).
It is further proposed that users and implementors be advised to set things
up so that explicit lengths do not have to be specified. For implementors,
this means making streams smart enough that they know how wide they are.
(This avoids the use of *PRINT-RIGHT-MARGIN*.) For users, this means
relying on streams knowing their own widths (which is a good idea for
adaptability in any case) and using ~:I (instead of just ~I) to specify
indentations wherever possible. Further, it should be noted that since
*PRINT-MISER-WIDTH* is essentially heuristic in nature, it does not
matter if its value is only an approximate length and users will only need
to change the value of *PRINT-MISER-WIDTH* in unusual situations.
This leaves only tabbing as an area where explicit lengths have to be
specified on a regular basis. Fortunately, approximate lengths are often
acceptable in this situation as well.
---
The currently proposed syntax for PPRINT-LOGICAL-BLOCK was suggested by
Dave Moon based on his experience with similar constructs at Symbolics.
Waters had originally suggested using a standard binding pair to specify
the underlying stream separately from the variable used to hold the special
stream used within the logical block. However, this invites user mistakes.
The problem is that peculiar results will be obtained if any I/O is sent
directly to the underlying stream from within the logical block. By
arranging the syntax as proposed, the same variable is always used for the
special stream within the logical block as is used for the underlying
stream outside of the block. As a result, it is syntactically impossible
to directly access the underlying stream (unless it is stored in two
different variables) and the user is painlessly saved from making mistakes.
Also, the PPRINT-LOGICAL-BLOCK macro is rendered more compact.
---
Another interesting issue is the interaction between pretty-printing and
*PRINT-READABLY*. Note first, that WITH-STANDARD-IO-SYNTAX binds
*PRINT-PRETTY* to NIL. In general one should expect that maximum machine
readability will be achieved when *PRINT-PRETTY* is nil. However, in
analogy with issue DATA-IO, it is reasonable to require that
PPRINT-DISPATCH functions must obey *PRINT-READABLY*. Note that XP
supports a number of features (e.g., automatic handling of malformed lists)
that are explicitly designed to make it easier to write pprint functions
that reliably produce machine readable output.
---
Steve Haflich comments that the macro FORMATTER provides an opportunity at
some later time to do something about making FORMAT control strings more
readable. Specifically, when using FORMATTER, one should not hesitate to
insert lots of newlines, because they will not waste any space since the
FORMAT string will be converted into a function in any case. Second, it
would be nice to add some feature to format strings that would allow
comments to appear in a FORMAT string. (This is what ~; probably should
have been reserved to mean.)
---
Walter van Roggen notes that the automatic handling of *PRINT-LEVEL* by XP
obsoletes the need for the third argument to print functions for
structures. (This argument was very seldom used in any case.) It might be
appropriate at some future time to get rid of the third argument to print
functions for structures. However, this would not be an upward compatible
change.
---
The pretty printer control interface is included in this proposal for two
key reasons:
(A) Something like the following is probably a key part of the argument
against the pretty-printer-control FORMAT interface in the minds of those
that oppose it. "Including the pretty-printer-control FORMAT interface
might be a gain or a loss for Common Lisp, but nothing could possibly be
lost by not including it. You can always just use FORMAT as it is now, and
you can get pretty printing control with the new functions." However, this
argument is not quite true.
As can be seen in the example below, pretty printer control information has
to be highly intertwined with the rest of the output functions. As a
practical matter, this means that if there is no pretty-printer-control
FORMAT interface you cannot make much if any use of FORMAT when specifying
output that contains pretty-printer-control information. (For instance in
the 20 line example below, there is not even one place where there are two
printing operations in a row that could be combined into a call on FORMAT
if there were no pretty-printer-control FORMAT interface. This means that
there would be no benefit to using FORMAT anywhere in this example.)
The consequence of the above is that, even though pretty printer control
and FORMAT inherently have nothing to do with each other, adding pretty
printer control facilities without adding a pretty-printer-control FORMAT
interface, effectively requires people to choose between FORMAT and pretty
printer control. In order to allow people to separately decide whether
they do or do not want to user FORMAT and do or do not want to get involved
with controlling the pretty printer, you have to provide a
pretty-printer-control FORMAT interface.
This issue is intensified given a pretty printer such as XP that is
within epsilon of just as fast as the ordinary non-pretty printer,
because many people choose to set *PRINT-PRETTY* to T all of the time.
They are therefore naturally led to wanting to specify at least some
pretty printing control information whenever defining a print function
for a structure, or an error message, or in fact essentially any kind
of output. If there is no pretty-printer-control FORMAT interface,
then this would effectively bar the use of FORMAT for these users.
In summary, rather than pushing FORMAT into new territory, the
pretty-printer-control FORMAT interface is required to prevent FORMAT from
sliding into obsolescence.
(B) Although it probably is not convincing to those that do not like
FORMAT, a additional reason for having a pretty-printer-control FORMAT
interface is exactly the same as the reason for having FORMAT at all:
compactness. For example, as shown in the main proposal, the format string:
"~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~1I~@{~↑ ~_~W~}~:>"
is the same as the expression:
(pprint-logical-block (nil list :prefix "(" :suffix ")")
(write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :fill)))
(pprint-indent :block 1)
(loop (pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)
(write (pprint-pop)))))
It is of course also true that a line of FORMAT control string is a
lot harder to read than a line of Lisp code. However, FORMAT has
become a permanent fixture of Common Lisp, because a line of FORMAT
control string is a lot easier to read and work with than 20 lines of
Lisp code.
(C) It should also be noted that the way the XP proposal was first written
up made the FORMAT interface look a lot more complex than it is. Only six
things are being added. Two of these just fix problems with FORMAT and do
not have anything to do with pretty printing. Of the remaining four, three
are very simple. Only ~<...~:> could be called complex.
~A and ~S both force the value of *PRINT-ESCAPE*. ~W is needed in
order to write FORMAT strings that obey *PRINT-ESCAPE*.
~/.../ restores (in a simplified form) a feature of FORMAT that was
lost in the first version of Common Lisp. A number of people have
commented that this is something that they like, having nothing to do
with pretty printing. (Note that ~/PPRINT-LINEAR/, ~/PPRINT-FILL/,
and ~/PPRINT-TABULAR/ are not new directives, they are just a
consequence of the fact that ~/.../ can call the functions
PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR.)
[end of part one of PRETTY-PRINT-INTERFACE:XP]
∂16-Aug-89 2002 X3J13-mailer PRETTY-PRINT-INTERFACE:XP version 5, part 2
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 89 20:01:13 PDT
Received: from MERLIN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 246209; Mon 7-Aug-89 12:16:47 EDT
Date: Mon, 7 Aug 89 12:16 EDT
From: Richard C. Waters <dick@AI.MIT.EDU>
Subject: PRETTY-PRINT-INTERFACE:XP version 5, part 2
To: x3j13@sail.stanford.edu
Message-ID: <19890807161633.2.DICK@MERLIN.AI.MIT.EDU>
THE ISSUE DESCRIBED HERE IS TOO LARGE TO FIT IN A SINGLE MESSAGE. AS A
RESULT, IT IS DIVIDED INTO TWO PARTS, SENT IN TWO MESSAGES. THIS IS PART
TWO, WHICH IS THE FULL DETAILED PROPOSAL ITSELF. THE STANDARD
CLEANUP-ISSUE-STYLE DESCRIPTION IS IN PART 1 AND CONTAINS SIGNIFICANT
AMOUNTS OF ADDITIONAL COMMENTARY.
--------------------
Proposal (PRETTY-PRINT-INTERFACE:XP):
Full description of XP accompanying version 5 of the proposal
--------------------
Pretty Printing
Richard C. Waters
Pretty printing has traditionally been a black box process, displaying
program code using a set of fixed layout rules. Its utility can be greatly
enhanced by opening it up to user control.
By providing direct access to the mechanisms within the pretty printer that
make dynamic decisions about layout, the macros and functions
PPRINT-LOGICAL-BLOCK, PPRINT-NEWLINE, and PPRINT-INDENT make it possible to
specify pretty printing layout rules as a part of any function that
produces output. They also make it very easy for the detection of
circularity and sharing, and abbreviation based on length and nesting depth
to be supported by the function. The function SET-PPRINT-DISPATCH makes it
possible to associate a user-defined pretty printing function with any type
of object. Together, these facilities enable users to redefine the way
code is displayed and allow the full power of pretty printing to be applied
to complex combinations of data structures.
Pretty Printing Control Variables
*PRINT-RIGHT-MARGIN* [variable]
A primary goal of pretty printing is to keep the output between a pair of
margins. The left margin is set at the column where the output begins. If
this cannot be determined, the left margin is set to zero.
When *PRINT-RIGHT-MARGIN* is not NIL, it specifies the right margin to use
when making layout decisions. When *PRINT-RIGHT-MARGIN* is NIL (the
initial value), the right margin is set at the maximum line length that can
be displayed by the output stream without wraparound or truncation. If
this cannot be determined, the right margin is set to an implementation
dependent value.
To allow for the possibility of variable-width fonts, *PRINT-RIGHT-MARGIN*
is interpreted in terms of ems---the length of an "m" in the font being
used to display characters on the relevant output stream at the moment when
the variables are consulted.
*PRINT-MISER-WIDTH* [variable]
If *PRINT-MISER-WIDTH* is not NIL, the pretty printer switches to a compact
style of output (called miser style) whenever the width available for
printing a substructure is less than or equal to *PRINT-MISER-WIDTH* ems.
The initial value of *PRINT-MISER-WIDTH* is implementation-dependent.
*PRINT-LINES* [variable]
When given a value other than its initial value of NIL, *PRINT-LINES*
limits the number of output lines produced when something is pretty
printed. If an attempt is made to go beyond *PRINT-LINES* lines, "
.." is printed at the end of the last line followed by all of the
suffixes (closing delimiters) that are pending to be printed.
(let ((*print-right-margin* 25) (*print-lines* 3))
(pprint '(progn (setq a 1 b 2 c 3 d 4))))
(PROGN (SETQ A 1
B 2
C 3 ..))
(The symbol ".." is printed out to ensure that a reader error will occur
if the output is later read. A symbol different than "..." is used to
indicate that a different kind of abbreviation has occurred.)
*PRINT-PPRINT-DISPATCH* [variable]
When *PRINT-PRETTY* is not NIL, printing is controlled by the `pprint
dispatch table' stored in the variable *PRINT-PPRINT-DISPATCH*. The
initial value of *PRINT-PPRINT-DISPATCH* is implementation dependent and
causes traditional pretty printing of Lisp code. The last section of this
proposal explains how the contents of this table can be changed.
The function WRITE accepts keyword arguments :PPRINT-DISPATCH,
:RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to
*PRINT-PPRINT-DISPATCH*, *PRINT-RIGHT-MARGIN*, *PRINT-LINES*, and
*PRINT-MISER-WIDTH*.
Dynamic Control of the Arrangement of Output
The following functions and macros support precise control of what should
be done when a piece of output is too large to fit in the space available.
Three concepts underlie the way these operations work---`logical blocks',
`conditional newlines', and `sections'. Before proceeding further, it is
important to define these terms.
The first line of Figure 1 shows a schematic piece of output. The
characters in the output are represented by "-"s. The positions of
conditional newlines are indicated by digits. The beginnings and ends of
logical blocks are indicated by "<" and ">" respectively.
The output as a whole is a logical block and the outermost section. This
section is indicated by the 0's on the second line of Figure 1. Logical
blocks nested within the output are specified by the macro
PPRINT-LOGICAL-BLOCK. Conditional newline positions are specified by calls
on PPRINT-NEWLINE. Each conditional newline defines two sections (one
before it and one after it) and is associated with a third (the section
immediately containing it).
The section after a conditional newline consists of: all the output up to,
but not including, (a) the next conditional newline immediately contained
in the same logical block; or if (a) is not applicable, (b) the next
newline that is at a lesser level of nesting in logical blocks; or if (b)
is not applicable, (c) the end of the output.
The section before a conditional newline consists of: all the output back
to, but not including, (a) the previous conditional newline that is
immediately contained in the same logical block; or if (a) is not
applicable, (b) the beginning of the immediately containing logical block.
The last four lines in Figure 1 indicate the sections before and after the
four conditional newlines.
The section immediately containing a conditional newline is the shortest
section that contains the conditional newline in question. In Figure 1,
the first conditional newline is immediately contained in the section
marked with 0's, the second and third conditional newlines are immediately
contained in the section before the fourth conditional newline, and the
fourth conditional newline is immediately contained in the section after
the first conditional newline.
<-1---<--<--2---3->--4-->->
000000000000000000000000000
11 111111111111111111111111
22 222
333 3333
44444444444444 44444
Figure 1: Example of logical blocks, conditional newlines, and sections.
Whenever possible, the pretty printer displays the entire contents of a
section on a single line. However, if the section is too long to fit in
the space available, line breaks are inserted at conditional newline
positions within the section.
PPRINT-NEWLINE kind &OPTIONAL (stream *STANDARD-OUTPUT*) [Function]
STREAM (which defaults to *STANDARD-OUTPUT*) follows the standard
conventions for stream arguments to printing functions (i.e., NIL stands
for *STANDARD-OUTPUT* and T stands for *TERMINAL-IO*). The KIND argument
specifies the style of conditional newline. It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY. An error is signalled if any other value is
supplied. If STREAM is a pretty printing stream created by
PPRINT-LOGICAL-BLOCK, a line break is inserted in the output when the
appropriate condition below is satisfied. Otherwise, PPRINT-NEWLINE has no
effect. The value NIL is always returned.
If KIND is :LINEAR, it specifies a `linear-style' conditional newline. A
line break is inserted if and only if the immediately containing section
cannot be printed on one line. The effect of this is that line breaks are
either inserted at every linear-style conditional newline in a logical
block or at none of them.
If KIND is :MISER, it specifies a `miser-style' conditional newline. A
line break is inserted if and only if the immediately containing section
cannot be printed on one line and miser style is in effect in the
immediately containing logical block. The effect of this is that
miser-style conditional newlines act like linear-style conditional
newlines, but only when miser style is in effect. Miser style is in effect
for a logical block if and only if the starting position of the logical
block is less than or equal to *PRINT-MISER-WIDTH* from the right margin.
If KIND is :FILL, it specifies a `fill-style' conditional newline. A line
break is inserted if and only if either (a) the following section cannot be
printed on the end of the current line, (b) the preceding section was not
printed on a single line, or (c) the immediately containing section cannot
be printed on one line and miser style is in effect in the immediately
containing logical block. If a logical block is broken up into a number of
subsections by fill-style conditional newlines, the basic effect is that
the logical block is printed with as many subsections as possible on each
line. However, if miser style is in effect, fill-style conditional
newlines act like linear-style conditional newlines.
If KIND is :MANDATORY, it specifies a `mandatory-style' conditional
newline. A line break is always inserted. This implies that none of the
containing sections can be printed on a single line and will therefore
trigger the insertion of line breaks at linear-style conditional newlines
in these sections.
When a line break is inserted by any type of conditional newline, any
blanks that immediately precede the conditional newline are omitted from
the output and indentation is introduced at the beginning of the next line.
By default, the indentation causes the following line to begin in the same
horizontal position as the first character in the immediately containing
logical block. (The indentation can be changed via PPRINT-INDENT.)
There are a variety of ways unconditional newlines can be introduced into
the output (e.g., via TERPRI or by printing a string containing a newline
character). As with mandatory conditional newlines, this prevents any of
the containing sections from being printed on one line. In general, when
an unconditional newline is encountered, it is printed out without
suppression of the preceding blanks and without any indentation following
it. However, if a per-line prefix has been specified (see
PPRINT-LOGICAL-BLOCK), this prefix will always be printed no matter how a
newline originates.
PPRINT-LOGICAL-BLOCK (stream-symbol list [Macro]
&KEY :prefix :per-line-prefix :suffix)
&BODY body
This macro causes printing to be grouped into a logical block. The value
NIL is always returned.
STREAM-SYMBOL must be a symbol. If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*. If it is T, it is treated the same as if
it were *TERMINAL-IO*. The run-time value of STREAM-SYMBOL must be a
stream (or NIL standing for *STANDARD-OUTPUT* or T standing for *TERMINAL-IO*).
The logical block is printed into this destination stream.
The BODY can contain any arbitrary Lisp forms. Within the BODY,
STREAM-SYMBOL (or *STANDARD-OUTPUT* if STREAM-SYMBOL is NIL, or
*TERMINAL-IO* if STREAM-SYMBOL is T) is bound to a `pretty printing' stream
that supports decisions about the arrangement of output and then forwards
the output to the destination stream. All the standard printing functions
(e.g., WRITE, PRINC, TERPRI) can be used to print output the pretty
printing stream created by PPRINT-LOGICAL-BLOCK. All and only the output
sent to this pretty printing stream is treated as being in the logical
block.
PPRINT-LOGICAL-BLOCK and the pretty printing stream it creates have dynamic
extent. It is undefined what happens if output is attempted outside of
this extent to the pretty printing stream created. It is unspecified what
happens if, within this extent, any output is sent directly to the
underlying destination stream.
The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that (at
run time) evaluate to strings. :SUFFIX (which defaults to the null string)
specifies a suffix that is printed just after the logical block. The
:PREFIX and :PRE-LINE-PREFIX arguments are mutually exclusive. If neither
:PREFIX or :PER-LINE-PREFIX is specified, a :PREFIX of the null string is
assumed. :PREFIX specifies a prefix to be printed before the beginning of
the logical block. :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block. An
error is signalled if :PREFIX and :PRE-LINE-PREFIX are both used or if the
:SUFFIX, :PREFIX, or :PER-LINE-PREFIX do not evaluate to strings.
LIST is interpreted as being a list that BODY is responsible for
printing. (See PPRINT-EXIT-IF-LIST-EXHAUSTED and PPRINT-POP.) If
LIST does not (at run time) evaluate to a list, it is printed using
WRITE. (This makes it easier to write printing functions that are
robust in the face of malformed arguments.) If *PRINT-CIRCLE* (and
possibly *PRINT-SHARED*) is not NIL and LIST is a circular (or shared)
reference to a cons, then an appropriate #n# marker is printed. (This
makes it easy to write printing functions that provide full support
for circularity and sharing abbreviation.) If *PRINT-LEVEL* is not
NIL and the logical block is at a dynamic nesting depth of greater
than *PRINT-LEVEL* in logical blocks, # is printed. (This makes easy
to write printing functions that provide full support for depth
abbreviation.)
If either of the three conditions above occurs, the indicated output is
printed on STREAM-SYMBOL and the BODY is skipped along with the printing of
the :PREFIX and :SUFFIX. (If the BODY is not responsible for printing a
list, then the first two tests above can be turned off by supplying NIL for
the LIST argument.)
In addition to the LIST argument of PPRINT-LOGICAL-BLOCK, the arguments of
the standard printing functions such as WRITE, PRINT, PPRINT, PRINT1, and
PPRINT, as well as the arguments of the standard FORMAT directives such as
~A, ~S, (and ~W) are all checked (when necessary) for circularity and
sharing. However, such checking is not applied to the arguments of the
functions WRITE-LINE, WRITE-STRING, and WRITE-CHAR or to the literal text
output by FORMAT. A consequence of this is that you must use one of the
latter functions if you want to print some literal text in the output that
is not supposed to be checked for circularity or sharing. (See the
examples below.)
----------------------------------------
Implementation note: detection of circularity and sharing is supported by
the pretty printer by in essence performing requested output twice.
On the first pass, circularities and sharing are detected and the
actual outputting of characters is suppressed. On the second pass, the
appropriate #n= and #n# markers are inserted and characters are output.
A consequence of this two-pass approach to the detection of circularity and
sharing is that the BODY of a PPRINT-LOGICAL-BLOCK must not perform any
side-effects on the surrounding environment. This includes not modifying
any variables that are bound outside of its scope. Obeying this
restriction is facilitated by using PPRINT-POP, instead of an ordinary POP
when traversing a list being printed by the BODY of a
PPRINT-LOGICAL-BLOCK.)
----------------------------------------
PPRINT-EXIT-IF-LIST-EXHAUSTED [Macro]
PPRINT-EXIT-IF-LIST-EXHAUSTED tests whether or not the LIST passed to
PPRINT-LOGICAL-BLOCK has been exhausted (see PPRINT-POP). If this list has
been reduced to NIL, PPRINT-EXIT-IF-LIST-EXHAUSTED terminates the execution
of the immediately containing PPRINT-LOGICAL-BLOCK except for the printing
of the suffix. Otherwise PPRINT-EXIT-IF-LIST-EXHAUSTED returns NIL. An
error message is issued if PPRINT-EXIT-IF-LIST-EXHAUSTED is used anywhere
other than syntactically nested within a call on PPRINT-LOGICAL-BLOCK. It
is undefined what happens if PPRINT-POP is executed outside of the dynamic
extent of this PPRINT-LOGICAL-BLOCK.
PPRINT-POP [Macro]
PPRINT-POP pops elements one at a time off the LIST passed to
PPRINT-LOGICAL-BLOCK obeying *PRINT-LENGTH*, *PRINT-CIRCLE*, and
*PRINT-SHARED*. An error message is issued if it is used anywhere
other than syntactically nested within a call on PPRINT-LOGICAL-BLOCK.
It is undefined what happens if PPRINT-POP is executed outside of the
dynamic extent of this PPRINT-LOGICAL-BLOCK.
Each time PPRINT-POP is called, it pops the next value off the LIST
passed to PPRINT-LOGICAL-BLOCK and returns it. However, before doing
this, it performs three tests. If the remaining list is not a list
(i.e., a cons or NIL), ". " is printed followed by the remaining list.
(This makes it easier to write printing functions that are robust in
the face of malformed arguments.) If *PRINT-LENGTH* is NIL and
PPRINT-POP has already been called *PRINT-LENGTH* times within the
immediately containing logical block, "..." is printed. (This makes
it easy to write printing functions that properly handle
*PRINT-LENGTH*.) If *PRINT-CIRCLE* (and possibly *PRINT-SHARED*) is
not NIL, and the remaining list is a circular (or shared) reference,
then ". " is printed followed by an appropriate #n# marker. (This
catches instances of cdr circularity and sharing in lists.)
If either of the three conditions above occurs, the indicated output is
printed on the pretty printing stream created by the immediately containing
PPRINT-LOGICAL-BLOCK and the execution of the immediately containing
PPRINT-LOGICAL-BLOCK is terminated except for the printing of the suffix.
If PPRINT-LOGICAL-BLOCK is given a LIST argument of NIL---because it is not
processing a list---PPRINT-POP can still be used to obtain support for
*PRINT-LENGTH* (see the example function PPRINT-VECTOR below). In this
situation, the first and third tests above are disabled and
PPRINT-POP always returns NIL.
PPRINT-INDENT relative-to n &OPTIONAL (stream *STANDARD-OUTPUT*) [Function]
PPRINT-INDENT specifies the indentation to use in a logical block. STREAM
(which defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. N specifies the indentation in
ems. If RELATIVE-TO is :BLOCK, the indentation is set to the horizontal
position of the first character in the block plus N ems. If RELATIVE-TO is
:CURRENT, the indentation is set to the current output position plus N ems.
(For robustness in the face of variable-width fonts, it is advisable to use
:CURRENT with an N of zero whenever possible.)
N can be negative; however, the total indentation cannot be moved left of
the beginning of the line or left of the end of the rightmost per-line
prefix. Changes in indentation caused by PPRINT-INDENT do not take
effect until after the next line break. In addition, in miser mode all
calls on PPRINT-INDENT are ignored, forcing the lines corresponding to the
logical block to line up under the first character in the block.
An error is signalled if a value other than :BLOCK or :CURRENT is supplied
for RELATIVE-TO. If STREAM is a pretty printing stream created by
PPRINT-LOGICAL-BLOCK, PPRINT-INDENT sets the indentation in the innermost
dynamically enclosing logical block. Otherwise, PPRINT-INDENT has no
effect. The value NIL is always returned.
PPRINT-TAB kind colnum colinc &OPTIONAL (stream *STANDARD-OUTPUT*) [function]
PPRINT-TAB specifies tabbing as performed by the standard FORMAT directive
~T. STREAM (which defaults to *STANDARD-OUTPUT*) follows the standard
conventions for stream arguments to printing functions. The arguments
COLNUM and COLINC correspond to the two parameters to ~T and are in terms
of ems. The KIND argument specifies the style of tabbing. It must be one
of :LINE (tab as by ~T) :SECTION (tab as by ~T, but measuring horizontal
positions relative to the start of the dynamically enclosing section),
:LINE-RELATIVE (tab as by ~@T), or :SECTION-RELATIVE (tab as by ~@T, but
measuring horizontal positions relative to the start of the dynamically
enclosing section). An error is signalled if any other value is supplied
for KIND. If STREAM is a pretty printing stream created by
PPRINT-LOGICAL-BLOCK, tabbing is performed. Otherwise, PPRINT-TAB has no
effect. The value NIL is always returned.
PPRINT-FILL STREAM LIST &OPTIONAL (COLON? T) ATSIGN? [function]
PPRINT-LINEAR STREAM LIST &OPTIONAL (COLON? T) ATSIGN? [function]
PPRINT-TABULAR STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16) [function]
These three functions specify particular ways of pretty printing lists.
STREAM follows the standard conventions for stream arguments to printing
functions. Each function prints parentheses around the output if and only
if COLON? (default T) is not NIL. Each function ignores its ATSIGN?
argument and returns NIL. (These two arguments are included in this way so
that these functions can be used via ~/.../ and as SET-PPRINT-DISPATCH
functions as well as directly.) Each function handles abbreviation and the
detection of circularity and sharing correctly, and uses WRITE to print
LIST when given a non-list argument.
The function PPRINT-LINEAR prints a list either all on one line, or with
each element on a separate line. The function PPRINT-FILL prints a list
with as many elements as possible on each line. The function
PPRINT-TABULAR is the same as PPRINT-FILL except that it prints the
elements so that they line up in columns. This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.
---
As an example of the interaction of logical blocks, conditional newlines,
and indentation, consider the function SIMPLE-PPRINT-DEFUN below. This
function prints out lists whose cars are DEFUN in the standard way assuming
that the list has exactly length 4.
(defun simple-pprint-defun (*standard-output* list)
(pprint-logical-block (*standard-output* list :prefix "(" :suffix ")")
(write (first list))
(write-char #\space)
(pprint-newline :miser)
(pprint-indent :current 0)
(write (second list))
(write-char #\space)
(pprint-newline :fill)
(write (third list))
(pprint-indent :block 1)
(write-char #\space)
(pprint-newline :linear)
(write (fourth list))))
Suppose that one evaluates the following:
(simple-pprint-defun *standard-output* '(defun prod (x y) (* x y)))
If the line width available is greater than or equal to 26, then all of the
output appears on one line. If the line width available is reduced to 25,
a line break is inserted at the linear-style conditional newline before the
expression (* X Y), producing the output shown. The (PPRINT-INDENT :BLOCK 1)
causes (* X Y) to be printed at a relative indentation of 1 in the logical block.
(DEFUN PROD (X Y)
(* X Y))
If the line width available is 15, a line break is also inserted at the
fill style conditional newline before the argument list. The call on
(PPRINT-INDENT :CURRENT 0) causes the argument list to line up under the
function name.
(DEFUN PROD
(X Y)
(* X Y))
If *PRINT-MISER-WIDTH* were greater than or equal to 14, the example output
above would have been as follows, because all indentation changes are
ignored in miser mode and line breaks are inserted at miser-style
conditional newlines.
(DEFUN
PROD
(X Y)
(* X Y))
---
As an example of a per-line prefix, consider that evaluating the following
produces the output shown with a line width of 20 and *PRINT-MISER-WIDTH*
of NIL.
(pprint-logical-block (*standard-output* nil :per-line-prefix ";;; ")
(simple-pprint-defun *standard-output* '(defun prod (x y) (* x y))))
;;; (DEFUN PROD
;;; (X Y)
;;; (* X Y))
---
As a more complex (and realistic) example, consider the function PPRINT-LET
below. This specifies how to print a LET in the standard style. It is more
complex than the example above, because it has to deal with nested structure.
Also, unlike the example above it contains complete code to readably print any
possible list that begins with the symbol LET. The outermost
PPRINT-LOGICAL-BLOCK handles the printing of the input list as a whole and
specifies that parentheses should be printed in the output. The second
PPRINT-LOGICAL-BLOCK handles the list of binding pairs. Each pair in the list
is itself printed by the innermost PPRINT-LOGICAL-BLOCK. (A LOOP is used
instead of merely decomposing the pair into two elements so that readable
output will be produced no matter whether the list corresponding to the pair
has one element, two elements, or (being malformed) has more than two
elements.) A space and a fill-style conditional newline are placed after
each pair except the last. The loop at the end of the topmost
PPRINT-LOGICAL-BLOCK prints out the forms in the body of the LET separated by
spaces and linear-style conditional newlines.
(defun pprint-let (*standard-output* list)
(pprint-logical-block (nil list :prefix "(" :suffix ")")
(write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (pprint-logical-block (nil (pprint-pop) :prefix "(" :suffix ")")
(pprint-exit-if-list-exhausted)
(loop (write (pprint-pop))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)))
(pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :fill)))
(pprint-indent :block 1)
(loop (pprint-exit-if-list-exhausted)
(write-char #\space)
(pprint-newline :linear)
(write (pprint-pop)))))
Suppose that one evaluates the following with *PRINT-LEVEL* 4, and
*PRINT-CIRCLE* T.
(pprint-let *standard-output*
'#1=(let (x (*print-length* (f (g 3)))
(z . 2) (k (car y)))
(setq x (sqrt z)) #1#))
If the line length is greater than or equal to 77, the output produced
appears on one line. However, if the line length is 76, line breaks are
inserted at the linear-style conditional newlines separating the forms in
the body and the output below is produced. Note that, the degenerate
binding pair X is printed readably even though it fails to be a list; a
depth abbreviation marker is printed in place of (G 3); the binding pair
(Z . 2) is printed readably even though it is not a proper list; and
appropriate circularity markers are printed.
#1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
If the line length is reduced to 35, a line break is inserted at one of the
fill-style conditional newlines separating the binding pairs.
#1=(LET (X (*PRINT-PRETTY* (F #))
(Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
Suppose that the line length is further reduced to 22 and *PRINT-LENGTH* is
set to 3. In this situation, line breaks are inserted after both the first
and second binding pairs. In addition, the second binding pair is itself
broken across two lines. Clause (b) of the description of fill-style
conditional newlines prevents the binding pair (Z . 2) from being printed
at the end of the third line. Note that the length abbreviation hides the
circularity from view and therefore the printing of circularity markers
disappears.
(LET (X
(*PRINT-LENGTH*
(F #))
(Z . 2) ...)
(SETQ X (SQRT Z))
...)
---
The function PPRINT-TABULAR could be defined as follows.
(defun pprint-tabular (s list &optional (colon? T) atsign? (tabsize nil))
(declare (ignore atsign?))
(when (null tabsize) (setq tabsize 16))
(pprint-logical-block (s list :prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(pprint-exit-if-list-exhausted)
(loop (write (pprint-pop) :stream s)
(pprint-exit-if-list-exhausted)
(write-char #\space s)
(pprint-tab :section-relative 0 tabsize s)
(pprint-newline :fill s))))
Evaluating the following with a line length of 25 produces the output shown.
(princ "Roads ")
(pprint-tabular *standard-output* '(elm main maple center) nil nil 8)
Roads ELM MAIN
MAPLE CENTER
---
The function below prints a vector using #(...) notation.
(defun pprint-vector (*standard-output* v)
(pprint-logical-block (nil nil :prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (pprint-pop)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(pprint-newline :fill))))))
Evaluating the following with a line length of 15 produces the output shown.
(pprint-vector *standard-output* '#(12 34 567 8 9012 34 567 89 0 1 23))
#(12 34 567 8
9012 34 567
89 0 1 23)
Format Directive Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through the functions above. However, an
additional interface is provided via a set of new format directives.
This is done, because as shown by the examples in this section and the
next, FORMAT strings are typically a much more compact way to specify
pretty printing. In addition, without such an interface, one would have to
abandon the use of FORMAT when interacting with the pretty printer.
~W [format directive]
WRITE -- An arg, any Lisp object, is printed obeying every printer control
variable (as by WRITE). In addition, ~W interacts correctly with depth
abbreviation, by not resetting the depth counter to zero. ~W does not
accept parameters. If given the colon modifier, ~W binds *PRINT-PRETTY* to
T. If given the atsign modifier, ~W binds *PRINT-LEVEL* and *PRINT-LENGTH*
to NIL.
~W provides automatic support for the detection of circularity and
sharing. If *PRINT-CIRCLE* (and possibly *PRINT-SHARED*) is not NIL
and ~W is applied to an argument that is a circular (or shared)
reference, an appropriate #n# marker is inserted in the output instead
of printing the argument.
~_ [format directive]
CONDITIONAL-NEWLINE -- Without any modifiers, ~_ is the same as
(PPRINT-NEWLINE :LINEAR). ~@_ is the same as (PPRINT-NEWLINE :MISER).
~:_ is the same as (PPRINT-NEWLINE :FILL). ~:@_ is the same as
(PPRINT-NEWLINE :MANDATORY).
~<...~:> [format directive]
LOGICAL BLOCK -- If ~:> is used to terminate a ~<...~>, the directive
is equivalent to a call on PPRINT-LOGICAL-BLOCK. The FORMAT argument
corresponding to the ~<...~:> directive is treated in the same way as
the LIST argument to PPRINT-LOGICAL-BLOCK, thereby providing automatic
support for non-list arguments and the detection of circularity,
sharing, and depth abbreviation. The portion of the FORMAT control
string nested within the ~<...~:> specifies the :PREFIX (or
:PER-LINE-PREFIX), :suffix}, and body of the PPRINT-LOGICAL-BLOCK.
The FORMAT string portion enclosed by ~<...~:> can be divided into
segments ~<prefix~;body~;suffix~:> by ~; directives. If the first
section is terminated by ~@;, it specifies a per-line prefix rather
than a simple prefix. The prefix and suffix cannot contain FORMAT
directives. An error is signalled if either the prefix or suffix
fails to be a constant string or if the enclosed portion is divided
into more than three segments.
If the enclosed portion is divided into only two segments, the suffix
defaults to the null string. If the enclosed portion consists of only
a single segment, both the prefix and the suffix default to the null
string. If the colon modifier is used (i.e., ~:<...~:>), the prefix
and suffix default to "(" and ")" (respectively) instead of the null
string.
The body segment can be any arbitrary FORMAT control string. This
FORMAT control string is applied to the elements of the list
corresponding to the ~<...~:> directive as a whole. Elements are
extracted from this list using PPRINT-POP, thereby providing automatic
support for malformed lists, and the detection of circularity,
sharing, and length abbreviation. Within the body segment, ~↑ acts
like PPRINT-EXIT-IF-LIST-EXHAUSTED.
~<...~:> supports a feature not supported by PPRINT-LOGICAL-BLOCK. If
~:@> is used to terminate the directive (i.e., ~<...~:@>), then a
fill-style conditional newline is automatically inserted after each
group of blanks immediately contained in the body (except for blanks
after a ~<newline> directive). This makes it easy to achieve the
equivalent of paragraph filling.
If the atsign modifier is used with ~<...~:>, the entire remaining
argument list is passed to the directive as its argument. All of the
remaining arguments are always consumed by ~@<...~:>, even if they are
not all used by the FORMAT string nested in the directive. Other than
the difference in its argument, ~@<...~:> is exactly the same as
~<...~:> except that " . #n#" is printed if circularity or sharing has
to be indicated for its argument as a whole.
To a considerable extent, the basic form of the directive ~<...~> is
incompatible with the dynamic control of the arrangement of output by
~W, ~_, ~<...~:>, ~I, and ~:T. As a result, an error is signalled if
any of these directives is nested within ~<...~>. Beyond this, an
error is also signalled if the ~<...~:;...~> form of ~<...~> is used
in the same FORMAT string with ~W, ~_, ~<...~:>, ~I, or ~:T.
~I [format directive]
INDENT -- ~nI is the same as (PPRINT-INDENT :BLOCK N).
~n:I is the same as (PPRINT-INDENT :CURRENT N). In both cases, N defaults
to zero, if it is omitted.
~:T [format directive]
TABULATE -- If the colon modifier is used with the ~T directive, the
tabbing computation is done relative to the horizontal position where the
section immediately containing the directive begins, rather than with
respect to a horizontal position of zero. The numerical parameters are
both interpreted as being in units of ems and both default to 1.
~n,m:T is the same as (PPRINT-TAB :SECTION N M).
~n,m:@T is the same as (PPRINT-TAB :SECTION-RELATIVE N M).
~/name/ [format directive]
CALL FUNCTION -- User defined functions can be called from within a FORMAT
string by using the directive ~/name/. The colon modifier, the atsign
modifier, and arbitrarily many parameters can be specified with the ~/name/
directive. NAME can be any arbitrary string that does not contain a "/".
All of the characters in NAME are treated as if they were upper case. If
NAME contains a ":" or "::", then everything up to but not including the
first ":" or "::" is taken to be a string that names a package. Everything
after the first ":" or "::" (if any) is taken to be a string that names a
symbol. The function corresponding to a ~/name/ directive is obtained by
looking up the symbol that has the indicated name in the indicated package.
If NAME does not contain a ":" or "::", then the whole name string is
looked up in the USER package.
When a ~/name/ directive is encountered, the indicated function is called
with four or more arguments. The first four arguments are: the output
stream, the FORMAT argument corresponding to the directive, the value T if
the colon modifier was used (NIL otherwise), and the value T if the atsign
modifier was used (NIL otherwise). The remaining arguments consist of any
parameters specified with the directive. The function should print the
argument appropriately. Any values returned by the function are ignored.
The three functions PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR are
specifically designed so that they can be called by ~/.../ (i.e.,
~/PPRINT-LINEAR/, ~/PPRINT-FILL/, and ~/PPRINT-TABULAR/). In particular
they take colon and atsign arguments.
---
As examples of the convenience of specifying pretty printing with FORMAT
strings, consider that the first two functions used as examples in the last
section can be compactly defined as follows. The function PPRINT-VECTOR
cannot be defined using FORMAT, because the data structure it traverses is
not a list. The function PPRINT-TABULAR is inconvenient to define using
FORMAT, because of the need to pass its TABSIZE argument through to a ~:T
directive nested within an iteration over a list.
(defun simple-pprint-defun (*standard-output* list)
(format T "~:<~W ~@_~:I~W ~:_~W~1I ~_~W~:>" list))
(defun pprint-let (*standard-output* list)
(format T "~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~1I~@{~↑ ~_~W~}~:>" list))
Compiling Format Control Strings
The control strings used by FORMAT are essentially programs that perform
printing. The macro FORMATTER provides the efficiency of using a compiled
function for printing without losing the compactness of FORMAT control
strings.
FORMATTER control-string [macro]
CONTROL-STRING must be a literal string. An error is signalled if
CONTROL-STRING is not a valid FORMAT control string. The macro FORMATTER
expands into an expression of the form (FUNCTION (LAMBDA (STREAM &REST
ARGS) ...)) that does the printing specified by CONTROL-STRING. The
LAMBDA created accepts an output stream as its first argument and zero or
more data values as its remaining arguments. The value returned by the
LAMBDA is the tail (if any) of the data values that are not printed out by
CONTROL-STRING. (E.g., if the CONTROL-STRING is "~A~A" the CDDR (if any)
of the data values is returned.)
For instance: (formatter "~%~2@{~S, ~}") is equivalent to
#'(lambda (stream &rest args)
(terpri stream)
(dotimes (n 2)
(if (null args) (return nil))
(prin1 (pop args) stream)
(write-string ", " stream))
args)
In support of the above, FORMAT is extended so that it accepts functions as
its second argument as well as strings. When a function is provided, it
must be a function of the form created by FORMATTER. The function is called
with the appropriate output stream as its first argument and the data
arguments to FORMAT as its remaining arguments. The function should
perform whatever output is necessary and return the unused tail of the
arguments (if any). The directives ~? and ~{~} with no body are also
extended so that they accept functions as well as control strings.
Every other standard function that takes a FORMAT string as an argument
(e.g., ERROR and WARN) are also extended so that they can accept functions
of the form above instead.
Pretty Print Dispatch Tables
When *PRINT-PRETTY* is not NIL, the pprint dispatch table in the variable
*PRINT-PPRINT-DISPATCH* controls how objects are printed. The information
in this table takes precedence over all other mechanisms for specifying how
to print objects. In particular, it overrides user-defined PRINT-OBJECT
methods and print functions for structures. However, if there is no
specification for how to pretty print a particular kind of object, it is then
printed using the standard mechanisms as if *PRINT-PRETTY* were NIL.
Pprint dispatch tables are mappings from keys to pairs of values. The keys
are type specifiers. The values are functions and numerical priorities.
Basic insertion and retrieval is done based on the keys with the equality
of keys being tested by EQUAL. The function to use when pretty printing an
object is chosen by finding the highest priority function from
*PRINT-PPRINT-DISPATCH* that is associated with a type specifier that
matches the object.
COPY-PPRINT-DISPATCH &optional (table *PRINT-PPRINT-DISPATCH*) [function]
A copy is made of TABLE, which defaults to the current pprint dispatch
table. If TABLE is NIL, a copy is returned of the initial value of
*PRINT-PPRINT-DISPATCH*.
PPRINT-DISPATCH object &optional (table *PRINT-PPRINT-DISPATCH*) [function]
This retrieves the highest priority function from a pprint table that is
associated with a type specifier in the table that matches OBJECT. The
function is chosen by finding all the type specifiers in TABLE that match
the object and selecting the highest priority function associated with any
of these type specifiers. If there is more than one highest priority
function, an arbitrary choice is made. If no type specifiers match the
object, a function is returned that prints object with *PRINT-PRETTY* bound
to NIL.
As a second return value, PPRINT-DISPATCH returns a flag that is T if a
matching type specifier was found in TABLE and NIL if not.
TABLE (which defaults to *PRINT-PPRINT-DISPATCH*) must be a pprint dispatch
table. TABLE can be NIL, in which case retrieval is done in the initial
value of *PRINT-PPRINT-DISPATCH*.
When *PRINT-PRETTY* is T, (WRITE OBJECT :STREAM S) is equivalent to
(FUNCALL (PPRINT-DISPATCH OBJECT) S OBJECT).
SET-PPRINT-DISPATCH type-specifier function [function]
&optional (priority 0) (table *PRINT-PPRINT-DISPATCH*)
This puts an entry into a pprint dispatch table and returns NIL.
TYPE-SPECIFIER must be a valid type specifier and is the key of the entry.
The first action of SET-PPRINT-DISPATCH is to remove any pre-existing entry
associated with TYPE-SPECIFIER. This guarantees that there will never be
two entries associated with the same type specifier in a given pprint
dispatch table. Equality of type specifiers is tested by EQUAL.
Two values are associated with each type specifier in a pprint dispatch
table: a function and a priority. FUNCTION must accept two arguments: the
stream to send output to and the object to be printed. FUNCTION should
pretty print the object on the stream. FUNCTION can assume that object
satisfies TYPE-SPECIFIER. Function must obey *PRINT-READABLY* (see issue
DATA-IO). Any values returned by FUNCTION are ignored.
PRIORITY (which defaults to 0) must be a non-complex number. This
number is used as a priority to resolve conflicts when an object
matches more than one entry. An error is signalled if priority fails
to be a non-complex number.
TABLE (which defaults to *PRINT-PPRINT-DISPATCH*) must be a pprint dispatch
table. The specified entry is placed in this table.
It is permissible for FUNCTION to be NIL. In this situation, there will be
no TYPE-SPECIFIER entry in TABLE after SET-PPRINT-DISPATCH is evaluated.
To facilitate the use of pprint dispatch tables for controlling the pretty
printing of Lisp code, the TYPE-SPECIFIER argument of the function
SET-PPRINT-DISPATCH is allowed to contain constructs of the form
(CONS car-type cdr-type)
This signifies that the corresponding object must be a cons cell whose car
matches the type specifier CAR-TYPE and whose cdr matches the type specifier
CDR-TYPE. The CDR-TYPE can be omitted in which case it defaults to T.
The initial value of *PRINT-PPRINT-DISPATCH* is implementation dependent.
However, the initial entries all use a special class of priorities that
have the property that they are less than every priority that can be
specified using SET-PPRINT-DISPATCH. The benefit of this is that it
guarantees that any pretty printing functions users specify will override
everything in the initial value of *PRINT-PPRINT-DISPATCH*.
----------------------------------------------------------------------
Implementation note: The restriction above is very useful to users
without actually limiting what Common Lisp implementors can do. It is
possible for implementors to set up any kind of pretty printing they
desire using the range of priorities available to them.
----------------------------------------------------------------------
Consider the following examples. The first form restores
*PRINT-PPRINT-DISPATCH* to its initial value. The next two forms then set
up a special way to pretty print ratios. Note that the more specific type
specifier has to be associated with a higher priority.
(setq *print-pprint-dispatch* (copy-pprint-dispatch nil))
(set-pprint-dispatch 'ratio
#'(lambda (s obj)
(format s "#.(/ ~W ~W)" (numerator obj) (denominator obj))))
(set-pprint-dispatch '(and ratio (satisfies minusp))
#'(lambda (s obj)
(format s "#.(- (/ ~W ~W))" (- (numerator obj)) (denominator obj)))
5)
(pprint '(1/3 -2/3)) prints: (#.(/ 1 3) #.(- (/ 2 3)))
The following two forms illustrate the definition of pretty printing
functions for types of Lisp code. The first form illustrates how to
specify the traditional method for printing quoted objects using "'"
syntax. Note the care taken to ensure that data lists that happen to begin
with QUOTE will be printed readably. The second form specifies that lists
beginning with the symbol MY-LET should print the same way that lists
beginning with LET print when the initial pprint dispatch table is in effect.
(set-pprint-dispatch '(cons (member quote)) ()
#'(lambda (s list)
(if (and (consp (cdr list)) (null (cddr list)))
(funcall (formatter "'~W") s (cadr list))
(pprint-fill s list)))))
(set-pprint-dispatch '(cons (member my-let)) (pprint-dispatch '(let) nil))
The next example specifies a default method for printing lists that do not
correspond to function calls. Note that, as shown in the definition of
PPRINT-TABULAR above, PPRINT-LINEAR, PPRINT-FILL, and PPRINT-TABULAR are
all defined with optional COLON? and ATSIGN? arguments so that they can be
used as pprint dispatch functions as well as ~/.../ functions.
(set-pprint-dispatch '(cons (not (and symbol (satisfies fboundp))))
#'pprint-fill -5)
with a line length of 9, (pprint '(0 b c d e f g h i j k)) prints:
(0 b c d
e f g h
i j k)
This final example shows how to define a pretty printing function for a
user defined data structure.
(defstruct family mom kids)
(set-pprint-dispatch 'family
#'(lambda (s f)
(funcall (formatter "~@<#<~;~W and ~2I~_~/pprint-fill/~;>~:>")
s (family-mom f) (family-kids f))))
The pretty printing function for the structure FAMILY specifies how to
adjust the layout of the output so that it can fit aesthetically into
a variety of line widths. In addition, it obeys the printer control
variables *PRINT-LEVEL*, *PRINT-LENGTH*, *PRINT-LINES*,
*PRINT-CIRCLE*, *PRINT-SHARED* and *PRINT-ESCAPE*, and can tolerate
several different kinds of malformity in the data structure. The
output below shows what is printed out with a right margin of 25,
*PRINT-PRETTY* T, *PRINT-ESCAPE* NIL, and a malformed KIDS list.
(write (list 'principal-family
(make-family :mom "Lucy"
:kids '("Mark" "Bob" . "Dan")))
:right-margin 25 :pretty T :escape nil :miser-width nil)
(PRINCIPAL-FAMILY
#<Lucy and
Mark Bob . Dan>)
Note that a pretty printing function for a structure is different from the
structure's print function. While print functions are permanently
associated with a structure, pretty printing functions are stored in pprint
dispatch tables and can be rapidly changed to reflect different printing
needs. If there is no pretty printing function for a structure in the
current print dispatch table, the print function (if any) is used instead.
[end of part two of PRETTY-PRINT-INTERFACE:XP]
∂17-Aug-89 1307 X3J13-mailer In case you hadn't heard...
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 17 Aug 89 13:07:53 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 643519; 17 Aug 89 16:09:48 EDT
Date: Thu, 17 Aug 89 16:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: In case you hadn't heard...
To: X3J13@SAIL.Stanford.EDU
Message-ID: <19890817200950.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Not having heard anything, I called Kathy Chapman to see if she'd had
her kid. As I'd suspected, she had done so but had figured no one was
interested so hadn't sent an announcement. From my discussion with her,
I was able to cons the following list of properties...
(Y-CHROMOSOME-P NIL
RGB-HAIR-COLOR (1.0 0.0 0.0)
RGB-EYE-COLOR (0.0 0.0 1.0)
WEIGHT-IN-LBS-AT-BIRTH 111/16
LENGTH-IN-INCHES-AT-BIRTH 41/2
UNIVERSAL-TIME-OF-BIRTH 2827177440.
FULL-NAME "Wesley Ann Spacht"
SEQUENCE-NUMBER 1 ;0-based
MOTHER-AND-SELF-DOING-FINE-P T)
∂28-Aug-89 0805 X3J13-mailer Organizing ANSI Common Lisp
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 28 Aug 89 08:04:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 648289; 28 Aug 89 11:06:43 EDT
Date: Mon, 28 Aug 89 11:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Organizing ANSI Common Lisp
To: X3J13@sail.stanford.edu
Message-ID: <19890828150641.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Two questions:
Does anyone have a list of all the symbols that are supposed to be
external in the COMMON-LISP package? I'd guess the most useful form of
this list would be alphabetical, one per line, with a comment on each
symbol referencing the X3J13 document that specifies that symbol's
existence (CLtL, cleanup issue, CLOS spec, LOOP spec, etc.) Of course
this list will be extractable from the language specification document,
but it would be interesting to find out now if everyone agrees on the
same list of symbols. I remember it took a while to agree on the list
for CLtL Common Lisp since there were a few symbols that were obscurely
documented. These lists will be too long to mail to X3J13, but if you
just mention their existence to X3J13, I'll be willing to coordinate
the correlation of the lists.
Does anyone have an index of the X3J13 cleanup, compiler, and character
issues, cross-referenced by symbol? This would be an inverted form of
the "References" field at the front of the cleanup issue template. For
example, if I wanted to know where MACROLET's expander functions are
changed not to be in the null lexical environment, such an index would
tell me to look in DEFINING-MACROS-NON-TOP-LEVEL (and a couple of other
places).
∂12-Sep-89 1505 X3J13-mailer November X3J13 meeting
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 12 Sep 89 15:05:53 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 12 Sep 89 18:07:52 EDT
Date: Tue, 12 Sep 89 18:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: November X3J13 meeting
To: x3j13@sail.stanford.edu
Message-Id: <19890912220450.7.BARMAR@OCCAM.THINK.COM>
Is the next X3J13 meeting still scheduled for November 6-8?
barmar
∂19-Sep-89 1435 X3J13-mailer November meeting (again)
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 19 Sep 89 14:35:25 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 19 Sep 89 17:37:33 EDT
Date: Tue, 19 Sep 89 17:34 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: November meeting (again)
To: x3j13@sail.stanford.edu
Message-Id: <19890919213424.8.BARMAR@OCCAM.THINK.COM>
A week or two ago I asked whether the November meeting is still on, and
got no response. I need know soon, since I'll be on vacation for two
weeks in two weeks (going back to Hawaii for a more respectful length of
time), and I'd like to make the arrangements before I leave. Is the
meeting still scheduled for November 6-8 in Fairfax?
barmar
∂19-Sep-89 1848 X3J13-mailer latest draft
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Sep 89 18:48:22 PDT
Received: by decwrl.dec.com; id AA00362; Tue, 19 Sep 89 17:52:38 -0700
Date: Tue, 19 Sep 89 17:52:31 -0700
Message-Id: <8909200052.AA00362@decwrl.dec.com>
From: chapman@aitg.enet.dec.com (19-Sep-1989 1711)
To: "x3j13@sail.stanford.edu"@decwrl.dec.com
Cc: CHAPMAN@decwrl.dec.com
Subject: latest draft
You should have received working draft standard chapters 2 and 3 and the
glossary. The remaining chapters are being mailed this week.
This mailing is approximately equal to what was mailed to ISO.
Note that the figure listing and the TOC reflect the total standard,
not the ISO subset (sorry about that).
If you recall from the last meeting, we were to review this part of the
standard first and decide what to do with it at the November meeting.
At that time, the remainder of the standard will be distributed for
review.
Please try to review this information as soon as possible, paying
close attention to the guidelines in the cover letter since those
are what we agreed to at the last meeting. Keep in mind that in the
rush to insure that the issues were correctly incorporated, the
formatting of figures and layout of the document took a back seat.
Don't get worried that the final standard will look disheveled.
Thanks in advance for your careful review.
kathy
∂20-Sep-89 0826 CL-Cleanup-mailer Issue COMPLEX-ATANH-BOGUS-FORMULA
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 20 Sep 89 08:26:44 PDT
Received: from fafnir.think.com by Think.COM; Wed, 20 Sep 89 11:28:29 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 20 Sep 89 11:25:01 EDT
Received: by verdi.think.com; Wed, 20 Sep 89 11:24:48 EDT
Date: Wed, 20 Sep 89 11:24:48 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8909201524.AA21857@verdi.think.com>
To: x3j13@sail.stanford.edu
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Issue COMPLEX-ATANH-BOGUS-FORMULA
I hate to bring *anything* up at this late date, but while working over the
numbers chapter second edition I have been going over this branch cut stuff
one more time, with even greater care, and have discovered that the formula
for ATANH on page 209 and again on page 213 is completely bogus. What that
computes is not anything like a hyperbolic arc tangent. It would seem that
I must have mistranscribed the APL formula in Penfield's article.
CLtL has: arctanh z = log ((1+z) sqrt(1 - (1 / z↑2)))
Should be: arctanh z = log ((1+z) sqrt(1 / (1 - z↑2)))
Note that they differ in the transposition of two operators. (Boy, am I
embarrassed.)
Clearly this must be corrected. In the meantime I have found a more
definitive treatment of complex branch cuts by W. Kahan, and I propose to
follow his recommendations. This involves correcting the formula for
ATANH, and adopting new formulas for ACOS and ACOSH that are equivalent to
the ones we have now but more perspicuous.
I would appreciate knowing very soon on an informal basis whether anyone
objects to this change, so that I can include some discussion of it in the
second edition. (Of course I'm not asking for a vote until we have an
official meeting.)
--Guy
----------------------------------------------------------------
Status: New proposal
Forum: Cleanup
Issue: COMPLEX-ATANH-BOGUS-FORMULA
References: CLtL pp. 209, 212, 213
Penfield, P. "Principal Values and Branch Cuts in
Complex APL", Proc. APL 81 Conference Proceedings,
Association for Computing Machinery, 1981
Kahan, W. "Branch Cuts for Complex Elementary
Functions, or Much Ado About Nothing's Sign Bit"
in Iserles and Powell (eds.) "The State of the Art
in Numerical Analysis", pp. 165-211, Clarendon
Press, 1987
Related issues: COMPLEX-ATAN-BRANCH-CUT, IEEE-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 20-SEP-89, Steele
Problem description:
The formula that defines ATANH in CLtL is incorrect, apparently
because of a mistranscription of a formula from Penfield's article.
CLtL has: arctanh z = log ((1+z) sqrt(1 - (1 / z↑2)))
Should be: arctanh z = log ((1+z) sqrt(1 / (1 - z↑2)))
However, given the change to ATAN in issue COMPLEX-ATAN-BRANCH-CUT,
it seems simpler to follow Kahan's recommendation and define
arctanh z = (log(1+z) - log(1-z))/2
thereby preserving the identity i arctan z = arctanh iz .
Kahan also notes that Penfield's formula for arccosh (CLtL p. 213)
arccosh z = log(z + (z + 1) sqrt((z-1)/(z+1)))
has a gratuitous removable singularity at z=-1 and recommends
arccosh z = 2 log(sqrt((z+1)/2) + sqrt((z-1)/2))
which has the same values and is also well-defined at z=-1.
Finally, Kahan recommends a different defining formula for acos
that is more similar to that of acosh (but less similar to that
of asin).
Proposal (COMPLEX-ATANH-BRANCH-CUT:TWEAK-MORE):
(1) Replace the erroneous formula
arctanh z = log ((1+z) sqrt(1 - (1 / z↑2)))
with
arctanh z = (log(1+z) - log(1-z))/2
(2) Note that i arctan z = arctanh iz .
(3) Replace the gratuitously singular formula
arccosh z = log(z + (z + 1) sqrt((z-1)/(z+1)))
with
arccosh z = 2 log(sqrt((z+1)/2) + sqrt((z-1)/2))
(4) Adopt the formula (already in CLtL)
arccos z = (pi / 2) - arcsin z
as the official definition of arccos, and also note that the
formulas
arccos z = -i log(z + i sqrt(1 - z↑2))
(already in CLtL) and
arccos z = 2 log(sqrt((1+z)/2) + i sqrt((1-z)/2)) / i
(recommended by Kahan) are equivalent.
Rationale:
Compatibility with what seems to be becoming standard practice.
Current practice:
Implementations I have checked have a correct implementation
of ATANH rather than slavishly following the bogus CLtL formula.
Cost to Implementors:
ATANH must be rewritten. It is not a very difficult fix.
Possibly ACOSH must be rewritten. It is not a very difficult fix.
Cost to Users:
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Possible incorrect implementations of ATANH.
Incompatibility with HP calculators.
Benefits:
Numerical analysts may find the new definition easier to use.
Esthetics:
A toss-up, except to those who care.
Discussion:
Kahan's article not only discussed formulas but also gives specific
implementation techniques for use with IEEE 754 arithmetic.
∂25-Sep-89 1304 X3J13-mailer Other things we might want to clean up
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Sep 89 13:03:58 PDT
Received: from fafnir.think.com by Think.COM; Mon, 25 Sep 89 16:06:24 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 25 Sep 89 16:02:14 EDT
Received: by verdi.think.com; Mon, 25 Sep 89 16:02:26 EDT
Date: Mon, 25 Sep 89 16:02:26 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8909252002.AA06408@verdi.think.com>
To: x3j13@sail.stanford.edu
Cc: gls@Think.COM
Subject: Other things we might want to clean up
I have running through the old issues and have found a few discrepancies we
might want to address at the November meeting. Let me emphasize that I am
addressing only problems with old issues, trying not to raise new issues.
I think each of these is pretty simple but goes beyond the nature of a
simple editorial correction; in other words, for each one I could imagine a
reasonable person coming up with some objection. I bet we could vote them
up or down in less than fifteen minutes in November.
It would be useful to me to know soon whether anyone has an objection
right off the bat to any of these.
On the whole I have been very impressed how few such discrepancies I have
found. The proposals have been well thought out and quite thorough.
--Guy
(1) Proposal LISP-PACKAGE-NAME:COMMON-LISP (passed March 1989)
specifies that ANSI Common Lisp uniformly replaces the package
named USER with one names COMMON-LISP-USER, and the package
named LISP with COMMON-LISP. The idea is to allow CLtL Common Lisp
and ANSI Common Lisp to coexist in the same memory image.
Problem: what about the SYSTEM package? CLtL Common Lisp needs
it to use the LISP package, and ANSI Common Lisp presumably needs
it to use the COMMON-LISP package.
Suggestion: in ANSI Common Lisp, the SYSTEM package is named
COMMON-LISP-SYSTEM with nickname CL-SYS and uses COMMON-LISP-USER.
(2) Proposal REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89 (passed March 1989)
specifies behavior for NUNION, NINTERSECTION, and NSET-EXCLUSIVE-OR
but does not mention NSET-DIFFERENCE. This appears to be a simple
oversight.
Suggestion: amend the proposal to treat NSET-DIFFERENCE in the same
way as the other three functions mentioned.
(3) Proposal LISP-SYMBOL-REDEFINITION:MAR89-X3J13 (passed March 1989)
restricts various sorts of redefinition on symbols in the COMMON-LISP
package.
Proposal DEFINE-COMPILER-MACRO:NEW-FACILITY (passed June 1989)
subsequently introduced the notion of a compiler macro.
Suggestion: amend LISP-SYMBOL-REDEFINITION:MAR89-X3J13 to add
another form of prohibited redefinition:
14. Defining it as a compiler macro
(4) Proposal FUNCTION-TYPE:X3J13-MARCH-88 (actually passed June 1988)
specifies that the value of *MACROEXPAND-HOOK* is coerced to a
function before being called as the expansion interface hook.
This allows its value to be a lambda-expression, for example.
However, the proposal does not mention *EVALHOOK* and *APPLYHOOK*.
Suggestion: specify that the value of *EVALHOOK* or *APPLYHOOK*,
if not NIL, is coerced to be a function before being called as a hook.
(5) Proposal SETF-MULTIPLE-STORE-VALUES:ALLOW extends SETF and friends
to deal with SETF methods that have more than one store variable
and newvalue forms that produce more than one value. The discussion
remarks that "it is not difficult to write a reasonable SETF method
for the VALUES function, yielding a powerful MULTIPLE-VALUE-SETF form."
Suggestion: incorporate a SETF method for VALUES into Common Lisp.
I think this would be very useful and not difficult.
Second suggestion: clarify that SETF returns all the values
produced by its last <newvalue> form, and that SHIFTF returns
all the values of its <place1> form.
[End]
∂25-Sep-89 1319 X3J13-mailer Other things we might want to clean up
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Sep 89 13:17:31 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 25 Sep 89 16:19:34 EDT
Date: Mon, 25 Sep 89 16:15 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Other things we might want to clean up
To: Guy Steele <gls@Think.COM>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8909252002.AA06408@verdi.think.com>
Message-Id: <19890925201518.8.BARMAR@OCCAM.THINK.COM>
Date: Mon, 25 Sep 89 16:02:26 EDT
From: gls@Think.COM (Guy Steele)
(1) Proposal LISP-PACKAGE-NAME:COMMON-LISP (passed March 1989)
specifies that ANSI Common Lisp uniformly replaces the package
named USER with one names COMMON-LISP-USER, and the package
named LISP with COMMON-LISP. The idea is to allow CLtL Common Lisp
and ANSI Common Lisp to coexist in the same memory image.
Problem: what about the SYSTEM package? CLtL Common Lisp needs
it to use the LISP package, and ANSI Common Lisp presumably needs
it to use the COMMON-LISP package.
Suggestion: in ANSI Common Lisp, the SYSTEM package is named
COMMON-LISP-SYSTEM with nickname CL-SYS and uses COMMON-LISP-USER.
I thought we got rid of references to the SYSTEM package in ANSI CL.
barmar
∂25-Sep-89 1329 X3J13-mailer Other things we might want to clean up
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 25 Sep 89 13:29:32 PDT
Received: from xenna.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA16592; Mon, 25 Sep 89 16:32:35 -0400
Received: by xenna.UUCP (4.0/4.7)
id AA29045; Mon, 25 Sep 89 16:31:16 EDT
Date: Mon, 25 Sep 89 16:31:16 EDT
From: Dan Pierson <pierson@xenna.encore.com>
Message-Id: <8909252031.AA29045@xenna.UUCP>
To: gls@Think.COM (Guy Steele)
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8909252002.AA06408@verdi.think.com>
Subject: Other things we might want to clean up
Guy Steele writes:
> Suggestion: in ANSI Common Lisp, the SYSTEM package is named
> COMMON-LISP-SYSTEM with nickname CL-SYS and uses COMMON-LISP-USER.
I thought we had verbally agreed to just remove the SYSTEM package
from the standard since many implementations have no use for it and
the convention of putting Froboz Inc.'s extensions in the package
FROBOZ-COMMON-LISP seems likely to supersede it in practice.
On the other hand, I don't feel at all strongly about the SYSTEM
package and do not intend to spend any time at the meeting arguing or
voting against a reasonable suggestion such as yours.
∂25-Sep-89 1341 X3J13-mailer Other things we might want to clean up
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Sep 89 13:41:30 PDT
Received: from fafnir.think.com by Think.COM; Mon, 25 Sep 89 16:43:57 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 25 Sep 89 16:39:50 EDT
Received: by verdi.think.com; Mon, 25 Sep 89 16:40:02 EDT
Date: Mon, 25 Sep 89 16:40:02 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8909252040.AA06576@verdi.think.com>
To: barmar@Think.COM
Cc: gls@Think.COM, x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Mon, 25 Sep 89 16:15 EDT <19890925201518.8.BARMAR@OCCAM.THINK.COM>
Subject: Other things we might want to clean up
Please ignore item (1) in my previous message. Prompted by Dan and Barry
(thanks, fellows!) I did a quick search os passed issues. Somehow I
overlooked the fact that proposal PACKAGE-CLUTTER:REDUCE (passed January
1989) eliminated the SYSTEM package from ANSI Common Lisp.
Sorry about that. However, it illustrates exactly why there should
be a vote instead of everyone just taking my word for it.
One down. I still think the other four items deserve thought.
--Guy
----------------------------------------------------------------
Date: Mon, 25 Sep 89 16:02:26 EDT
From: gls@Think.COM (Guy Steele)
(1) Proposal LISP-PACKAGE-NAME:COMMON-LISP (passed March 1989)
specifies that ANSI Common Lisp uniformly replaces the package
named USER with one names COMMON-LISP-USER, and the package
named LISP with COMMON-LISP. The idea is to allow CLtL Common Lisp
and ANSI Common Lisp to coexist in the same memory image.
Problem: what about the SYSTEM package? CLtL Common Lisp needs
it to use the LISP package, and ANSI Common Lisp presumably needs
it to use the COMMON-LISP package.
Suggestion: in ANSI Common Lisp, the SYSTEM package is named
COMMON-LISP-SYSTEM with nickname CL-SYS and uses COMMON-LISP-USER.
Date: Mon, 25 Sep 89 16:15 EDT
From: Barry Margolin <barmar@Think.COM>
I thought we got rid of references to the SYSTEM package in ANSI CL.
Date: Mon, 25 Sep 89 16:31:16 EDT
From: Dan Pierson <pierson@xenna.encore.com>
I thought we had verbally agreed to just remove the SYSTEM package
from the standard since many implementations have no use for it and
the convention of putting Froboz Inc.'s extensions in the package
FROBOZ-COMMON-LISP seems likely to supersede it in practice.
On the other hand, I don't feel at all strongly about the SYSTEM
package and do not intend to spend any time at the meeting arguing or
voting against a reasonable suggestion such as yours.
∂25-Sep-89 1515 X3J13-mailer Time functions
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Sep 89 15:14:27 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 25 Sep 89 18:16:54 EDT
Date: Mon, 25 Sep 89 18:12 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Time functions
To: x3j13@sail.stanford.edu
Message-Id: <19890925221245.4.BARMAR@OCCAM.THINK.COM>
What should the various get-XXX-time functions do if the system has no
clock?
barmar
∂25-Sep-89 1722 X3J13-mailer Time functions
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 25 Sep 89 17:22:29 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA11627; Mon, 25 Sep 89 20:23:18 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA10262; Mon, 25 Sep 89 16:34:00 PDT
Received: by fiona.Franz.COM (3.2/FI-1.0)
id AA12169; Mon, 25 Sep 89 16:33:57 PDT
Date: Mon, 25 Sep 89 16:33:57 PDT
From: smh@Franz.COM (Steve Haflich)
Message-Id: <8909252333.AA12169@fiona.Franz.COM>
To: barmar@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Mon, 25 Sep 89 18:12 EDT <19890925221245.4.BARMAR@OCCAM.THINK.COM>
Subject: Time functions
From: Barry Margolin <barmar@Think.COM>
What should the various get-XXX-time functions do if the system has no
clock?
Probably the best you can do is politely ask the user what time it is
(or how much time has elapsed, etc.) using *QUERY-IO*.
∂26-Sep-89 1230 X3J13-mailer November X3J13 meeting, Palo Alto
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 89 12:30:12 PDT
Received: from rose ([192.9.200.83]) by heavens-gate id AA04018g; Tue, 26 Sep 89 12:29:26 PDT
Received: by rose id AA01702g; Tue, 26 Sep 89 12:30:49 PDT
Date: Tue, 26 Sep 89 12:30:49 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8909261930.AA01702@rose>
To: x3j13@sail.stanford.edu
Subject: November X3J13 meeting, Palo Alto
Please let me now ASAP if you are planning to attend and which meals you'll be
attending.
Thanks!
---jan---
COMMITTEE MEETING:
DATES: 11/6 - 11/8
TIME: 9:00 - 5:00
CITY: Palo Alto
PLACE: Xerox PARC
ROOM: Auditorium
ADDRESS: 3333 Coyote Hill Road (Directions from hotel to PARC below)
REGISTRATION FEE: $60 Payable to: LUCID, Inc.
HOTEL ACCOMODATIONS:
HOTEL: Rickey's Hyatt
ADDRESS: 4219 El Camino Real, Palo Alto, CA 94306
PHONE: 800/228-9000 or 415/493-8000
RATE: $82/night
MENTION: "X3J13" or "Lucid" or "Xerox" for rate (ya just never know...)
DIRECTIONS from airport:
>From SFO: Take 101 south to San Antonio Road (about 25 minutes in non-rush
hour traffic). Take San Antonio Road exit marked Los Altos, heading toward the
hills. Turn right on El Camino Real. The hotel is on the right at 4219 El
Camino Real.
Directions from hotel to PARC:
Traveling "north" on El Camino, turn left at Page Mill. Go about 1.5
miles, you will cross Foothill Expressway. Take the first left after
you cross Foothill, that is Coyote Hill Road. Go up Coyote Hill Road
and, just after you crest the hill, take the first left. This will take
you into the PARC parking lot. At that point turn left again to go into
the vistors lot. Follow the signs to the auditorium entrance.
In short, after leaving Rickey's, there are 3 left turns to get to PARC.
One more to get to the visitor's lot.
For further information contact:
Jan Zubkoff
jlz@lucid.com
904/926-8039
!
X3J13 November 1989 Meeting Registration Form
Checks will be collected the first day of the meeting.
Name: _____________________________________________________________
Institution: ______________________________________________________
Phone: ____________________________________________________________
Lunch 11/6: _________ yes _______ no
Lunch 11/7: _________ yes _______ no
Lunch 11/8: _________ yes _______ no
∂26-Sep-89 1310 X3J13-mailer November X3J13 meeting, Palo Alto
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 26 Sep 89 13:10:01 PDT
Received: from fafnir.think.com by Think.COM; Tue, 26 Sep 89 16:12:18 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 26 Sep 89 16:08:09 EDT
Received: by verdi.think.com; Tue, 26 Sep 89 16:08:21 EDT
Date: Tue, 26 Sep 89 16:08:21 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8909262008.AA01339@verdi.think.com>
To: jlz@lucid.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Tue, 26 Sep 89 12:30:49 PDT <8909261930.AA01702@rose>
Subject: November X3J13 meeting, Palo Alto
I'll be there! As for lunches, can we get Chef Chu to bring
them in, or is it PARC cafeteria?
--Q
∂26-Sep-89 2054 X3J13-mailer function and generic-function
Received: from mtfuji.gw.u-tokyo.ac.jp ([128.167.64.2]) by SAIL.Stanford.EDU with TCP; 26 Sep 89 20:53:57 PDT
Received: from relay.cc.u-tokyo.ac.jp by mtfuji.gw.u-tokyo.ac.jp (5.61/WIDE/JUNET-1.2)
id AA04657; Tue, 26 Sep 89 23:55:25 -0400
Received: from ccutrd.cc.u-tokyo.ac.jp by relay.cc.u-tokyo.ac.jp (5.61/6.3J-1.1jp)
id AA03144; Wed, 27 Sep 89 12:54:49 +0900
Received: from aoyama.cc.aoyama.ac.jp by ccut.cc.u-tokyo.ac.jp (5.61/6.4J.6-ut1.57)
id AA01058; Wed, 27 Sep 89 12:57:08 +0900
Received: by aoyama.cc.aoyama.ac.jp (4.0/6.4J.6-agu4)
id AA15869; Wed, 27 Sep 89 12:53:34 JST
Received: by kepa.cc.aoyama.ac.jp (4.0/6.4J.5-aguac)
id AA20576; Wed, 27 Sep 89 12:53:42 JST
Date: Wed, 27 Sep 89 12:53:42 JST
From: Masayuki Ida <ida@cc.aoyama.ac.jp>
Return-Path: <ida@cc.aoyama.ac.jp>
Message-Id: <8909270353.AA20576@kepa.cc.aoyama.ac.jp>
To: x3j13@sail.stanford.edu
Cc: ida@cc.aoyama.ac.jp
Subject: function and generic-function
An ambiguity with the current draft.
Page 2-14 says
"The type generic-function is a subtype of the types function and t."
and
Page 2-23 Figure 2-7 shows their relation as follows:
t
|
-- compiled-function ------------- function ------------|
| |
-- standard-generic-function ----- generic-function -----
meaning "generic-function is NOT a subtype of the type function".
Figure 2-7 should be updated to show
"generic-function is a subtype of the type function" like,
t
|
-- compiled-function ------------------------------------ function -----|
|
-- standard-generic-function ---- generic-function ----
Masayuki Ida
Aoyama Gakuin University, Japan
∂27-Sep-89 1718 X3J13-mailer Other things we might want to clean up
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 27 Sep 89 17:18:15 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA16839; Wed, 27 Sep 89 17:14:34 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00753; Wed, 27 Sep 89 17:19:04 PDT
Message-Id: <8909280019.AA00753@masunter.parc.xerox.com>
Date: Wed, 27 Sep 89 17:19:04 PDT
From: <masinter@parc.xerox.com>
To: gls@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: Guy Steele's message of Mon, 25 Sep 89 16:02:26 EDT <8909252002.AA06408@verdi.think.com>
Subject: Other things we might want to clean up
Reply-To: masinter@parc.xerox.com
I'm hoping there will be few enough cleanup-style issues for the
November meeting that we can deal with them individually. Does anyone
think we'll need a "cleanup" agenda item? Does anyone expect any
issues to be addressed other than those that Guy mentioned?
∂29-Sep-89 1526 X3J13-mailer November X3J13 meeting, Palo Alto
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 29 Sep 89 15:26:45 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA11010; Fri, 29 Sep 89 18:27:16 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA10154; Fri, 29 Sep 89 12:23:46 PDT
Received: by ox.Franz.COM (4.0/FI-1.0)
id AA10797; Fri, 29 Sep 89 12:29:37 PDT
Date: Fri, 29 Sep 89 12:29:37 PDT
From: jarl@Franz.COM (Jarl Nilsson)
Message-Id: <8909291929.AA10797@ox.Franz.COM>
To: jlz@lucid.com
Cc: x3j13@sail.stanford.edu
Subject: November X3J13 meeting, Palo Alto
I will attend.
I'll represent myself (and NOT Franz inc.).
Count me in for all lunches.
/jarl
____________________________________________________________
Jarl Atle Nilsson Franz inc.
417 Evelyn ave. #106 1995 University ave. Berkeley CA
Albany, CA 94706 jarl@franz.com // uunet!franz!jarl
(home) (415) 524-8110 (work) (415) 548-3600
∂04-Oct-89 2059 X3J13-mailer Other things we might want to clean up
Received: from src.honeywell.com (altura.Honeywell.COM) by SAIL.Stanford.EDU with TCP; 4 Oct 89 20:59:52 PDT
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.src.honeywell.com by src.honeywell.com (4.0/smail2.6.3/SRCv0.25);
Wed, 4 Oct 89 22:59:43 CDT id AA16107 for x3j13@sail.stanford.edu at sail.stanford.edu
Posted-Date: Wed, 4 Oct 89 22:59:40 CDT
Received: by pavo.src.honeywell.com (4.0/SMI-3.2)
id AA11307; Wed, 4 Oct 89 22:59:40 CDT
Date: Wed, 4 Oct 89 22:59:40 CDT
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8910050359.AA11307@pavo.src.honeywell.com>
To: masinter@parc.xerox.com
Cc: gls@Think.COM, x3j13@sail.stanford.edu
In-Reply-To: <masinter@parc.xerox.com>'s message of Wed, 27 Sep 89 17:19:04 PDT <8909280019.AA00753@masunter.parc.xerox.com>
Subject: Other things we might want to clean up
From: <masinter@parc.xerox.com>
...Does anyone expect any issues to be addressed other than those that
Guy mentioned?
I've found two;
pg 1-9 in the description of safe code:
The statement: Thus the phrase "the function F should signal an error"
... an error will be signalled. Appears wrong to me (it is consistent
with the cleanup proposals however) E.g.
(let ((safe #'(lambda (f a b) (declare (optimize (safety 3)))
(funcall f a b)))
(not-safe #'(lambda (f a b) (declare (optimize (safety 1)))
(funcall f a b))))
(declare (optimize (safety XXX)))
(funcall #'safe #'+ 1 nil)
(funcall #'not-safe #'+ 1 nil))
If the "safeness" of this program is not dependent on the value of XXX,
then I don't think we've captured the essense of "lexical property of code"
correctly in the definition of "safe code". Perhaps the statement needs to
take into account the coercion from symbol to function.
(I don't have much energy for this one)
pg 2-14&15 can you use the stream types as specializers for defmethod?
The various stream-xxx types are not listed in figure 2-13. They are not
specified as being classes in the STREAM-ACCESS cleanup. Should we
entertain a cleanup to make them classes/useable as specializers?
∂04-Oct-89 2138 X3J13-mailer Other things we might want to clean up
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Oct 89 21:37:56 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA18185; Wed, 4 Oct 89 21:38:19 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00624; Wed, 4 Oct 89 21:38:24 PDT
Message-Id: <8910050438.AA00624@masunter.parc.xerox.com>
Date: Wed, 4 Oct 89 21:38:24 PDT
From: <masinter@parc.xerox.com>
To: alarson@src.honeywell.com
Cc: gls@Think.COM, x3j13@sail.stanford.edu
In-Reply-To: Aaron Larson's message of Wed, 4 Oct 89 22:59:40 CDT <8910050359.AA11307@pavo.src.honeywell.com>
Subject: Other things we might want to clean up
Reply-To: masinter@parc.xerox.com
I don't think these are cleanup issues.
I don't think we had a 'cleanup' issue on the declaration of safety
(my memory is failing; was this a compiler issue? Or editorial?)
While I can find no mention of it in the mail for stream-access, I
remember discussing the issue and deciding *not* to add the stream
subtypes as classes; there was some fairly serious issues having to do
with whether (class-of x) needed to be more specific than "stream",
even for a two-way stream, etc. Adding the "types" as predicates
didn't have the negative effects that adding classes would.
∂04-Oct-89 2211 X3J13-mailer Character proposal
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 4 Oct 89 22:11:20 PDT
Received: from fafnir.think.com by Think.COM; Thu, 5 Oct 89 01:13:43 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 5 Oct 89 01:09:40 EDT
Received: by verdi.think.com; Thu, 5 Oct 89 01:09:47 EDT
Date: Thu, 5 Oct 89 01:09:47 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8910050509.AA26577@verdi.think.com>
To: x3j13@sail.stanford.edu
Cc: gls@Think.COM
Subject: Character proposal
The issues passed on the character proposal did not address the
following, but I assume that we should regard the #nnn\x syntax
for specifying the font attribute of a character no longer to
be defined, and that COERCE no longer converts integers to
characters (as INT-CHAR has disappeared)?
--Guy
∂05-Oct-89 0703 X3J13-mailer Other things we might want to clean up
Received: from src.honeywell.com (altura.Honeywell.COM) by SAIL.Stanford.EDU with TCP; 5 Oct 89 07:03:47 PDT
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.src.honeywell.com by src.honeywell.com (4.0/smail2.6.3/SRCv0.25);
Thu, 5 Oct 89 08:41:15 CDT id AA25027 for masinter@parc.xerox.com at parc.xerox.com
Posted-Date: Thu, 5 Oct 89 08:39:43 CDT
Received: by pavo.src.honeywell.com (4.0/SMI-3.2)
id AA11467; Thu, 5 Oct 89 08:39:43 CDT
Date: Thu, 5 Oct 89 08:39:43 CDT
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8910051339.AA11467@pavo.src.honeywell.com>
To: masinter@parc.xerox.com
Cc: gls@Think.COM, x3j13@sail.stanford.edu
In-Reply-To: <masinter@parc.xerox.com>'s message of Wed, 4 Oct 89 21:38:24 PDT <8910050438.AA00624@masunter.parc.xerox.com>
Subject: Other things we might want to clean up
Date: Wed, 4 Oct 89 21:38:24 PDT
From: <masinter@parc.xerox.com>
I don't think these are cleanup issues.
I don't think we had a 'cleanup' issue on the declaration of safety
(my memory is failing; was this a compiler issue? Or editorial?)
It came from ERROR-TERMINOLOGY, which I believe was editorial. I've been
sort of assuming that "cleanup" at this point means non editorial level
review. It was my understanding that the cleanup committee has essentially
reverted to the committee at large.
...deciding *not* to add the stream subtypes as classes...
O.k. by me, I couldn't find any reference to this either, and thought it
may have fallen through the cracks.
∂05-Oct-89 1008 X3J13-mailer Re: Character proposal
Received: from IBM.COM (ALMADEN.IBM.COM) by SAIL.Stanford.EDU with TCP; 5 Oct 89 10:08:04 PDT
Received: from almaden.ibm.com by IBM.COM (IBM VM SMTP R1.2.1MX) with BSMTP id 4000; Thu, 05 Oct 89 10:09:03 PDT
Received: by linden.almaden.ibm.com (FL-AIX 2.1.2/4.03)
id AA12250; Thu, 5 Oct 89 10:07:47 PDT
Message-Id: <8910051707.AA12250@linden.almaden.ibm.com>
To: gls%Think.COM@vmn.almaden.ibm.COM (Guy Steele)
Cc: x3j13@sail.stanford.edu, gls@Think.COM
Subject: Re: Character proposal
In-Reply-To: Your message of Thu, 05 Oct 89 01:09:47 EDT.
<8910050509.AA26577@verdi.think.com>
Date: Thu, 05 Oct 89 10:07:17 -0800
From: "Thom" <BAGGINS@IBM.COM>
I agree with gls on both points.
Thom
∂06-Oct-89 1808 X3J13-mailer character proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 6 Oct 89 18:08:06 PDT
Date: Thu, 05 Oct 89 10:12:37 PDT
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <891005.101237.baggins@almvma>
Subject: character proposal
I agree with Guy on both (reader syntax and coercion) points.
Thom
∂07-Oct-89 1453 X3J13-mailer 2 week rule and agenda items
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 89 14:53:26 PDT
Received: from rose ([192.9.200.83]) by heavens-gate id AA08611g; Sat, 7 Oct 89 14:52:26 PDT
Received: by rose id AA00593g; Sat, 7 Oct 89 14:54:01 PDT
Date: Sat, 7 Oct 89 14:54:01 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8910072154.AA00593@rose>
To: x3j13@sail.stanford.edu
Subject: 2 week rule and agenda items
Just a reminder that things should be mailed this week if you have something
to be voted on.
Please let me know if you have anything to put on the agenda and how much time
you need.
---jan---
∂08-Oct-89 1407 X3J13-mailer more cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Oct 89 14:07:42 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15021; Sun, 8 Oct 89 15:08:45 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA18897; Sun, 8 Oct 89 15:08:40 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910082108.AA18897@defun.utah.edu>
Date: Sun, 8 Oct 89 15:08:39 MDT
Subject: more cleanups
To: masinter.pa@xerox.com
Cc: x3j13@sail.stanford.edu
Here is my current list of random bugs, misfeatures, omissions, and
the like. About half of these came up in the context of questions
about how the particular feature should be implemented and the rest
came up while I've been reviewing the latest material from the
drafting committee. I'm sure there are more problems that I just haven't
discovered yet, too.
Most of these notes are pretty terse and some of them raise questions
without supplying answers. They are not listed in any particular
order.
Larry, do you want to treat these as cleanup issues at the upcoming
meeting?
(1) Remove the requirement that STEP be implemented using *EVALHOOK*
(CLtL p323). Clarify that the *EVALHOOK* and *APPLYHOOK* functions
may never actually be invoked by the evaluator. (I think they ought
to be deprecated.) Make it explictly vague whether the scope of the
code which is stepped by STEP is lexical or dynamic.
(2) INSPECT ought to return its argument instead of leaving its return
value unspecified. If the inspector allows the user to edit the
object then it should be OK to return the modified object (possibly a
copy or a replacement object) instead.
(3) Requiring an error to be signalled in the case of a SPECIAL
declaration in SYMBOL-MACROLET is bogus, since there are plenty of
other cases where you can get screwed with declarations that apply to
variable bindings when the lexically visible "binding" is a symbol
macro. For example, what does DYNAMIC-EXTENT mean when applied to a
symbol that names a symbol macro? Does a SPECIAL declaration inside a
LOCALLY shadow any symbol-macro definition of the symbol that would
otherwise be lexically visible?
Also, if TYPE declarations can apply to symbol macros, it seems like
for symmetry that FTYPE declarations ought to be able to apply to
ordinary macros. Actually, I'd suggest not allowing TYPE declarations
to apply to symbol macros since users can just as easily wrap a THE
form around the expansion in the SYMBOL-MACROLET form. More
generally, I think there needs to be clarification of what
declarations that apply to function or variable bindings mean when the
lexically visible "binding" is a macro definition instead of a real
binding, and all of them should be treated uniformly.
(4) There's a problem with DEFINE-DECLARATION in that it assumes that
a single declaration-specifier can apply to either function or
variable bindings, but not both. DYNAMIC-EXTENT cannot be handled
with this mechanism. Maybe DEFINE-DECLARATION should be modified so
that the function returns a single value which is a list whose
elements are lists of the form
(:VARIABLE name (key . value))
(:FUNCTION name (key . value))
(:DECLARE (key . value))
or something like that. (I won't claim that there isn't a better solution
to the problem.)
(5) The description of DEFGENERIC says that if the function-name
already names a generic function, "that generic function is modified".
That's pretty vague. What parts of the old definition are retained?
For example, are methods from the old definition carried over? What
happens if the lambda list of the new generic function is not
congruent to that of the old definition? I also think it is wrong to
signal an error when an existing function or macro is redefined as a
generic function; it would make more sense and be more consistent to
say that DEFGENERIC always redefines the function (in the same way
that DEFUN does), or to leave the consequences of any redefinition of
a function/macro explicitly vague the same as we do for redefinition
of DEFSTRUCTs (issue DEFSTRUCT-REDEFINITION).
(6) Must the lambda variables specified in the generic function lambda
list actually be bound to the corresponding actual arguments by the
generic function? For lexical variables it shouldn't matter but what
if one of them has been proclaimed SPECIAL?
(7) I'm not convinced that ENSURE-GENERIC-FUNCTION is really necessary.
To me it seems unlikely that users will want to use this function,
since they can get equivalent functionality by using DEFGENERIC or a
combination of SETF FDEFINITION with the GENERIC-FUNCTION macro.
Either provide an explicit motivation for it or get rid of it.
(8) I think the way method combinations work is far too complicated
and inefficient. Instead of building a piece of code at runtime for a
specific set of applicable methods, the method combination function
ought to work more like a macro or a SETF method and be a compile-time
transformation. (I.e., instead of passing it a list of methods, pass
it a variable which is bound to a list of methods when the method
combination function is invoked.) Have to think more about a specific
proposal.
(9) Do the symbols which name DEFSTRUCT slots actually appear as
lambda variables in the default keyword constructor function? It
really only matters if a slot name symbol has been proclaimed SPECIAL.
CLtL says that the default slot init forms are evaluated in the
lexical environment in which the DEFSTRUCT appears but says nothing
about the dynamic environment.
(10) Is it permissible for the (:CONSTRUCTOR <name>) DEFSTRUCT option to
appear multiple times to get multiple copies of the default keyword
constructor function? Or is this behavior undefined/unspecified?
(11) For that matter, what is the right error terminology for other
kinds of syntactic errors in DEFSTRUCT options, like specifying two
:CONC-NAME options, specifying both :PRINT-FUNCTION and :TYPE, etc.?
(12) Does using :CONSTRUCTOR to specify a BOA constructor disable
DEFSTRUCT from making a default keyword constructor function too, or
do you have to explicitly specify (:CONSTRUCTOR NIL) to disable it?
(13) State explicitly that although circularities are OK in quoted or
self-evaluating constants, the effect of evaluating or compiling a
form that contains circularities anywhere else is undefined. For
example,
(progn . #1=((print 'in-endless-loop) . #1#)))
isn't a valid way to write a loop, and
#2=#'(lambda (x)
(if (eql x 1)
1
(funcall #2# (1- x))))
isn't a valid way to define a recursive function.
(14) Is it permissible for the expansion of a standard Common Lisp
macro in a particular implementation to contain syntax which is not
part of standard Common Lisp? For example, Lucid's DEFUN expands into
a SYS:NAMED-LAMBDA expression that has slightly different syntax than
a standard lambda expression. What about if the implementation
supports the use of a list like (SETF FOO) in the functional position
of a call?
(15) I think we ought to reconsider issue DEFINE-COMPILER-MACRO since
there is some disagreement about what it was intended to say. In
particular, I would like very much to see the requirements for
handling of NOTINLINE declarations made uniform between
COMPILER-MACRO-FUNCTION, COMPILER-MACROEXPAND, and the compiler.
(16) The description of DEFTYPE on CLtL p50 says that: "DEFTYPE
differs from DEFMACRO in that if no initform is specified for an
&OPTIONAL parameter, the default vaue is *, not NIL." Does this apply
only to &OPTIONAL parameters appearing in the top-level of the
lambda-list, or also to &OPTIONAL parameters embedded inside of nested
lambda-lists?
(17) Clarify whether supplied-p parameters in a lambda list must be
bound after the corresponding &optional or &keyword parameter. CLtL
kind of implies they are bound after but doesn't say so explicitly or
provide any examples. I actually think it works out better
implementationally to bind supplied-p parameters before. Maybe this
should be left unspecified if we can't agree.
(18) I think we need to introduce a new kind of error (READER-ERROR)
to handle reader syntax errors. PROGRAM-ERROR ought to be reserved
for errors in program tree structure.
(19) In the continuing saga of the hash table morass, it still needs
to be clarified that the consequences are undefined if components of a
structured object that would be recursively traversed by the :test
predicate are destructively modified while that object is being used
as a key in a hash table.
(20) In the list of three exceptions in issue
LISP-SYMBOL-REDEFINITION, does "defined" mean "defined by the
standard" or "defined (bound) in a particular implementation"?
(21) I still think we blew it on all those pathname issues..... The
mess seems worse than it did before.
(22) Can we require executing a declaration in the wrong place to
signal a PROGRAM-ERROR? If the declaration appears lexically within a
form that is processed by COMPILE or COMPILE-FILE the compiler should
be required to signal the error, otherwise if the enclosing form is
processed by EVAL it should be left unspecified whether the error is
signalled at that time or when the form is actually executed.
(23) Does the implicit BLOCK that surrounds DEFMACRO/MACROLET/DEFTYPE/etc
surround the destructuring bindings or only the body? The question is
whether the BLOCK is visible during the evaluation of &optional and
&key defaults and &aux parameters.
(24) In what order is the &environment variable bound with respect to
the other lambda variables in a DEFMACRO-style lambda list? I assume
it is always bound before regardless of where it actually appears in
the lambda list. I also assume that the other lambda variables are
bound left-to-right as they are in an ordinary lambda list.
(25) I think we should require a PROGRAM-ERROR to be signalled if there
is no matching tag for a GO or block name for a RETURN-FROM. This should
be a "compile-time" error.
(26) For consistency with other parts of the language, the second return
value from MACROEXPAND, MACROEXPAND-1, COMPILER-MACROEXPAND, and
COMPILER-MACROEXPAND-1 when the form does represent a macro call
ought to be specified as "true" rather than "T".
-------
∂08-Oct-89 1846 X3J13-mailer more cleanups
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 89 18:46:30 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA00015; Sun, 8 Oct 89 18:46:52 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA02620; Sun, 8 Oct 89 18:47:13 PDT
Message-Id: <8910090147.AA02620@masunter.parc.xerox.com>
Date: Sun, 8 Oct 89 18:47:13 PDT
From: <masinter@parc.xerox.com>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sun, 8 Oct 89 15:08:39 MDT <8910082108.AA18897@defun.utah.edu>
Subject: more cleanups
Reply-To: masinter@parc.xerox.com
I think people should prepare "cleanup-style" writeups for any
substantive changes to the standard, where there's some debate about
the issue. You have to use your judgement about what is substantive,
and whether you think there would be some debate about the change.
The cleanup form is useful in making sure the issues are addressed,
and give us a record of our decisions.
I don't think previous process (where the cleanup subcommittee debated
issues before bringing them to the main committee) is appropriate at
this time; I'd just as soon see this happen in the 'committee of the
whole' if at all.
(1) Remove the requirement that STEP be implementing using *EVALHOOK* ...
Why is this a good idea? I don't think we should consider removing or
deprecating *APPLYHOOK* or *EVALHOOK* at this point. Let sleeping
EVALHOOKs step.
(2) INSPECT ought to return its argument ...
From RETURN-VALUES-UNDERSPECIFIED early discussion (which was
unfortunately omitted from the final version of the proposal):
>Masinter believes that it is marginally more useful to say that
>INSPECT returns the item inspected. Some interactive inspectors might
>allow you to return a new value as the value of INSPECT, e.g., (SETQ X
>(INSPECT X)). GLS disagrees. If one regards INSPECT as a tool in the
>interactive interface, it can be a real nuisance to inspect some huge
>data structure and then when you finish it insists on printing 300
>lines of gobbledygook at you.
This was removed from the discussion because I agreed with Guy.
(3) "Requiring an error to be signalled in the case of a SPECIAL
declaration in SYMBOL-MACROLET is bogus ..."
If I understand your line of reasoning, its "we should remove the
requirement that an error be signalled because there are other ways
that you could get screwed that are equally as bad?" I don't buy that.
In general, I think the standard should try to require that errors be
signalled for run-time errors, and make fewer requirements about where
or when syntactic-type errors are detected, but since this is what we
passed and it isn't clearly *wrong*, why don't we leave it?
"... Also, if TYPE declarations can apply to symbol macros, it seems
like for symmetry that ..."
I don't think "symmetry" ever is the foundation of a good argument for
adding features. Simplicity, consistency, elegance, ease of use --
sometimes you can gain those by paying attention to symmetry. However,
allowing FTYPE declarations to apply to ordinary macros doesn't seem
to improve simplicity, elegance, ease of use for me, and consistency
is debatable.
"Actually, I'd suggest not allowing TYPE declarations to apply ..."
The issue SYMBOL-MACROLET-DECLARE, passed at the January 89 X3J13
meeting, allowed this. I don't recall much discussion at the meeting,
but there were enough messages about it (not all of which are
collected in my archives, e.g., there's a message from Moon that
references some previous mail, presumably about the SYMBOL-MACROLET
issue itself.)
(4) There's a problem with DEFINE-DECLARATION ...
This should be handled, if at all, as an amendment to
syntactic-environment-access, which passed June 89, right?
(5)-(8) These should be handled as cleanups if you have proposals to
make, but I don't think I understand what the individual issues or
proposals are. (Some of your points are just questions. At some
point, if the wording is vague and we mean the standard to remain
vague, we need not act.)
I think we could bundle 9-12 together.
(9) "Do the symbols which name DEFSTRUCT slots actaully appear as
lambda variables in the default keyword constructor function? ..."
Yes
(10) "Is it permissible for the (:CONSTRUCTOR <name>) DEFSTRUCT option
to appear multiple times ..."
Yes
(11) "... what is the right error terminology for other kinds of
syntactic errors in ..."
I don't know. Do we need any?
(12) "Does using :CONSTRUCTOR to specify a BOA constructor disable
DEFSTRUCT ..."
Yes. (I think current practice here varies. I remember reasoning that
if you wanted both, you could always ask for both, given (10).)
(13) "State explicity that although ... circular structures .."
I think this is implicit in the definition of s-expressions.
There's only so much "spelling out" we can do.
(14) "Is it permissible for the expansion of a standard Common Lisp
macro ... to contain syntax which is not part of Common Lisp ..."
No. Non-standard special forms, yes. (Some folks consider "special
forms" as a kind of syntax.) This is implied already.
(15) "I think we ought to reconsider issue DEFINE-COMPILER-MACRO since ..."
OK with me.
(16) (DEFTYPE &OPTIONAL's default * all the way down?)
That's what those words mean to me. Seems OK, so lets leave it.
(17) supplied-p parameters should be bound in the left-right order in
which they are visible. Example:
(lambda (a b &key (c 10000 c-supplied) (d (if c-supplied (/ 1 c) 0)))
If c is given, d defaults to 1/c; if c isn't given, d defaults to 0.
Does this need a cleanup? Any objections? LAMBDA-SUPPLIED-P-BIND-ORDER?
(18) ... new kind of error READER-ERROR ...
OK with me. But we don't need to add every kind of error to the
standard, do we?
(19) (hash-table clarification)
I think what JonL was trying to say is that that this can be
accomplished by a careful definition of "hash-table" in the glossary.
("A hash-table is a table for which the consequences are undefined if
..." :-)
(20) does "defined" mean "defined by the standard" or "defined (bound)
in a particular implementation"
The issue PACKAGE-CLUTTER effectively says that those are the same for
symbols in the COMMON-LISP package. If you think there's a difference,
LISP-SYMBOL-REDEFINITION means "defined by the standard".
(21) ... pathname ...
Have you changed your mind on any individual pathname issue, or have
any new arguments? Examples? Etc. I don't want to endlessly revisit
things that were voted on, but we've withdrawn issues before where
significant new arguments were advanced.
(22) "Can we require executing a declaration in the wrong place to
signal a PROGRAM-ERROR?"
We could, but I'd rather not. I'm for requiring specific errors to be
signalled at specific times only if I can imagine writing a portable
and useful program that might make meaningful use of such an error
being signalled. Unfortunately, my imagination is limited enough that
I'd only require that + signal an error when given a non-number, and
I'd leave the rest unspecified.
(23) Does the implicit BLOCK that surrounds DEFMACRO ... include the
arguments?
I remember debating this, but I don't remember it making it into a
cleanup issue. What I remember is that it would best serve users -- at
the expense of some implementation hair for some -- to wrap the block
around the arguments too, and that current practice differs.
In proposal "FUNCTION-NAME" we said:
Change the DEFUN macro to accept a function-name for its name argument,
instead of only accepting a symbol. If function-name is (SETF sym),
the body is surrounded by an implicit block named sym.
You could argue that "body" is ambigous here, too.
(24) In what order is the &environment ...
I'd say that the arguments should be bound left-to-right in the order
that they appear in the lambda-list. It doesn't matter much, its the
easiest to describe, and the implementation-pain is moot. Maybe this
could be bundled with (17).
(25) ... require a PROGRAM-ERROR to be signalled ...
Again, I'm not hot to require a lot of PROGRAM-ERROR signalling.
(26) ... true instead of T ...
Good idea. Amazing how many users think true = T, too.
∂08-Oct-89 1922 X3J13-mailer Sins of omission
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Oct 89 19:22:49 PDT
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA00628; Sun, 8 Oct 89 19:25:46 PDT
Date: Sun, 8 Oct 1989 19:25:45 PDT
From: Tim Koschmann <tdk@sumex-aim.stanford.edu>
To: x3j13@sail.stanford.edu
Subject: Sins of omission
Message-Id: <CMM.0.88.623903145.tdk@sumex-aim.stanford.edu>
I think that committee members should also be reviewing the draft document
for completeness. This is at least as important as reviewing it for
adherence, accuracy and consistency, as suggested in Kathy's cover letter.
For example, the generic function class-changed does not appear in the list
of defined names in the Table of Contents; nor do the functions cboundp,
cmakunbound, get-method and symbol-class. I also can't find the make-method
macro. This may reflect an oversight or merely a discrepancy between the
Table of Contents and the actual Chapters. (I can't say, since I have yet to
receive Chapters 6 and 7.)
I know that everyone is concerned about the size of the standard, but failing
to describe some of the built-in forms is probably not the best way to make
it shorter.
P.S.: I like the addition of the glossary, but where do we reference
'hermeneutics' in the standard?
∂09-Oct-89 1022 X3J13-mailer issue EVALHOOK-STEP-CONFUSION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Oct 89 10:22:20 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA24673; Mon, 9 Oct 89 11:23:25 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA19593; Mon, 9 Oct 89 11:23:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910091723.AA19593@defun.utah.edu>
Date: Mon, 9 Oct 89 11:23:20 MDT
Subject: issue EVALHOOK-STEP-CONFUSION
To: x3j13@sail.stanford.edu
Here is the first of a series of cleanup issues drawn from the list I
mailed out earlier. This one is item 1 from the list. The rest will
be trickling out over the next few weeks as I find the time to write
them up.
Forum: Cleanup
Issue: EVALHOOK-STEP-CONFUSION
References: CLtL p 321, 323, 441
Issue STEP-ENVIRONMENT (passed)
Category: CHANGE/CLARIFICATION
Edit History: V1, 9 Oct 1989, Sandra Loosemore
Problem Description:
Common Lisp permits the evaluator to be implemented by compiling the
form before executing it, but notes that this techniques "renders the
EVALHOOK mechanism relatively useless" (CLtL p. 321).
CLtL also requires the STEP utility to be implemented in terms of
EVALHOOK (p. 323). The restriction against implementing STEP using
some other technique (such as annotations on code lexically within the
body of the STEP) that make more sense in a compiled-only
implementation is pointless. It is probably not even desirable for
STEP to be implemented with *EVALHOOK*, since this effectively causes
the stepper to break on user programs that also use *EVALHOOK*.
Proposal (EVALHOOK-STEP-CONFUSION:FIX):
(1) Clarify that there is no guarantee that the functions that are the
values of *EVALHOOK* and *APPLYHOOK* will ever be invoked during
evaluation.
(2) Remove the requirement that STEP be implemented using *EVALHOOK*.
Make it explicitly vague whether the scope of the code that is affected
by STEP is lexical or dynamic.
(3) Deprecate *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.
Rationale:
Point by point:
(1) This is merely an explicit statement of the status quo.
(2) This permits compiled-only implementations to support a STEP
utility that does something useful.
(3) The eval hook mechanism is a relic of a particular interpreter
implementation technique and really has no place in a language
standard, especially since one of the stated goals of the language is
consistency between compiled and interpreted code. Since there is no
guarantee that these functions will ever be invoked, portable programs
should not rely on them.
Current Practice:
According to Kent Pitman:
I'm told by the guys who did the Cloe implementation that indeed
neither evalhook nor step do much of anything useful. If I understood
them correctly, *evalhook* just never gets called, and step works by a
different mechanism that may work at a granularity different than what
people expect.
Loosemore has been implementing an evaluator for Utah Common Lisp that
uses a preprocessor to partially compile programs. The interpreter
for the processed code does support the use of an *evalhook*-like
special variable, but the information it is passed is in a different
format than that which *evalhook* requires. In particular, the object
representing the lexical environment contains only bindings and not
syntactic information such as macro definitions. It also supports a
variety of annotation-based program debugging hooks that are specified
by declarations. We are in the process of integrating the
preprocessor into the UCL compiler so that most of these debugging
hooks will also work in compiled code.
Cost to implementors:
None.
Cost to users:
None.
Benefits:
Users will not be misled into thinking *evalhook* is more portable
than it actually is.
Compiled-only implementations can make STEP do something reasonable.
Discussion:
There is an article by Parker in Lisp Pointers, Vol 1 #4 which
describes one approach for annotation-based debugging. Loosemore's
PhD dissertation (soon to be available as a UofU Tech Report) also
discusses alternate approaches for implementing program steppers.
-------
∂09-Oct-89 1156 X3J13-mailer Re: issue EVALHOOK-STEP-CONFUSION
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 9 Oct 89 11:49:40 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 9 Oct 89 14:49:46 EDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@sail.stanford.edu
Subject: Re: issue EVALHOOK-STEP-CONFUSION
In-reply-to: Your message of Mon, 09 Oct 89 11:23:20 -0600.
<8910091723.AA19593@defun.utah.edu>
Date: Mon, 09 Oct 89 14:49:40 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I am staying out of most of these discussions, but thought I'd throw in my
two cents' worth on this one: I would very much like to see evalhook and
applyhook removed from the standard. They have been a constant source of
confusion, and there are so many different interpretations of what these
hooks do that facilities built on top of them are not really very portable
in practice. I'm now convinced that a really good stepping package cannot
easily be written using these hooks, but must be integrated into the
interpreter of a given implementation.
-- Scott
∂09-Oct-89 1545 X3J13-mailer re: more cleanups
To: sandra%defun@CS.UTAH.EDU, masinter.pa@XEROX.COM
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from sandra%defun@cs.utah.edu sent Sun, 8 Oct 89 15:08:39 MDT.]
(5) The description of DEFGENERIC says that if the function-name
already names a generic function, "that generic function is modified".
That's pretty vague. What parts of the old definition are retained?
Well, there is some interpretation to be done, but I think it's specified
what happens from the description on page 4-16 along with the stuff on
the function page (not supplied).
If you do a second definition-like operation, you expect the new object to
conform to the new definition. I think it's reasonable to mention only
the differences from that model. The first difference is that the existing
object is modified and not replaced. The second is that the methods are
treated in a funny way (as the next paragraph suggests). The third is
that CHANGE-CLASS might be called (explained in the function pages).
``\item{\bull} If a generic function of the given name already exists,
the existing generic function object is modified. Methods specified
by the current {\bf defgeneric} form are added, and any methods in the
existing generic function that were defined by a previous {\bf
defgeneric} form are removed. Methods added by the current {\bf
defgeneric} form might replace methods defined by {\bf defmethod} or
{\bf defclass}. No other methods in the generic function are affected
or replaced.''
I suppose it wouldn't hurt to state this explicitly in the function pages.
For example, are methods from the old definition carried over?
This is explained in the quoted paragraph above.
What happens if the lambda list of the new generic function is not
congruent to that of the old definition?
From the function pages:
``If a {\bf defgeneric} form is evaluated and some methods for that generic
function have lambda-lists that are not congruent with that given in the
{\bf defgeneric} form, an error is signaled.''
I also think it is wrong to signal an error when an existing function or
macro is redefined as a generic function; it would make more sense and be
more consistent to say that DEFGENERIC always redefines the function (in
the same way that DEFUN does), or to leave the consequences of any
redefinition of a function/macro explicitly vague the same as we do for
redefinition of DEFSTRUCTs (issue DEFSTRUCT-REDEFINITION).
Here it is best to think in terms of development of CLOS programs. It
might be difficult to recover the definition of a generic function if you
accidentally redefine it. It is far less difficult with other definitions
where a single existing definitional form will re-create it. One could
argue that this is an environment issue, but I think it's worth while to
require implementations to take a little effort to keep users from being
screwed.
(6) Must the lambda variables specified in the generic function lambda
list actually be bound to the corresponding actual arguments by the
generic function? For lexical variables it shouldn't matter but what
if one of them has been proclaimed SPECIAL?
I think the specification states pretty clearly the use of this
lamba-list, though I think it is more clearly spelled out in the function
pages. It is used for congruence checking and for specifying the argument
precedence order.
(7) I'm not convinced that ENSURE-GENERIC-FUNCTION is really necessary.
To me it seems unlikely that users will want to use this function,
since they can get equivalent functionality by using DEFGENERIC or a
combination of SETF FDEFINITION with the GENERIC-FUNCTION macro.
Either provide an explicit motivation for it or get rid of it.
Hm, it's the thing that enables me to answer the other questions asked above!!!
Well, CLOS is designed in three layers: a user macro level (def<mumble>),
a functional level (ensure... and friends), and a meta-object level.
ENSURE-GENERIC-FUNCTION is the functional level that implements
DEFGENERIC. If we want to flush ENSURE-GENERIC-FUNCTION, then we should
reconsider the overall design of CLOS and flush quite a bit more of it for
consistency.
(8) I think the way method combinations work is far too complicated
and inefficient. Instead of building a piece of code at runtime for a
specific set of applicable methods, the method combination function
ought to work more like a macro or a SETF method and be a compile-time
transformation. (I.e., instead of passing it a list of methods, pass
it a variable which is bound to a list of methods when the method
combination function is invoked.) Have to think more about a specific
proposal.
Many would agree with you on the complexity of method combination. I think
the CLOS group put in a lot of effort to simplify existing practice on
this. It is not clear to me what a better solution would be except
that a method combination ought to return a function rather than a form,
but it's not clear to me what sort of abstraction it is. Solving this is,
from my perspective, a research topic.
I think the proper time for this to have been brought up was during the
extensive period when CLOS was under discussion. This part of CLOS is not
a nit to be easily picked at this stage.
All other comments about lack of clarity, though, need to be addressed.
All I'm trying to say in most of this message is that it is well-specified
what should happen, not that it is well-described what those
specifications are.
-rpg-
∂09-Oct-89 1627 X3J13-mailer re: more cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Oct 89 16:27:39 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA14036; Mon, 9 Oct 89 17:28:42 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA20071; Mon, 9 Oct 89 17:28:38 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910092328.AA20071@defun.utah.edu>
Date: Mon, 9 Oct 89 17:28:37 MDT
Subject: re: more cleanups
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: x3j13@SAIL.Stanford.EDU
In-Reply-To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, 09 Oct 89 1545 PDT
OK, I guess most of the answers to the questions I was asking are
there in the document somewhere. I was just having trouble finding
all the pieces.
The two substantive CLOS-related issues I raised (the redefinition of
generic functions and the overly-complex method combination) are issues
which seem likely to come up again during the public review period. I
believe we will have an obligation to consider these issues again at
that point, even if we decide not to consider them now.
About the method-combination issue, you write:
> Many would agree with you on the complexity of method combination. I think
> the CLOS group put in a lot of effort to simplify existing practice on
> this. It is not clear to me what a better solution would be except
> that a method combination ought to return a function rather than a form,
> but it's not clear to me what sort of abstraction it is. Solving this is,
> from my perspective, a research topic.
My response to this would have to be that it is inappropriate to
standardize anything that is still an open research issue. If you
think that it is too late to consider alternatives at this point,
perhaps the right thing to do is to back off entirely from including
user-defined method-combinations in this version of the standard.
-Sandra
-------
∂09-Oct-89 2101 X3J13-mailer re: more cleanups
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 9 Oct 89 21:00:52 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 672695; 9 Oct 89 23:27:52 EDT
Date: Mon, 9 Oct 89 23:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: more cleanups
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Dick Gabriel <RPG@SAIL.Stanford.EDU>, x3j13@SAIL.Stanford.EDU
In-Reply-To: <8910092328.AA20071@defun.utah.edu>
Message-ID: <19891010032959.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Mon, 9 Oct 89 17:28:37 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
About the method-combination issue, you write:
> Many would agree with you on the complexity of method combination. I think
> the CLOS group put in a lot of effort to simplify existing practice on
> this. It is not clear to me what a better solution would be except
> that a method combination ought to return a function rather than a form,
> but it's not clear to me what sort of abstraction it is. Solving this is,
> from my perspective, a research topic.
My response to this would have to be that it is inappropriate to
standardize anything that is still an open research issue.
I must point out that what Dick said was a research topic was not method
combination as such, but recasting method combination in terms of
function composition rather than in terms of form construction. I
believe the fact that that is an open research issue is precisely why
X3J13 is making no attempt to base the standard on such ideas, appealing
as they may be. Method combination itself is quite simple and has been
well understood and widely used (within the Flavors community) for ten
years. You might simply not have seen a good explanation of it. It's
as easy to understand as macros, which it very much resembles (program
construction by form composition); actually method combination is easier
to understand than macros, since there are no name scoping issues in
method combination.
Of course some Lisp dialects have not been willing to admit macros
either, until a researcher puts them on a sound theoretical basis.
That's a perfectly legitimate attitude, although such puritanism can
lead to languages that are difficult to use. Common Lisp takes a more
practical approach and is happy to take advantage of macros without
waiting for the open research issues to be closed.
∂10-Oct-89 1146 X3J13-mailer re: more cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Oct 89 08:27:45 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA05116; Tue, 10 Oct 89 09:28:24 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA20624; Tue, 10 Oct 89 09:27:00 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910101527.AA20624@defun.utah.edu>
Date: Tue, 10 Oct 89 09:26:58 MDT
Subject: re: more cleanups
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Dick Gabriel <RPG@SAIL.Stanford.EDU>, x3j13@SAIL.Stanford.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 9 Oct 89 23:29 EDT
> Date: Mon, 9 Oct 89 23:29 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> I must point out that what Dick said was a research topic was not method
> combination as such, but recasting method combination in terms of
> function composition rather than in terms of form construction. I
> believe the fact that that is an open research issue is precisely why
> X3J13 is making no attempt to base the standard on such ideas, appealing
> as they may be. Method combination itself is quite simple and has been
> well understood and widely used (within the Flavors community) for ten
> years. You might simply not have seen a good explanation of it. It's
> as easy to understand as macros, which it very much resembles (program
> construction by form composition); actually method combination is easier
> to understand than macros, since there are no name scoping issues in
> method combination.
There's one very big difference between macros and the current model
of define-method-combination. Macros involve strictly a compile-time
substitution, while method combination (at least conceptually)
involves constructing a piece of code *at run time* which must then be
explicitly evaluated by means of a call to EVAL. That's the part I'm
really bothered by.
Although I have not yet given it a great deal of thought, I can think
of two other approaches to method-combinations off the top of my head.
The first is what I mentioned in my previous message about retaining
the macro-like syntax but having the expansion happen at compile-time
rather than run-time. The second approach is to make the
method-combination functions be called at run-time but invoke the
methods directly, instead of building a piece of code to do so. I am
willing to spend some more time investigating these and putting
together sample implementations, but I doubt if I could do this in
time for the upcoming meeting.
As I said in my previous message, this issue is sure to come up during
the public review period, if for no other reason than that I will
bring it up again myself if nothing has been done about it in the
meantime. I had originally not intended to raise the issue until then
but everybody seemed anxious for me to reveal my list of gripes! So,
now that it has been raised, do we want to try to deal with it now or
wait until after the public review?
Incidentally, I am not familiar with the Flavors method combination
facilities (having used only the most basic features of Flavors). I
suspect most readers of the standard will be similarly ignorant, and
if the explanation of method-combinations in the standard can't stand
on its own, we've got some serious editorial problems.....
-Sandra
-------
∂10-Oct-89 1215 X3J13-mailer November Attendee List
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Oct 89 12:15:37 PDT
Received: from rose ([192.9.200.83]) by heavens-gate id AA22942g; Tue, 10 Oct 89 07:53:49 PDT
Received: by rose id AA01902g; Tue, 10 Oct 89 07:54:46 PDT
Date: Tue, 10 Oct 89 07:54:46 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8910101454.AA01902@rose>
To: x3j13@sail.stanford.edu
Subject: November Attendee List
Let me know if there are any changes.
Vegatarian plates are available on request.
---jan---
X3J13 Attendee Information
10/10/89
Name Institute Paid L1 L2 L3
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
George Hadden Honeywell -0- y y y
Steve Haflich Franz, Inc. -0- y y y
Timothy Koschmann Southern Illinois -0- y y y
Aaron Larson Honeywell -0- y y y
Joachim Laubsch HP Labs -0- y y y
Thom Linden IBM -0- - - -
David Loeffler MCC -0- y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines -0- y y y
Larry Masinter Xerox PARC -0- y y y
Robert Mathis CONTEL -0- y y y
Jarl Nilsson Franz -0- y y y
Chris Perdue Sun Microsystems -0- y - y
Kent Pitman Symbolics -0- y y y
Bills St. Clair Apple Computer -0- y y y
Guy Steele Thinking Machines -0- y y y
Paul Tucker IBM -0- y y y
Walter van Roggen DEC -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂10-Oct-89 1810 X3J13-mailer Sins of omission
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Oct 89 18:10:23 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 673317; 10 Oct 89 21:10:23 EDT
Date: Tue, 10 Oct 89 21:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sins of omission
To: Tim Koschmann <tdk@sumex-aim.stanford.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <CMM.0.88.623903145.tdk@sumex-aim.stanford.edu>
Message-ID: <19891011011211.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Sun, 8 Oct 1989 19:25:45 PDT
From: Tim Koschmann <tdk@sumex-aim.stanford.edu>
I think that committee members should also be reviewing the draft document
for completeness.
I think that's a reasonable thing to do. However...
For example, the generic function class-changed does not appear in the list
of defined names in the Table of Contents; nor do the functions cboundp,
cmakunbound, get-method and symbol-class.
...CLOS does not use any of those names. Perhaps you have CLOS mixed up
in your mind with PCL, an implementation that has been moving towards
CLOS but is not identical to CLOS. Actually I don't think PCL uses
those names any more either.
I also can't find the make-method
macro.
MAKE-METHOD is not a macro, but a special symbol recognized in one
special context. It's described on the same page as CALL-METHOD.
You're right that it would be a good idea to check that the more obscure
symbols, such as MAKE-METHOD, are not omitted from the index and table
of contents. A few of these, VARIABLE for example, were missing from
the index of CLtL.
No one answered my request a while back for a list of all the symbols
that are supposed to be in the COMMON-LISP package. At Symbolics we
think this list is 975 symbols long, but we've probably made some
mistakes. For comparison, the CLtL LISP package has 775 symbols.
∂11-Oct-89 1035 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Oct 89 10:35:36 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA22140; Wed, 11 Oct 89 11:36:39 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA21677; Wed, 11 Oct 89 11:36:34 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910111736.AA21677@defun.utah.edu>
Date: Wed, 11 Oct 89 11:36:32 MDT
Subject: issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
To: x3j13@sail.stanford.edu
This is issue #9 from the list I distributed earlier.
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
References: DEFSTRUCT; CLtL p. 309
Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (passed)
Category: CLARIFICATION, CHANGE
Edit History: V1, 11 Oct 1989, Sandra Loosemore
Problem Description:
Must the symbols which name DEFSTRUCT slots be bound as lambda
variables by the default keyword constructor function? Normally it
would not matter, but if any of these symbols have been proclaimed
SPECIAL it will affect the dynamic environment in which the slot init
forms are evaluated.
There are three proposals, BOUND, NOT-BOUND, and VISIBLY-BOUND.
Background:
CLtL requires each default slot init form to be evaluated "in the
lexical environment of the DEFSTRUCT form in which it appeared". This
means that the obvious technique of supplying the init forms as the
defaults for the keyword arguments in the lambda list of the
constructor function is incorrect, unless care is taken to avoid
shadowing any variable bindings of the symbols which correspond to
those arguments.
For example, given
(defstruct foo
(a <a-init>)
(b <b-init>)
(c <c-init>))
Generating the constructor as
(defun make-foo (&key (a <a-init>) (b <b-init>) (c <c-init>)) ...)
may not evaluate <b-init> and <c-init> in the correct lexical environment
as specified in CLtL. Proposal VISIBLY-BOUND would change the specification
to make this the correct behavior.
One alternative is to wrap the init forms in closures named with gensyms:
(flet ((#:g1 () <a-init>)
(#:g2 () <b-init>)
(#:g3 () <c-init>))
(defun make-foo (&key (a (#:g1)) (b (#:g2)) (c (#:g3))) ...))
Under proposal BOUND, this would be the correct way to implement the
constructor function.
Another alternative is to make the lambda variables themselves gensyms:
(defun make-foo (&key ((:a #:g4) <a-init>)
((:b #:g5) <b-init>)
((:c #:g6) <c-init>)) ...)
Under proposal NOT-BOUND, this would be the correct way to implement the
constructor function.
(Of course, it's possible that DEFSTRUCT could produce a simplified
expansion in many cases by examining the init forms and/or lexical
environment.)
Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE implies that BOA constructors
do bind the symbols which name slots as lambda variables, since these
variables can be referenced in the init forms for subsequent
arguments.
Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:BOUND):
Clarify that the symbols which name slots must be bound as lambda
variables by the keyword constructor function, in the order in which
the slots are specified in the DEFSTRUCT form. Variables for
inherited slots are bound before variables for explitly specified
slots, in the order in which they were specified in the definition of
the inherited structure. Special bindings of these variables will be
visible during the evaluation of the default init forms for subsequent
slots. The slot default init forms are still evaluated in the
lexical environment in which the DEFSTRUCT form itself appears.
Rationale:
This appears to be closest to the intent of CLtL.
Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND):
Clarify that the symbols which name slots must *not* be bound as
lambda variables by the keyword constructor function. The slot
default init forms are evaluated in the lexical and dynamic
environment in which the DEFSTRUCT form itself appears.
Rationale:
This avoids the overhead of creating and invoking closures to compute
the default values of the slots for the default keyword constructor.
Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:VISIBLY-BOUND):
Clarify that the symbols which name slots must be bound as lambda
variables by the keyword constructor function, in the order in which
the slots are specified in the DEFSTRUCT form. Variables for
inherited slots are bound before variables for explitly specified
slots, in the order in which they were specified in the definition of
the inherited structure. Special bindings of these variables will be
visible during the evaluation of the default init forms for subsequent
slots.
Remove the requirement that the slot default init forms be evaluated
in the lexical environment in which the DEFSTRUCT form itself appears.
Instead, require that they be evaluated in a lexical environment that
contains bindings for the previous lambda variables of the constructor
function. This applies to both the default keyword constructor function
and BOA constructors.
Rationale:
This alternative corresponds most closely to current practice. It
avoids the overhead of creating and invoking closures to compute the
default values of the slots for both the default keyword constructor
and BOA constructors.
Example/Test Cases:
(defvar x 'global-x)
(let ((y 'local-y))
(defstruct baz (x 'x-init) (y x) (z y)))
(make-baz)
Under proposal BOUND,
slot X is initialized to X-INIT
slot Y is initialized to X-INIT
(since the init form X is evaluated in the dynamic environment
containing the binding to X-INIT)
slot Z is initialized to LOCAL-Y
(since the init form Y is evaluated in the lexical environment in
which the DEFSTRUCT appears)
Under proposal NOT-BOUND,
slot X is initialized to X-INIT
slot Y is initialized to GLOBAL-X
(since the constructor does not rebind the special variable X)
slot Z is initialized to LOCAL-Y
Under proposal VISIBLY-BOUND,
slot X is initialized to X-INIT
slot Y is initialized to X-INIT
(since the special binding of X made by the constructor is visible)
slot Z is initialized to X-INIT
(since the lexical binding of Y made by the constructor is visible)
Current Practice:
Most implementations (including Lucid CL, HPCL-I, KCL, CMU Common Lisp)
appear to implement proposal VISIBLY-BOUND even though it is in conflict
with what is required by CLtL.
Utah Common Lisp currently implements proposal NOT-BOUND.
Cost to implementors:
For proposal BOUND, the cost of implementing the proposal correctly is
fairly small. The cost of implementing it both correctly and efficiently
is potentially much larger.
For proposal NOT-BOUND, the implementation cost is again fairly small,
but it still requires essentially the same work as in proposal BOUND to
handle BOA constructors correctly.
Proposal VISIBLY-BOUND has the least implementation cost, since this
is what most implementations already do and is the least complicated
of the alternatives.
Cost to users:
Adopting any of these proposals would improve the situation faced by
users now.
Users may find proposal VISIBLY-BOUND to be marginally more useful
than the other alternatives since it allows the values of slots to be
referenced in the subsequent default init forms.
Benefits:
An area of confusion in the language is removed.
Discussion:
Loosemore doesn't care much about which of these alternatives we
adopt, but thinks that leaving this unspecified would be a mistake.
-------
∂11-Oct-89 1403 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-OPTIONS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Oct 89 14:02:50 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA00375; Wed, 11 Oct 89 15:03:39 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA21802; Wed, 11 Oct 89 15:03:36 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910112103.AA21802@defun.utah.edu>
Date: Wed, 11 Oct 89 15:03:34 MDT
Subject: issue DEFSTRUCT-CONSTRUCTOR-OPTIONS
To: x3j13@sail.stanford.edu
This includes issues 10 and 12 from my list.
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-OPTIONS
References: DEFSTRUCT; CLtL p. 309, 311, 315-316
Category: CLARIFICATION
Edit History: V1, 11 Oct 1989, Sandra Loosemore
Problem Description:
It is permitted to specify multiple :constructor options to DEFSTRUCT,
but the interactions between them are unclear.
Is it legitimate to specify multiple (:constructor <name>) options to
DEFSTRUCT to get multiple copies of the default keyword constructor
function?
Does specifying an explicit :constructor option inhibit DEFSTRUCT from
creating the default keyword constructor or does one have to
explicitly say (:constructor nil)?
Proposal (DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT):
Clarify that DEFSTRUCT creates the default keyword constructor only if
no explicit :constructor options are specified, or if the :constructor
option is specified without an argument.
(:constructor nil) is meaningful only when there are no other
:constructor options specified. It prevents DEFSTRUCT from generating
any constructors at all.
Otherwise, DEFSTRUCT builds a constructor function corresponding to
each supplied :constructor option. It is permissible to specify both
multiple BOA constructors and multiple keyword constructors.
Rationale:
This proposal treats all of the :constructor options uniformly as a
group. Instead of viewing each individual option as something that
adds to or modifies the behavior, the entire set of specified
:constructor options taken as a whole tell DEFSTRUCT to do something
*instead of* its default behavior. Treating all :constructor options
uniformly in this respect should make the behavior easier to
understand.
Current Practice:
Varies widely.
Lucid Common Lisp and Kyoto Common Lisp appear to implement this
proposal.
Utah Common Lisp currently allows only one keyword constructor. If a
(:constructor name) option appears more than once, it ignores all but
one. It always makes a keyword constructor unless (:constructor nil)
is explicitly specified, even if BOA constructors are explicitly
requested. CMU Common Lisp appears to behave in the same way.
HPCL-I signals an error if multiple (:constructor name) options appear.
It also always makes a keyword constructor unless (:constructor nil) is
explicitly specified.
Cost to implementors:
Probably wouldn't take more than a few hours to fix.
Cost to users:
Code (that is currently nonportable anyway) that assumes the default
keyword constructor will be created unless it is explictly disabled
with (:constructor nil) would have to be changed.
Benefits:
Increased portability of application code using DEFSTRUCT.
Discussion:
Loosemore supports this proposal even though she would have to fix UCL
to conform to it.
-------
∂11-Oct-89 1547 X3J13-mailer issue DEFSTRUCT-SYNTAX-ERRORS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Oct 89 15:47:08 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA04450; Wed, 11 Oct 89 16:48:12 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA21896; Wed, 11 Oct 89 16:48:09 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910112248.AA21896@defun.utah.edu>
Date: Wed, 11 Oct 89 16:48:08 MDT
Subject: issue DEFSTRUCT-SYNTAX-ERRORS
To: x3j13@sail.stanford.edu
Here is a first cut at this issue (#11 from my list). Those of you
who have been reviewing the draft standard might have noted that the
"Conditions" section of the DEFSTRUCT specification is currently
totally empty. I don't claim that this list of errors is definitive
and we might want to add or remove some.
Forum: Cleanup
Issue: DEFSTRUCT-SYNTAX-ERRORS
References: DEFSTRUCT
Issue DEFSTRUCT-CONSTRUCTOR-OPTIONS
Issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Category: CLARIFICATION
Edit History: V1, 11 Oct 1989, Sandra Loosemore
Problem Description:
Some of the defining macros which have been newly added to the
language are quite specific about detection of certain kinds of syntax
errors (such as multiple occurrences of options that can be specified
at most once) that are detectable at macroexpansion time. For
example, the DEFPACKAGE specification says errors "should be
signalled" in certain circumstances, and the DEFCLASS specification
says errors "are signalled" in similar circumstances.
Is the DEFSTRUCT macro required to detect and signal similar syntactic
errors?
Proposal (DEFSTRUCT-SYNTAX-ERRORS:SHOULD-SIGNAL):
If any of the following kinds of syntactic errors occur in a call to
DEFSTRUCT, an error of type PROGRAM-ERROR should be signalled at the time
the DEFSTRUCT macro is expanded.
(1) Any structure option not recognized by the implementation.
(Implementations might support options not described in the standard.)
(2) Multiple occurrences of the :conc-name, :copier, :predicate,
:include, :print-function, :type, :named, or :initial-offset options.
(3) Specifying both (:constructor nil) and any other :constructor option.
(Assumes proposal DEFSTRUCT-CONSTRUCTOR-OPTIONS:EXPLICIT passes.)
(4) :include'ing a type that has not previously been defined with DEFSTRUCT.
(5) :include'ing a type that was specified with a :type (or lack of :type)
that does not match the :type (or lack of :type) of the structure
being defined.
(6) Specifying slot descriptions with :include that do not name slots from
the include'd type.
(7) Specifying both :print-function and :type.
(8) Specifying a :type structure option that is not recognized by the
implementation. (Implementations might support :types not described
in the standard.)
(9) Specifying :named without also specifying :type.
(10) Specifying :initial-offset without also specifying :type.
(11) Specifying :predicate (except (:predicate nil)) when :type has been
specified but not :named.
(12) Any slot options not recognized by the implementation. (Implementations
might support slot options not described in the standard.)
(13) Specifying multiple slots with names that are STRING=.
(14) Multiple occurrences of slot options :TYPE and :READ-ONLY within
a single slot description.
Rationale:
Items 7, 9, 10. and 11 are explicitly mentioned as being invalid in
CLtL.
Item 13 is stated in issue DEFSTRUCT-SLOTS-CONSTRAINTS-NAME.
Item 5 is implied by the statement in CLtL that accessors for the
:include'd type work on instances of the type that includes it.
The remaining items are fairly easy to detect and signalling an error
can prevent users from doing something they didn't intend to.
This list does not include some other situations that CLtL also
mentions as being invalid that deal with type specifiers, such as
using a :type slot option that is not recognized as a valid type
specifier. The approach we have taken in the past (issue
COMPILE-ENVIRONMENT-CONSISTENCY) with problems relating to undefined
type specifiers in declarations is that it might be appropriate to
signal a warning but that the situation is not in error.
Current Practice:
Utah Common Lisp detects all of these except for items 2, 3, and 14.
It also checks for missing arguments to those options that require
them and for the arguments to :predicate, :copier, etc. being symbols.
Kyoto Common Lisp detects items 1, 3, 4, 7, 8, 11, and 12. It also
signals an error if a slot is specified in the :include'd type but
not in the :include'ing type, and for invalid BOA-constructor syntax.
CMU Common Lisp detects items 1, 4, 6, 8, and 12. It also signals an
error when there is not an argument supplied for a structure option
that requires one, and when there is an argument supplied for a
structure option that cannot accept one.
Cost to implementors:
Should not be too great. A few hours, maybe?
Cost to users:
None.
Benefits:
Early detection of mistakes by users.
Consistency with other parts of the language.
Discussion:
We should probably consider making all of the defining macros
consistent with regard to "must signal"/"should signal".
-------
∂12-Oct-89 0625 X3J13-mailer more cleanups
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Oct 89 06:25:17 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08935g; Thu, 12 Oct 89 06:24:04 PDT
Received: by bhopal id AA03268g; Thu, 12 Oct 89 06:26:02 PDT
Date: Thu, 12 Oct 89 06:26:02 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910121326.AA03268@bhopal>
To: sandra%defun@cs.utah.edu
Cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sun, 8 Oct 89 15:08:39 MDT <8910082108.AA18897@defun.utah.edu>
Subject: more cleanups
re: (19) In the continuing saga of the hash table morass, it still needs
to be clarified that the consequences are undefined if components of a
structured object that would be recursively traversed by the :test
predicate are destructively modified while that object is being used
as a key in a hash table.
This does not need "clarification" since it is a primitive property of
equivalence relations [and the key comparison is always done with
respect to some equivalence relation e.g., EQ, EQL, EQUAL, EQUALP.]
What probably does need to be clarified is the following point. But
I don't see that it needs to be elucidated in the standard -- it only
needs to be brought up because of the people who keep misunderstanding
this point. Many otherwise bright programmers have incorrectly assumed
that entering a key into a hash table enters the identical EQ object into
the hash table, so that subsequent updates to the original argument will
necessarily affect the equivalence relation in the table. It may and it
may not -- but there is nothing in CLtL that requires this sort of
implementation (except for EQ/EQL tables!, but then subsequent updates
don't affect the equivalence relation).
Please note that the *only* requirement for the keys of a hash table
is that they be equivalent to the original entering argument by the
equivalence relation of the hash table. In this regard, the wording
on CLtL p284 is somewhat deceptive, being far too EQ-centric:
"GETHASH finds the entry in 'hash-table' whose key is 'key', and
returns the associated value."
A slightly less misleading version would say:
"GETHASH finds the entry in 'hash-table' whose key is equivalent to
'key' under 'hash-table's equivalence relation, and returns the
associated value."
Similarly, when talking about SETF of GETHASH, rather than saying:
"...an entry with the specified 'key'..."
it could better say:
"...an entry with an equivalent specified 'key'..."
Unlike that for alists, the internal structure of hash-tables is opaque
to the end user.
These slightly extended sentences could surely be added in an editorial
process, without the need for cleanup review.
-- JonL --
∂12-Oct-89 0740 X3J13-mailer Re: more cleanups
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Oct 89 07:40:34 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15155; Thu, 12 Oct 89 08:41:31 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA22619; Thu, 12 Oct 89 08:41:28 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910121441.AA22619@defun.utah.edu>
Date: Thu, 12 Oct 89 08:41:27 MDT
Subject: Re: more cleanups
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Thu, 12 Oct 89 06:26:02 PDT
> Date: Thu, 12 Oct 89 06:26:02 PDT
> From: Jon L White <jonl@lucid.com>
>
> What probably does need to be clarified is the following point. But
> I don't see that it needs to be elucidated in the standard -- it only
> needs to be brought up because of the people who keep misunderstanding
> this point. Many otherwise bright programmers have incorrectly assumed
> that entering a key into a hash table enters the identical EQ object into
> the hash table, so that subsequent updates to the original argument will
> necessarily affect the equivalence relation in the table. It may and it
> may not -- but there is nothing in CLtL that requires this sort of
> implementation (except for EQ/EQL tables!, but then subsequent updates
> don't affect the equivalence relation).
I think the continuing confusion over this point is precisely why it
needs to be stated explicitly in the standard. If we say nothing
about destructive operations being a potential source of problems, it
could possibly be construed as a requirement that hash tables be
implemented in such a way that that destructive operations *must not*
cause problems (i.e., a requirement that keys be "copied" where
appropriate). I happen to agree with your interpretation that it was
not the intent of CLtL to make this requirement.
Your proposed changes to the CLtL wording are certainly an improvement
but I don't think they go quite far enough in addressing this problem
directly. Perhaps if there is really serious disagreement about
whether it is appropriate to mention destructive operations on keys in
the standard, we could compromise by putting it in the "Notes" section
(which is not officially part of the standard)?
I don't care much whether this is resolved by a vote on a cleanup
issue or by the drafting committee as an editorial tweak, as long as
something is done about it. I noted this problem while reviewing the
latest draft but thought it might be better raised as a substantive
issue to X3J13 as a whole in light of the past controversy over hash
table clarifications.
-Sandra
-------
∂12-Oct-89 1106 X3J13-mailer more cleanups
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Oct 89 11:06:30 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA04542; Thu, 12 Oct 89 11:00:56 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA01399; Thu, 12 Oct 89 10:59:04 PDT
Message-Id: <8910121759.AA01399@masunter.parc.xerox.com>
Date: Thu, 12 Oct 89 10:59:04 PDT
From: <masinter@parc.xerox.com>
To: sandra%defun@cs.utah.edu
Cc: jonl@lucid.com, sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 12 Oct 89 08:41:27 MDT <8910121441.AA22619@defun.utah.edu>
Subject: more cleanups
Reply-To: masinter@parc.xerox.com
I don't think this is a "substantive issue", since, while "some people"
might miscontrue the standard to mean that hash table entries of EQUAL
hash tables must be copied, I don't think any current implementation
does it that way, and I don't think any of us take it to mean that.
(I think we need to add "substantive issue" and "editorial tweak" to
the meta-glossary, along with "hokey-pokey" and a few other terms.)
∂12-Oct-89 1203 X3J13-mailer more cleanups
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 12 Oct 89 12:02:56 PDT
Received: from fafnir.think.com by Think.COM; Thu, 12 Oct 89 15:05:16 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 12 Oct 89 15:01:06 EDT
Received: by verdi.think.com; Thu, 12 Oct 89 15:01:07 EDT
Date: Thu, 12 Oct 89 15:01:07 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8910121901.AA13404@verdi.think.com>
To: masinter@parc.xerox.com
Cc: sandra%defun@cs.utah.edu, jonl@lucid.com, sandra%defun@cs.utah.edu,
x3j13@sail.stanford.edu
In-Reply-To: <masinter@parc.xerox.com>'s message of Thu, 12 Oct 89 10:59:04 PDT <8910121759.AA01399@masunter.parc.xerox.com>
Subject: more cleanups
Date: Thu, 12 Oct 89 10:59:04 PDT
From: <masinter@parc.xerox.com>
...
(I think we need to add "substantive issue" and "editorial tweak" to
the meta-glossary, along with "hokey-pokey" and a few other terms.)
Two Common Lisp functions are "similar as a codehack" if they have the
same control structure, there is an isomorphism mapping variable names in
one to variable names in the other, and the names are equally silly in each.
∂13-Oct-89 0048 X3J13-mailer completeness of the draft
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 89 00:48:25 PDT
Received: from relay.cc.u-tokyo.ac.jp ([192.41.197.3]) by argus.Stanford.EDU with TCP; Fri, 13 Oct 89 00:45:19 PDT
Received: from ccut.cc.u-tokyo.ac.jp by relay.cc.u-tokyo.ac.jp (5.61/2.3W-relay)
id AA12070; Fri, 13 Oct 89 16:49:43 +0900
Received: from aoyama.cc.aoyama.ac.jp by ccut.cc.u-tokyo.ac.jp (5.61/6.4J.6-ut1.66)
id AA25014; Fri, 13 Oct 89 16:52:37 +0900
Received: by aoyama.cc.aoyama.ac.jp (4.0/6.4J.6-agu4)
id AA17912; Fri, 13 Oct 89 16:48:22 JST
Received: by kepa.cc.aoyama.ac.jp (4.0/6.4J.5-aguac)
id AA04612; Fri, 13 Oct 89 16:48:25 JST
Date: Fri, 13 Oct 89 16:48:25 JST
From: Masayuki Ida <ida@cc.aoyama.ac.jp>
Return-Path: <ida@cc.aoyama.ac.jp>
Message-Id: <8910130748.AA04612@kepa.cc.aoyama.ac.jp>
To: x3j13@sail.stanford.edu
Cc: ida@cc.aoyama.ac.jp
Subject: completeness of the draft
I received the second part of the review copy.
I have the following comments as for the completeness of the draft.
Many defined names, say 1+,...,car,...., are dropped in 6.2,
though the table of contents for 6.2 which was included in the first part
has them.
I also feel curious to see the 6.2 starts with 'adjust-array'
which I don't think the first one in alphabetic order.
Am I losing something ?
Masayuki Ida
∂13-Oct-89 0059 X3J13-mailer Issues COMPILER-VERBOSITY, LOAD-TRUENAME
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 13 Oct 89 00:59:22 PDT
Received: from fafnir.think.com by Think.COM; Fri, 13 Oct 89 04:01:57 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 13 Oct 89 03:57:48 EDT
Received: by verdi.think.com; Fri, 13 Oct 89 03:57:47 EDT
Date: Fri, 13 Oct 89 03:57:47 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8910130757.AA15399@verdi.think.com>
To: x3j13@sail.stanford.edu
Subject: Issues COMPILER-VERBOSITY, LOAD-TRUENAME
We currently have the following asymmetric set of names:
*load-truename* *compile-file-truename*
*load-pathname* *compile-file-pathname*
*load-verbose* *compile-verbose*
*load-print* *compile-print*
Proposal: rename *compile-verbose* => *compile-file-verbose*
and *compile-print* => *compile-file-print*
--Guy
∂13-Oct-89 0951 X3J13-mailer Issues COMPILER-VERBOSITY, LOAD-TRUENAME
Received: from arisia (arisia.Xerox.COM) by SAIL.Stanford.EDU with TCP; 13 Oct 89 09:50:59 PDT
Received: from masunter.parc.Xerox.COM by arisia with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA04543; Fri, 13 Oct 89 09:51:06 -0700
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00526; Fri, 13 Oct 89 09:49:21 PDT
Message-Id: <8910131649.AA00526@masunter.parc.xerox.com>
Date: Fri, 13 Oct 89 09:49:21 PDT
From: <masinter@arisia>
To: gls@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: Guy Steele's message of Fri, 13 Oct 89 03:57:47 EDT <8910130757.AA15399@verdi.think.com>
Subject: Issues COMPILER-VERBOSITY, LOAD-TRUENAME
Reply-To: Masinter@arisia
Well, I don't think the names are any more asymmetric than the
situation. On the one hand, there's LOAD, and on the other, there's
COMPILE and COMPILE-FILE. COMPILE-FILE and COMPILE share some
behavior, namely that controlled by *compile-verbose* and
*compile-print*, but the -truename* and -pathname* variables only
apply to COMPILE-FILE.
∂13-Oct-89 1033 X3J13-mailer Re: Issues COMPILER-VERBOSITY, LOAD-TRUENAME
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 89 10:33:44 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA24416; Fri, 13 Oct 89 11:34:38 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA23824; Fri, 13 Oct 89 11:34:36 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910131734.AA23824@defun.utah.edu>
Date: Fri, 13 Oct 89 11:34:35 MDT
Subject: Re: Issues COMPILER-VERBOSITY, LOAD-TRUENAME
To: Masinter@arisia
Cc: gls@Think.COM, x3j13@sail.stanford.edu
In-Reply-To: Masinter@arisia, Fri, 13 Oct 89 09:49:21 PDT
*COMPILE-VERBOSE* and *COMPILE-PRINT* are only supposed to affect the
behavior of COMPILE-FILE, not COMPILE. (See issue COMPILER-VERBOSITY.)
Changing the names seems reasonable to me.
-Sandra
-------
∂13-Oct-89 1222 X3J13-mailer Issues COMPILER-VERBOSITY, LOAD-TRUENAME
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 13 Oct 89 12:22:32 PDT
Received: from fafnir.think.com by Think.COM; Fri, 13 Oct 89 15:25:01 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 13 Oct 89 15:20:47 EDT
Received: by verdi.think.com; Fri, 13 Oct 89 15:20:45 EDT
Date: Fri, 13 Oct 89 15:20:45 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8910131920.AA16571@verdi.think.com>
To: Masinter@arisia.arpa
Cc: gls@Think.COM, x3j13@sail.stanford.edu
In-Reply-To: <masinter@arisia.arpa>'s message of Fri, 13 Oct 89 09:49:21 PDT <8910131649.AA00526@masunter.parc.xerox.com>
Subject: Issues COMPILER-VERBOSITY, LOAD-TRUENAME
Date: Fri, 13 Oct 89 09:49:21 PDT
From: <masinter@arisia.arpa>
Well, I don't think the names are any more asymmetric than the
situation. On the one hand, there's LOAD, and on the other, there's
COMPILE and COMPILE-FILE. COMPILE-FILE and COMPILE share some
behavior, namely that controlled by *compile-verbose* and
*compile-print*, but the -truename* and -pathname* variables only
apply to COMPILE-FILE.
No, according to issue COMPILER-VERBOSITY, *compile-verbose* and
*compile-print* apply only to compile-file.
--Guy
∂15-Oct-89 0954 X3J13-mailer more standards
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 15 Oct 89 09:54:00 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa07189; 15 Oct 89 17:31 BST
Date: Sun, 15 Oct 89 17:42:50 BST
Message-Id: <14127.8910151642@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: more standards
To: rpg@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
What happened in Sendai?
∂16-Oct-89 0950 X3J13-mailer re: more cleanups
To: barmar@THINK.COM, sandra%defun@CS.UTAH.EDU
CC: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from barmar@Think.COM sent Mon, 16 Oct 89 12:39 EDT.]
Having recently reviewed the CLOS material, I think the description of
method combination is self-contained. The only problem I found was that
the term ``method combination procedure'' is used in the section on
DEFINE-METHOD-COMBINATION and it is not defined.
-rpg-
∂16-Oct-89 0943 X3J13-mailer re: more cleanups
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 Oct 89 09:43:26 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 16 Oct 89 12:44:06 EDT
Date: Mon, 16 Oct 89 12:39 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: re: more cleanups
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: David A. Moon <Moon@stony-brook.scrc.symbolics.com>,
Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu
In-Reply-To: <8910101527.AA20624@defun.utah.edu>
Message-Id: <19891016163933.4.BARMAR@OCCAM.THINK.COM>
Date: Tue, 10 Oct 89 09:26:58 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Incidentally, I am not familiar with the Flavors method combination
facilities (having used only the most basic features of Flavors). I
suspect most readers of the standard will be similarly ignorant, and
if the explanation of method-combinations in the standard can't stand
on its own, we've got some serious editorial problems.....
Flavors method combination is pretty similar to CLOS method combination,
except that there's no CALL-NEXT-METHOD, so it doesn't have any of the
aspects that deal with that. However, the CLOS explanation stands on
its own pretty well. The reference to Flavors seemed to be for the
purpose of pointing out that this isn't something newly invented for
CLOS, not to imply that understanding Flavors is necessary to understand
CLOS.
barmar
∂16-Oct-89 0950 X3J13-mailer more cleanups
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 Oct 89 09:50:13 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 16 Oct 89 12:52:42 EDT
Date: Mon, 16 Oct 89 12:48 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: more cleanups
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <8910082108.AA18897@defun.utah.edu>
Message-Id: <19891016164807.5.BARMAR@OCCAM.THINK.COM>
Date: Sun, 8 Oct 89 15:08:39 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
(4) There's a problem with DEFINE-DECLARATION in that it assumes that
a single declaration-specifier can apply to either function or
variable bindings, but not both. DYNAMIC-EXTENT cannot be handled
with this mechanism. Maybe DEFINE-DECLARATION should be modified ...
Or we could just live with the fact that DEFINE-DECLARATION doesn't have
the power to create all the kinds of declarations that can be built in
to a compiler.
(8) I think the way method combinations work is far too complicated
and inefficient. Instead of building a piece of code at runtime for a
specific set of applicable methods, the method combination function
ought to work more like a macro or a SETF method and be a compile-time
transformation. (I.e., instead of passing it a list of methods, pass
it a variable which is bound to a list of methods when the method
combination function is invoked.) Have to think more about a specific
proposal.
Others have touched upon the issue of whether this should be a form or
function or something else. I think the issue is whether it is computed
at runtime or compile time, and I think the nature of Flavors- and
CLOS-style OOP requires them to be computed at runtime. The flexibility
of CLOS implies that the information needed to compute an effective
method may not be available at compile time. And even if it were,
computing them all would result in exponentially many effective methods
being computed and stored in object files, many of which would be for
classes that are never actually instantiated.
Flavors does have a facility for building effective methods (called
"combined methods" in Flavors) at compile time -- the macro
(COMPILE-FLAVOR-METHODS <flavor-name>) may be placed at top-level in a
file being compiled. However, if the relevant portion of the flavor
hierarchy is later changed, the combined method will be recomputed at
runtime. Unfortunately, I don't think this scheme is trivially adapted
to CLOS, because of multimethods.
barmar
∂16-Oct-89 0956 X3J13-mailer more cleanups
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 Oct 89 09:56:26 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 16 Oct 89 12:57:59 EDT
Date: Mon, 16 Oct 89 12:53 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: more cleanups
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <8910082108.AA18897@defun.utah.edu>
Message-Id: <19891016165328.6.BARMAR@OCCAM.THINK.COM>
Date: Sun, 8 Oct 89 15:08:39 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
(17) Clarify whether supplied-p parameters in a lambda list must be
bound after the corresponding &optional or &keyword parameter. CLtL
kind of implies they are bound after but doesn't say so explicitly or
provide any examples. I actually think it works out better
implementationally to bind supplied-p parameters before. Maybe this
should be left unspecified if we can't agree.
I think it should be left unspecified. I can't imagine any code where
the default-value form would need to refer to the corresponding
supplied-p parameter (since the supplied-p parameter will always be true
when the default-value form is executed).
barmar
∂16-Oct-89 1003 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 Oct 89 10:03:33 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 16 Oct 89 13:05:48 EDT
Date: Mon, 16 Oct 89 13:01 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8910111736.AA21677@defun.utah.edu>
Message-Id: <19891016170118.7.BARMAR@OCCAM.THINK.COM>
Date: Wed, 11 Oct 89 11:36:32 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
References: DEFSTRUCT; CLtL p. 309
Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (passed)
Category: CLARIFICATION, CHANGE
Edit History: V1, 11 Oct 1989, Sandra Loosemore
...
Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND):
Clarify that the symbols which name slots must *not* be bound as
lambda variables by the keyword constructor function. The slot
default init forms are evaluated in the lexical and dynamic
environment in which the DEFSTRUCT form itself appears.
Since we don't have dynamic closures, I presume you meant "the lexical
environment in which the DEFSTRuCT form appears and the dynamic
environment in which the call to the constructor function appears."
By the way, I prefer this proposal. I think lexical environments should
be captured (I think we've fixed everything so that init-forms are
always evaluated in the appropriate lexical environment), but I don't
like making the order of slots significant by allowing init forms to
reference other slots. Order of slots is often constrained by other
requirements (such as the :INCLUDE hierarchy, or using :TYPE to match a
pre-existing structure), so they shouldn't have an effect on the
semantics of the structure.
barmar
∂16-Oct-89 1631 X3J13-mailer more cleanups
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Oct 89 16:30:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 676605; 16 Oct 89 19:22:45 EDT
Date: Mon, 16 Oct 89 19:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: more cleanups
To: Barry Margolin <barmar@Think.COM>, Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <19891016165328.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19891016232952.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 16 Oct 89 12:53 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Sun, 8 Oct 89 15:08:39 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
(17) Clarify whether supplied-p parameters in a lambda list must be
bound after the corresponding &optional or &keyword parameter. CLtL
kind of implies they are bound after but doesn't say so explicitly or
provide any examples. I actually think it works out better
implementationally to bind supplied-p parameters before. Maybe this
should be left unspecified if we can't agree.
I think it should be left unspecified. I can't imagine any code where
the default-value form would need to refer to the corresponding
supplied-p parameter (since the supplied-p parameter will always be true
when the default-value form is executed).
I think it would be very confusing if bindings did not occur in the
order that the variables appear in the lambda-list. Of course where
some other order is implementationally easier and the user can't tell
the difference other than by using DISASSEMBLE, the compiler can
actually perform the bindings in a different order.
CLtL pp.60 and 61, and pages 4-12 and 4-13 of the recently distributed
X3J13 draft, actually seem pretty explicit on this point, although there
is room for ambiguity if one isn't sure that the word "parameter" includes
supplied-p parameters as well as regular parameters.
∂17-Oct-89 0040 X3J13-mailer more cleanups
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 89 00:39:57 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA23129g; Tue, 17 Oct 89 00:34:13 PDT
Received: by bhopal id AA05060g; Tue, 17 Oct 89 00:33:50 PDT
Date: Tue, 17 Oct 89 00:33:50 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910170733.AA05060@bhopal>
To: masinter@parc.xerox.com
Cc: sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
In-Reply-To: <masinter@parc.xerox.com>'s message of Thu, 12 Oct 89 10:59:04 PDT <8910121759.AA01399@masunter.parc.xerox.com>
Subject: more cleanups
re: I don't think this is a "substantive issue", since, while "some people"
might miscontrue the standard to mean that hash table entries of EQUAL
hash tables must be copied, I don't think any current implementation
does it that way, and I don't think any of us take it to mean that.
I belive your reasoning here is backwards; there has never been any fear
that people would "misconstrue" the standard as requiring this extra step
(of insulating the keys entered into hash-tables from the actual argument
to setf of gethash). On the other hand, it would be a misconstruing to
presume that the other alternative is required behaviour (e.g., that they
be _not_ insulated).
However, regardless of which way an implementation does it, the primary
properties of equivalence relations say all that there needs to be said
about the effects of altering objects that:
(1) are in fact the EQ object stored as the key of a table entry
(2) are used as key arguments in table lookups.
[Note well that I never had to refer to "hash-table" at all in order to
deduce these properties; but I did acknowledge that the interior structure
of the table is opaque (unlike, e.g., alists).]
It is the lack of understanding about what this opaqueness means that
keeps prompting Sandra's concern. The important extent of that opaqueness
for hash tables was the concern of the issue HASH-TABLE-STABILITY. But an
amendment to a later issue tossed out the "HASH" in HASH-TABLE entirely
(except for the lingering use in names like MAKE-HASH-TABLE), so it's all
moot as far as the standard is concerned now. Hash-tables are no longer
required to be "hashing" at all, but fulfill the upcoming standard's
definition merely if they are "tables".
-- JonL --
∂17-Oct-89 1053 X3J13-mailer more cleanups
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 17 Oct 89 10:53:12 PDT
Received: from Fafnir.Think.COM by Think.COM; Tue, 17 Oct 89 13:55:46 -0400
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 17 Oct 89 13:51:18 EDT
Received: by verdi.think.com; Tue, 17 Oct 89 13:51:16 EDT
Date: Tue, 17 Oct 89 13:51:16 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8910171751.AA25089@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: barmar@Think.COM, sandra%defun@cs.utah.edu, masinter.pa@xerox.com,
x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 16 Oct 89 19:29 EDT <19891016232952.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: more cleanups
Date: Mon, 16 Oct 89 19:29 EDT
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Mon, 16 Oct 89 12:53 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Sun, 8 Oct 89 15:08:39 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
(17) Clarify whether supplied-p parameters in a lambda list must be
bound after the corresponding &optional or &keyword parameter. CLtL
kind of implies they are bound after but doesn't say so explicitly or
provide any examples. I actually think it works out better
implementationally to bind supplied-p parameters before. Maybe this
should be left unspecified if we can't agree.
I think it should be left unspecified. I can't imagine any code where
the default-value form would need to refer to the corresponding
supplied-p parameter (since the supplied-p parameter will always be true
when the default-value form is executed).
I think it would be very confusing if bindings did not occur in the
order that the variables appear in the lambda-list. Of course where
some other order is implementationally easier and the user can't tell
the difference other than by using DISASSEMBLE, the compiler can
actually perform the bindings in a different order.
CLtL pp.60 and 61, and pages 4-12 and 4-13 of the recently distributed
X3J13 draft, actually seem pretty explicit on this point, although there
is room for ambiguity if one isn't sure that the word "parameter" includes
supplied-p parameters as well as regular parameters.
I think CLtL p. 63 is fairly clear on this point:
Whenever any initform is evaluated for any parameter specifier, that form
may refer to any parameter variable to the left of the specifier in which
the initform appears, including any supplied-p variables, and may rely on
the fact that no other parameter variables has yet been bound (including
its own parameter variable).
--Guy
∂19-Oct-89 0822 X3J13-mailer November X3J13 meeting, Palo Alto
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 19 Oct 89 08:21:13 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA24565; Thu, 19 Oct 89 11:21:55 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA03205; Thu, 19 Oct 89 07:41:32 PDT
Received: by fiona.Franz.COM (3.2/FI-1.0)
id AA02288; Thu, 19 Oct 89 07:37:01 PDT
Date: Thu, 19 Oct 89 07:37:01 PDT
From: smh@Franz.COM (Steve Haflich)
Message-Id: <8910191437.AA02288@fiona.Franz.COM>
To: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Tue, 26 Sep 89 12:30:49 PDT <8909261930.AA01702@rose>
Subject: November X3J13 meeting, Palo Alto
COMMITTEE MEETING:
DATES: 11/6 - 11/8
TIME: 9:00 - 5:00
CITY: Palo Alto
PLACE: Xerox PARC
ROOM: Auditorium
ADDRESS: 3333 Coyote Hill Road (Directions from hotel to PARC below)
HOTEL: Rickey's Hyatt
ADDRESS: 4219 El Camino Real, Palo Alto, CA 94306
The obvious issue should be discussed, if only to dispel it:
Does earthquake damage raise any reason the November meeting time or
place should be changed?
Here in Berkeley there is very little damage (although the 880 highway
collapse which killed several hundred is only 3 miles away). Outside
certain heavily-damaged localities the only systemic problems likely
to remain after two weeks relate to transportation: the Bay Bridge
between S.F. and Oakland will be closed; hwy 880 north-south around
Oakland is destroyed; certain highways in S.F itself will likely still
be closed; and many of the highways around Santa Clara south of San
Jose are uncertain. Although these will cause transportation delays
for people commuting from the Bay Area, ground transportation still
works. From here in the East Bay one would not expect any significant
difficulty for attendees arriving at S.F. Airport. The only damage
reports I have heard from the Palo Alto area is that a number of old
buildings at Stanford have been closed.
It *appears* to me that the meeting should and will go on as
scheduled, but I haven't actually *been* in Palo Alto. Could someone
from Parc please comment?
∂19-Oct-89 0836 X3J13-mailer November meeting (Shake, Rattle and Roll!)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Oct 89 08:36:00 PDT
Received: from rose ([192.9.200.83]) by heavens-gate id AA06940g; Thu, 19 Oct 89 08:34:37 PDT
Received: by rose id AA00554g; Thu, 19 Oct 89 08:36:38 PDT
Date: Thu, 19 Oct 89 08:36:38 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8910191536.AA00554@rose>
To: x3j13@sail.stanford.edu
Subject: November meeting (Shake, Rattle and Roll!)
Yes, it's still on folks! Despite what you are seeing on TV, we have had
little to no damage in Palo Alto or Menlo Park and all systems are go.
---jan---
X3J13 Attendee Information
10/19/89
Name Institute Paid L1 L2 L3
David Bartley TI -0- y y y
Mary Boelk Johnson Controls -0- y y y
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
George Hadden Honeywell -0- y y y
Steve Haflich Franz, Inc. -0- y y y
Timothy Koschmann Southern Illinois -0- y y y
Aaron Larson Honeywell -0- y y y
Joachim Laubsch HP Labs -0- y y y
Thom Linden IBM -0- - - -
David Loeffler MCC -0- y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines -0- y y y
Larry Masinter Xerox PARC -0- y y y
Robert Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Jarl Nilsson Franz -0- y y y
Chris Perdue Sun Microsystems -0- y - y
Dan Pierson Encore -0- y y y
Kent Pitman Symbolics -0- y y y
B. Raghavan NASA Ames Research Center -0- - - -
Bill St. Clair Apple Computer -0- y y y
Philip Stanhope Goldhill -0- y y y
Guy Steele Thinking Machines -0- y y y
Paul Tucker IBM -0- y y y
Walter van Roggen DEC -0- y y y
Ellen Waldrum TI -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂22-Oct-89 2254 X3J13-mailer Report on WG16 Meeting
To: x3j13@SAIL.Stanford.EDU
CC: jerome@SRC.DEC.COM, chaynes@IUVAX.CS.INDIANA.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
WG16 (ISO) met in Sendai, Japan, in September. The results of this
meeting will be a major topic of discussion at the next X3J13 meeting.
Some interesting things happened, and we learned some things about how
these meetings work, so perhaps we will be in better shape next time.
We ate a lot of sushi, some of it not quite dead.
The following are the important points:
1. The only drafts that were sent according to the orally-agreed-upon
August 1 deadline were the CL draft, the Scheme draft, and possibly
the EuLisp draft (depending on how one believes it was sent).
2. Missing entirely was the LeLisp draft, and even that was a surrogate
for an unwritten version. That is, the draft sent was for version 15.2,
which is dynamically scoped, and the intended draft is for version 16, which
is lexically scoped and includes many EuLisp features.
3. Almost no one had read the drafts for comment, and so the light discussion
of the drafts centered on the CL draft and the EuLisp draft.
4. The German work plan, which is to consider drafts by various national
groups and accept a subset of them, was dropped.
5. The Japanese delegation asked the US delegation to determine whether
an ISO standard that was ANSI CL minus CLOS was acceptable to the US.
6. Two action items were drafted:
a. each country is to list those things that ought to be in
a CL subset and those things that ought not.
b. each country is to decide on a starting point for the long-term
standard.
7. In general it was agreed that the short-term standard should be a
subset of CL, but there was disagreement about what a subet was. The
French delegation proposed a definition that I could not understand, and
so I will repeat it as best I can but refuse to claim responsibility for
any inaccuracy:
Language L is a subset of language L' if there exists a
program C such that for every valid program P in L with
observable behavior B, the program C concatenated with P
is a valid program in L' with the same observable behavior B.
That is, C is a compatibility package, but some examples of L and L' I saw
require C to be a compiler.
8. Some delegations consider the official minutes of a meeting to be the
*only* outcome of the meeting. This explains why no country except the US
delivered drafts as agreed *orally* in Fairfax and also why some important
decisions are never officially voted on (even in straw fashion) -
otherwise they would appear in the minutes. Some countries try very hard
to prevent statements from being agreed by consensus. I believe that the
*only* outcome of the Sendai meeting that will be reported to the rest of
the world except in the US and Japan will be that each country is to list
what should and should not be in a CL subset. In particular the Japanese
request, which was formulated as a resolution for voting, was not allowed
to have any official status. Therefore it is not in the minutes, and
therefore it never happened.
*****************************************************************************
The UK position appeared to change, but again this will not be reflected in the
minutes. The UK stated that they intended for the EuLisp draft to be considered
for the long-term only because commercial interests in the UK require CL to have
a useful lifetime. ANSI without ISO interference is sufficient for this purpose.
Japan seems genuinely interested in CL - CLOS, the main objection to CLOS
being that it is too new and an ISO standard should be to enable current
programs to run for some period of time.
Germany seems to be primarily interested in ANSI CL, but it was hard
to separate the views of DIN from the views of Siemens, which supplies
all the German delegates - this impression was partially gathered in
an informal setting and therefore I could not tell which personae were
conversing with me.
My guess is that favor has slightly shifted to CL for the short-term, but
that bureaucratically-minded folks are not discouraged by this.
-rpg-
∂23-Oct-89 0735 X3J13-mailer Report on WG16 Meeting
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 23 Oct 89 07:35:24 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Mon, 23 Oct 89 10:36:50 -0400
Date: Mon, 23 Oct 89 10:31 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Report on WG16 Meeting
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: x3j13@SAIL.Stanford.EDU, jerome@SRC.DEC.COM, chaynes@IUVAX.CS.INDIANA.EDU
In-Reply-To: <W0D92@SAIL.Stanford.EDU>
Message-Id: <19891023143158.2.BARMAR@OCCAM.THINK.COM>
Date: 22 Oct 89 2254 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
7. In general it was agreed that the short-term standard should be a
subset of CL, but there was disagreement about what a subet was. The
French delegation proposed a definition that I could not understand, and
so I will repeat it as best I can but refuse to claim responsibility for
any inaccuracy:
Language L is a subset of language L' if there exists a
program C such that for every valid program P in L with
observable behavior B, the program C concatenated with P
is a valid program in L' with the same observable behavior B.
That is, C is a compatibility package, but some examples of L and L' I saw
require C to be a compiler.
This definition seems backward to me. It says that the "compatibility
package" must be used when processing the program with the FULL
language. Yes, I know you disavowed responsiblity for the accuracy of
the definition, but who else can I ask?
Do you remember some particular examples of L, L', and C?
barmar
∂23-Oct-89 0836 X3J13-mailer re: Report on WG16 Meeting
To: barmar@THINK.COM
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from barmar@Think.COM sent Mon, 23 Oct 89 10:31 EDT.]
Yes, the idea is that you need the compatibility package for programs
written in the subset to be run in the superset, as well as in the other
direction. An example is Level 0 of EuLisp (L') and Common Lisp (L).
EuLisp has dynamic-let and not let/special. So to run a program in L (CL)
that was written in L' (EuLisp) using dynamic-let, you need a
compatibility package for to turn the dynamic-let into let/special.
Dynamic-let:
(dynamic-let ((x <form>)) ... (dynamic x) ...)
is equivalent to
(let ((x <form>)) (declare (special x)) ... x ...)
Since the dynamic variable and lexical variable namespaces are different,
you need to code-walk to alphatize the names to get dynamic-let's right.
-rpg-
∂23-Oct-89 0822 X3J13-mailer WG16 and subsets
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 23 Oct 89 08:21:42 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa08960; 23 Oct 89 15:39 BST
Date: Mon, 23 Oct 89 15:42:05 BST
Message-Id: <8904.8910231442@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: WG16 and subsets
To: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 22 Oct 89 2254 PDT
Cc: jerome@src.dec.com, chaynes@iuvax.cs.indiana.edu
> 7. In general it was agreed that the short-term standard should be a
> subset of CL, but there was disagreement about what a subet was. The
> French delegation proposed a definition that I could not understand, and
> so I will repeat it as best I can but refuse to claim responsibility for
> any inaccuracy:
>
> Language L is a subset of language L' if there exists a
> program C such that for every valid program P in L with
> observable behavior B, the program C concatenated with P
> is a valid program in L' with the same observable behavior B.
>
> That is, C is a compatibility package, but some examples of L and L' I saw
> require C to be a compiler.
I think I can explain the French definition, at least to some extent.
However, I too find it somewhat strange.
Part of the problem may be that it's hard to define this notion of
subset precisely. There were similar difficulties in the past when
trying to say exactly how Eulisp level 0 was related to the higher
levels. Was it supposed to be possible to define level 1 in terms of
level 0 by writing a few functions and macros, by writing a compiler,
or what? It seems to be difficult to specify relationships of this
sort.
I think the intent of the French definition of "subset" is to say
something near to "implementations (of L') don't have to change". The
subset doesn't require any new semantic primitives (where by "semantic
primitive" I mean something near to "special forms that can't be
implemented as macros").
For example, it has been argued that the EuLisp proposal for dynamic
binding (as specified by the paper discussed at the Snowbird (?)
meeting) could be part of a subset of CL, because the new "special
forms" dynamic-let, dynamic-ref, etc could be defined by macros
that expand to use PROGV and SYMBOL-VALUE.
However, this certainly violates my notion of subset, because
I would have thought that subset would be defined as follows:
A language L is a subset of a language L' if every conforming
program of L is also a conforming program of L'.
This seems to me reasonably clear, intuitive, and straightforward: if
I have a program that conforms to L, I can run it in any (conforming)
implementation of L'. Still, there are a few problems. For example,
suppose there are some names (eg, DEFCLASS) that are defined in L' but
not in L and suppose that L'-conforming programs cannot redefine such
names. Then, if L is to be a subset of L', L-conforming programs
cannot redefine such names either. I'm not sure whether this agrees
with "intuition" or not (and maybe that means it doesn't).
In the French definition, I'm a bit worried about the "observable
behavior" criterion; I think it's better to work through conforming
programs and implementations rather than address behavior directly.
However, the real problem is surely the "conversion prefix", C. It
allows someone to show they have a subset by exhibiting a C, but it
becomes difficult to reason about subsets in the abstract. It also
means that the set of subsets might change rather dramatically when
relatively small changes are made in L'. For example, what happens if
C changes the readtable? Do those changes apply to P? Whether they
do or not depends on the definition of L', and deciding this one way
or the other may determine, just for example, whether or not Pascal
(and virtually every other language) counts as a subset of Common
Lisp. So, for this definition of subset to make much sense, we'd have
to specify a number of constraints on C.
I think all of this is fairly obvious, so I apologize for saying
it at such length. However, a number of people seem to disagree
with my notion of subset, so maybe it's not so obvious after all.
Anyway, ...
In a case where C is non-null, I would prefer to say "L _corresponds_
to a subset of L'" (where the correspondence is specified by C) rather
than to say "L _is_ a subset of L'", but there are at least political
reasons for saying L should count as a subset.
To some extent, the technical question of how to define "subset" is
just another way to discuss more pragmatic issues. In particular, if
we agree that the short term standard should be a "subset" of Common
Lisp, how much freedom is left? I think the French would argue that
the real issue should be how much existing implementations (and
programs?) would have to change. When that point gets expressed
in terms of subsets, you get the sort of definition RPG quoted
above.
Unfortunately, it's harder to conduct the discussion in terms of
subsets, because there are all these technical details to work out so
that things like Pascal are excluded. I think it would be easier to
discuss specific proposals for departures from CL directly. If we
don't worry specifically about subsets, there are still lots of other
grounds for rejecting changes. A change might require too much work
by CL implementors, destroy the integrity of the language, be ill-
defined, reduce efficiency, etc.
-- Jeff
∂23-Oct-89 0946 X3J13-mailer WG16 and subsets
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 23 Oct 89 09:44:09 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Mon, 23 Oct 89 12:42:03 -0400
Date: Mon, 23 Oct 89 12:37 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: WG16 and subsets
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Cc: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu,
jerome@src.dec.com, chaynes@iuvax.cs.indiana.edu
In-Reply-To: <8904.8910231442@aiai.ed.ac.uk>
Message-Id: <19891023163709.7.BARMAR@OCCAM.THINK.COM>
Date: Mon, 23 Oct 89 15:42:05 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
I would have thought that subset would be defined as follows:
A language L is a subset of a language L' if every conforming
program of L is also a conforming program of L'.
...
In the French definition, I'm a bit worried about the "observable
behavior" criterion; I think it's better to work through conforming
programs and implementations rather than address behavior directly.
Actually, I think that part is important. Consider the following
languages: L is Common Lisp; L' is Common Lisp, with the semantics of
the + and - functions interchanged. Every conforming program of L would
also be a conforming program of L', so by your definition L would be a
subset of L'.
Unfortunately, it's harder to conduct the discussion in terms of
subsets, because there are all these technical details to work out so
that things like Pascal are excluded.
I don't think it's necessary to define subset in a way that rules out
such things. The goal of defining a Lisp language standard should be
enough to prevent that (how many ISO members would vote in favor of an
ISO-Lisp standard that simply specified a Pascal compiler in Lisp?).
I'm having trouble coming up with a good reason why I think this aspect
of the definition doesn't need to be clarified but the "observable
behavior" part is important. Perhaps it's because the observable
behavior criterion is independent of the potentially debatable issue of
whether the Conversion prefix is needed.
barmar
∂23-Oct-89 1019 X3J13-mailer re: Report on WG16 Meeting
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 23 Oct 89 10:19:20 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Mon, 23 Oct 89 13:20:57 -0400
Date: Mon, 23 Oct 89 13:15 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: re: Report on WG16 Meeting
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: x3j13@SAIL.Stanford.EDU
In-Reply-To: <k0WTO@SAIL.Stanford.EDU>
Message-Id: <19891023171559.8.BARMAR@OCCAM.THINK.COM>
Date: 23 Oct 89 0836 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from barmar@Think.COM sent Mon, 23 Oct 89 10:31 EDT.]
Yes, the idea is that you need the compatibility package for programs
written in the subset to be run in the superset, as well as in the other
direction. An example is Level 0 of EuLisp (L') and Common Lisp (L).
EuLisp has dynamic-let and not let/special. So to run a program in L (CL)
that was written in L' (EuLisp) using dynamic-let, you need a
compatibility package for to turn the dynamic-let into let/special.
Dynamic-let:
(dynamic-let ((x <form>)) ... (dynamic x) ...)
is equivalent to
(let ((x <form>)) (declare (special x)) ... x ...)
Since the dynamic variable and lexical variable namespaces are different,
you need to code-walk to alphatize the names to get dynamic-let's right.
-rpg-
I agree with Jeff that this doesn't correspond to the usual definition
of language subset. These two languages are just plain DIFFERENT.
Sure, they're similar (just as Common Lisp and Scheme are similar), and
some macrology can be used to make one acceptable to a processor for the
other, but that's not a good basis for a standardization effort.
Perhaps this is what is meant by "extended subset"?
barmar
∂23-Oct-89 1105 X3J13-mailer Re: Report on WG16 Meeting
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 23 Oct 89 11:04:45 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa12759; 23 Oct 89 18:36 BST
Date: Mon, 23 Oct 89 18:38:49 BST
Message-Id: <10942.8910231738@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Report on WG16 Meeting
To: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 22 Oct 89 2254 PDT
Cc: jerome@src.dec.com, chaynes@iuvax.cs.indiana.edu
> WG16 (ISO) met in Sendai, Japan, in September. The results of this
> meeting will be a major topic of discussion at the next X3J13 meeting.
Thanks for the report.
Since I won't be able to attend the X3J13 meeting, I hope someone will
take notes and post them. Minutes tend to concentrate on official
decisions without necessarily providing much insight into why they
went one way rather than another.
Some brief remarks follow.
> 1. The only drafts that were sent according to the orally-agreed-upon
> August 1 deadline were the CL draft, the Scheme draft, and possibly
> the EuLisp draft (depending on how one believes it was sent).
I think there may have been a genuine misunderstanding on this point.
In a long discussion, it may seem that a later decision overrides an
earlier one, especially of the later decision is agreed on a more
formal basis. Moreover, it is always possible for decisions to be
misunderstood, especially when they are not written down, and
especially when many of the people involved are not native speakers of
the language used for discussion (ie, English). Consequently, I
think it is understandable that some of the delegations prefer
to have action items written down so that we can all know what
we've agreed to. When this happens, it is understandable that
items that are not written down are given less significance than
they might be given otherwise. More on this below.
> 3. Almost no one had read the drafts for comment, and so the light
> discussion of the drafts centered on the CL draft and the EuLisp draft.
I would be interested in hearing what people think of the EuLisp
draft.
> 5. The Japanese delegation asked the US delegation to determine whether
> an ISO standard that was ANSI CL minus CLOS was acceptable to the US.
It seems to me that it ought to be acceptable, since it has been
explicitly stated that a strict subset would be acceptable, and
CL minus CLOS presumably is a strict subset.
> 7. In general it was agreed that the short-term standard should be a
> subset of CL, but there was disagreement about what a subet was. The
> French delegation proposed a definition that I could not understand
> [...]
To keep this message reasonably short, I addressed this separately.
> 8. Some delegations consider the official minutes of a meeting to be the
> *only* outcome of the meeting.
One thing I noticed at the Fairfax meeting was that it was fairly easy
for the native English speakers to discuss issues very quickly and to
consider changes in direction. Other delegations seemed to put more
emphasis on documents that they had had time to study and to
understand fully. Since everyone who attends the meetings has an
excellent command of English it is possible to forget that native
speakers still have an advantage. It is also possible to think that
some point has been made and then ignored only to discover that the
reason is that some people had not completely understand what you were
saying. That sort of thing happens at EuLisp meetings, and I think
it can happen at WG-16 meetings too.
Not only that. I take fairly complete notes, but after a WG-16
meeting I have often found that I have to ask other people exactly
what was agreed. When this happens, the minutes are an important
source.
> This explains why no country except the US
> delivered drafts as agreed *orally* in Fairfax
Possibly. See various remarks elsewhere in this message.
> and also why some important
> decisions are never officially voted on (even in straw fashion) -
> otherwise they would appear in the minutes. Some countries try very hard
> to prevent statements from being agreed by consensus.
I can't speak for other delegations, but as far as I am aware, the UK
delegation has never done anything as a tactic designed to prevent
something from appearing in the minutes.
As far as I am aware, the UK does not regard only what appears in
the minutes as significant. However, like anyone else, we may have
trouble keeping track of the rest.
> I believe that the
> *only* outcome of the Sendai meeting that will be reported to the rest of
> the world except in the US and Japan will be that each country is to list
> what should and should not be in a CL subset. In particular the Japanese
> request, which was formulated as a resolution for voting, was not allowed
> to have any official status. Therefore it is not in the minutes, and
> therefore it never happened.
By "the Japanese request", do you mean
5. The Japanese delegation asked the US delegation to determine
whether an ISO standard that was ANSI CL minus CLOS was acceptable
to the US.
This sounds like a request to the US delegation rather than something
to be considered by all delegations. In what sense do you think it
will not be reported?
When you say "the only outcome", it sounds like "outcome" might mean
only decisions, action items, and the like. If so, I'm not sure what
to say about it, because it brings us back to the question of the
status of informal decisions. However, I certainly expect to
hear a more complete report of what happened at the meeting.
> The UK position appeared to change, but again this will not be
> reflected in the minutes.
I would say that the expressed UK position has changed. However,
to some extent this is because it has become more definite, and
also because we now have a more complete definition of EuLisp
and consequently are better able to see how much remains to be
done.
> The UK stated that they intended for the
> EuLisp draft to be considered for the long-term only because
> commercial interests in the UK require CL to have a useful lifetime.
> ANSI without ISO interference is sufficient for this purpose.
Humm. This makes it sound like, if it weren't for these commercial
interests, the UK would want EuLisp considered as a short-term
standard. Is that what it's meant to say? (Presumably, we're not
supposed to infer that otherwise the UK would not want EuLisp
considered at all.)
I can't speak for anyone but myself at this point, but I would say
that the UK has to take a number of factors into account. There are
Common Lisp users, some commercial, and even Common Lisp vendors, in
the UK. Most of their needs for a CL standard would be satisfied by
an ANSI CL standard. EuLisp has a number of attractive features
but is still relatively immature. So our interest in EuLisp has
to be more long-term. I don't think we've tried to define exactly
what long-term and short-term would mean in terms of years.
---
I hope I have been able to some information about how these
things might be seen from the UK. However, one should bear
in mind that other people may have different views and that
was not at the Sendai meeting myself.
-- Jeff
∂23-Oct-89 1223 X3J13-mailer Re: Report on WG16 Meeting
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 23 Oct 89 12:23:26 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa14177; 23 Oct 89 20:04 BST
Date: Mon, 23 Oct 89 20:07:06 BST
Message-Id: <11741.8910231907@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Report on WG16 Meeting
To: Barry Margolin <barmar@think.com>, Dick Gabriel <RPG@sail.stanford.edu>
In-Reply-To: Barry Margolin's message of Mon, 23 Oct 89 10:31 EDT
Cc: x3j13@sail.stanford.edu, jerome@src.dec.com, chaynes@iuvax.cs.indiana.edu
> Language L is a subset of language L' if there exists a
> program C such that for every valid program P in L with
> observable behavior B, the program C concatenated with P
> is a valid program in L' with the same observable behavior B.
>
> This definition seems backward to me. It says that the "compatibility
> package" must be used when processing the program with the FULL
> language. Yes, I know you disavowed responsiblity for the accuracy of
> the definition, but who else can I ask?
>
> Do you remember some particular examples of L, L', and C?
I think it seems backwards to you because you're thinking of subset
from the point of view of someone writing programs (or something like
that). That's how I think of it too. But what you have to do is
think of it from the point of someone who's told: any language you
define has to be a subset of Common Lisp. The idea (I think) is to
suggest a less strict definition of "subset" so that a greater range
of languages would qualify.
The idea is not to say "we know what a subset is, let's provide
a precise definition" but rather to say "here is the notion of subset
that we would like to use for this purpose", in which case whether
the notion should really be called "subset" is somewhat beside the
point.
I gave the one example I'm pretty sure of in a longer message about
subsets sent earlier today. [Well, it used to be longer.] But maybe
I should elaborate a bit. Suppose we remove SPECIAL declarations and
proclamations from Common Lisp. I think everyone would agree that the
result is a subset. Note, however, that PROGV and SYMBOL-VALUE
remain. So, suppose I add some "syntactic sugar" to the subset:
(DYNAMIC-LET ((v1 init1) (v2 init2) ...)
body)
== (PROGV '(v1 v2 ...) (list init1 init2 ...)
body)
(DYNAMIC-REF name)
== (SYMBOL-VALUE 'v)
Can I still say the resulting language is a subset? The idea
is to make the answer be "yes". C would contain macro definitions
for DYNAMIC-LET and DYNAMIC-REF.
At least that is what I think is going on.
My feeling is that rather than spend too much time on the question of
whether this is a good definition of the word "subset", we (ie, x3j13)
should consider what we want to accomplish by saying that an ISO
standard should be a subset of Common Lisp, and then see how much
freedom makes sense given those aims.
-- Jeff
∂23-Oct-89 1240 X3J13-mailer re: Report on WG16 Meeting
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 23 Oct 89 12:40:05 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa14427; 23 Oct 89 20:16 BST
Date: Mon, 23 Oct 89 20:19:41 BST
Message-Id: <11917.8910231919@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: re: Report on WG16 Meeting
To: Dick Gabriel <RPG@sail.stanford.edu>, barmar@think.com
In-Reply-To: Dick Gabriel's message of 23 Oct 89 0836 PDT
Cc: x3j13@sail.stanford.edu
> [In reply to message from barmar@Think.COM sent Mon, 23 Oct 89 10:31 EDT.]
>
> Yes, the idea is that you need the compatibility package for programs
> written in the subset to be run in the superset, as well as in the other
> direction. An example is Level 0 of EuLisp (L') and Common Lisp (L).
Note that the L and L' used to be the other way around:
Language L is a subset of language L' if there exists a
> EuLisp has dynamic-let and not let/special. So to run a program in L (CL)
> that was written in L' (EuLisp) using dynamic-let, you need a
> compatibility package for to turn the dynamic-let into let/special.
>
> Dynamic-let:
>
> (dynamic-let ((x <form>)) ... (dynamic x) ...)
>
> is equivalent to
>
> (let ((x <form>)) (declare (special x)) ... x ...)
>
> Since the dynamic variable and lexical variable namespaces are different,
> you need to code-walk to alphatize the names to get dynamic-let's right.
The EuLisp proposal presented as a separate paper for, I think, the
Snowbird meeting supposedly did not require code-walking because it
was trivially definable in terms of PROGV and SYMBOL-VALUE. Now,
maybe it wasn't trivially definable in fact, but that was the
claim.
Cheers,
Jeff
∂23-Oct-89 1255 X3J13-mailer Re: WG16 and subsets
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 23 Oct 89 12:55:20 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa14765; 23 Oct 89 20:34 BST
Date: Mon, 23 Oct 89 20:37:45 BST
Message-Id: <12154.8910231937@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: WG16 and subsets
To: Barry Margolin <barmar@think.com>, jerome@src.dec.com,
chaynes@iuvax.cs.indiana.edu
Cc: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu
> Date: Mon, 23 Oct 89 15:42:05 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
>
> I would have thought that subset would be defined as follows:
>
> A language L is a subset of a language L' if every conforming
> program of L is also a conforming program of L'.
>
> ...
>
> In the French definition, I'm a bit worried about the "observable
> behavior" criterion; I think it's better to work through conforming
> programs and implementations rather than address behavior directly.
>
> Actually, I think that part is important. Consider the following
> languages: L is Common Lisp; L' is Common Lisp, with the semantics of
> the + and - functions interchanged. Every conforming program of L would
> also be a conforming program of L', so by your definition L would be a
> subset of L'.
You're right. I was careless. I think I'd still rather say something
in terms of interpretations of symbols rather than behavior, but I
don't think it matters much right now.
> Unfortunately, it's harder to conduct the discussion in terms of
> subsets, because there are all these technical details to work out so
> that things like Pascal are excluded.
>
> I don't think it's necessary to define subset in a way that rules out
> such things. The goal of defining a Lisp language standard should be
> enough to prevent that (how many ISO members would vote in favor of an
> ISO-Lisp standard that simply specified a Pascal compiler in Lisp?).
I picked an extreme example to show that constraints on C might make
a big difference, but maybe my example was so extreme that it ceased
to be convincing. [I had in mind the point that can be made against
"extended subset": almost anything is one, especially if you extend
the null subset.]
I think it does matter, however, whether Scheme, or Le Lisp, or
Cambridge Lisp counts as a subset of CL; and it think it may matter
whether the C prefix for some subset has to be a compiler, or whether
the only way to get efficient implementations of the subset in an
implementation of the superset is to change the implementation of the
superset extensively.
But what I really think is that technical questions about the
definition of subset, while interesting, may not be the best way to
decide what "subsets" of CL we'd be willing to accept as ISO
standards.
> I'm having trouble coming up with a good reason why I think this
> aspect of the definition doesn't need to be clarified but the
> "observable behavior" part is important.
Well, maybe there isn't one. After all, would anyone vote for a
standard in which + and - were interchanged?
Cheers,
Jeff
∂23-Oct-89 1530 X3J13-mailer issue READER-ERROR
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Oct 89 15:30:31 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA05438; Mon, 23 Oct 89 16:30:19 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA07983; Mon, 23 Oct 89 16:30:16 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910232230.AA07983@defun.utah.edu>
Date: Mon, 23 Oct 89 16:30:15 MDT
Subject: issue READER-ERROR
To: x3j13@sail.stanford.edu
This is issue #18 from my list.
Forum: Cleanup
Issue: READER-ERROR
References: Chapter 3, "Syntax"
Section 2.2, "Types"
Category: ADDITION, CHANGE
Edit History: V1, 23 Oct 1989, Sandra Loosemore
Problem Description:
Chapter 3 of the current draft is not consistent about the types of
errors that must be signalled by the reader. In most places where it
specifies that an error is to be signalled, it does not indicate a
particular type of error, but in at least one situation it requires
the error to be of type PROGRAM-ERROR, and in other cases it requires
the error to be of type ERROR.
None of the ERROR subtypes described in section 2.2 really seem
appropriate for syntactic errors detected by the reader. In
particular, the description of PROGRAM-ERROR implies that its purpose
is for errors relating to program syntax which are detectable during
evaluation or compilation rather than read-time errors. It seems
especially inappropriate to use PROGRAM-ERROR for this purpose since
the reader can be used to read things other than programs. Likewise,
STREAM-ERROR appears to have been intended to be used for errors
relating to character-level transactions on the stream rather than
lexical analysis or parsing.
Proposal (READER-ERROR:NEW-TYPE):
Add a new type specifier, READER-ERROR. This is a subtype of the
types ERROR, SERIOUS-CONDITION, CONDITION, and T. The type
READER-ERROR consists of serious conditions that relate to lexical
analysis (the building and interpretation of tokens) and parsing
(errors in reader macro syntax) by the Lisp reader.
Change the discussion in chapter 3 to specify that the type of errors
signalled by the reader is READER-ERROR. There are numerous places
that would be affected.
Rationale:
The general policy that has been followed in other areas of the
language where errors must, should, or might be signalled is to
specify a particular subtype of ERROR which covers that class of
errors. Doing the same for reader errors would be consistent with the
overall policy, but none of the existing error types seem appropriate
for reader-related errors.
Current Practice:
Probably no implementation does this yet.
Cost to implementors:
Trivial.
Cost to users:
Probably no user programs rely on the reader signalling any particular
type of error yet.
Benefits:
Increased consistency in the language design.
Ability to set up handlers specifically for reader errors.
Discussion:
-------
∂23-Oct-89 1542 X3J13-mailer issue INSPECT-RETURN-VALUE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Oct 89 15:42:28 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA06192; Mon, 23 Oct 89 16:42:13 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA07990; Mon, 23 Oct 89 16:42:10 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910232242.AA07990@defun.utah.edu>
Date: Mon, 23 Oct 89 16:42:09 MDT
Subject: issue INSPECT-RETURN-VALUE
To: x3j13@sail.stanford.edu
This is issue #2 from my list.
Forum: Cleanup
Issue: INSPECT-RETURN-VALUE
References: CLtL p442,
issue RETURN-VALUES-UNSPECIFIED
issue DESCRIBE-INTERACTIVE
Category: CHANGE
Edit History: V1, 23 Oct 1989, Sandra Loosemore
Problem Description:
Issue RETURN-VALUES-UNSPECIFIED states that the return values from
INSPECT are implementation-dependent. However, it would be helpful in
writing portable debugging tools if INSPECT reliably returned a useful
value. For example, one might implement an interactive tracing
utility that allows the user to INSPECT the arguments being passed.
In some implementations, INSPECT might support specification of a
replacement object. It would be useful if this were returned from
INSPECT so that the caller could make use of the value in place of the
original object.
Proposal (INSPECT-RETURN-VALUE:SPECIFY):
Specify that INSPECT returns the object being inspected. It is
possible that some implementations might permit the user to specify a
replacement object within the inspector, in which case that object
should be returned instead. (In other words, the return value need
not be EQL to the argument.)
Rationale:
This makes INSPECT a more useful function to call from within portable
debugging tools.
Current Practice:
In Lucid CL, INSPECT returns the object being examined. Since it
allows components to be examined recursively, this may be a component
of the top-level object that was passed to INSPECT.
In KCL, HPCL-I, and CMU Common Lisp, INSPECT returns no values (the
same as DESCRIBE).
Loosemore has written a (mostly portable) CLX-based graphical data
structure inspector utility, which implements the proposal.
Cost to implementors:
Trivial.
Cost to users:
There are probably few user programs that depend on the return value
from INSPECT. Those that do are already nonportable.
Benefits:
For those implementations that do provide a way to specify a
replacement object, this would provide a reliable way to get at it.
Discussion:
Perhaps this ought to be extended to apply to DESCRIBE also to keep
the two functions parallel. Since DESCRIBE is not permitted to be
interactive, however, its return value would always be the same as its
argument.
Masinter says:
From RETURN-VALUES-UNDERSPECIFIED early discussion (which was
unfortunately omitted from the final version of the proposal):
>Masinter believes that it is marginally more useful to say that
>INSPECT returns the item inspected. Some interactive inspectors might
>allow you to return a new value as the value of INSPECT, e.g., (SETQ X
>(INSPECT X)). GLS disagrees. If one regards INSPECT as a tool in the
>interactive interface, it can be a real nuisance to inspect some huge
>data structure and then when you finish it insists on printing 300
>lines of gobbledygook at you.
This was removed from the discussion because I agreed with Guy.
Loosemore responds:
There are lots of other ways to inhibit lengthy printings. You can
set *print-depth*, *print-length*, or the new *print-lines* variable,
or do something like (progn (inspect foo) nil). On the other hand,
there is no other way to get the information about the replacement
value for the object back from INSPECT.
-------
∂23-Oct-89 1750 X3J13-mailer Re: Report on WG16 Meeting
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 23 Oct 89 17:50:11 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Mon, 23 Oct 89 20:51:16 -0400
Date: Mon, 23 Oct 89 20:46 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Report on WG16 Meeting
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Cc: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu,
jerome@src.dec.com, chaynes@iuvax.cs.indiana.edu
In-Reply-To: <11741.8910231907@aiai.ed.ac.uk>
Message-Id: <19891024004622.4.BARMAR@OCCAM.THINK.COM>
Date: Mon, 23 Oct 89 20:07:06 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Suppose we remove SPECIAL declarations and
proclamations from Common Lisp. I think everyone would agree that the
result is a subset. Note, however, that PROGV and SYMBOL-VALUE
remain. So, suppose I add some "syntactic sugar" to the subset:
Can I still say the resulting language is a subset? The idea
is to make the answer be "yes". C would contain macro definitions
for DYNAMIC-LET and DYNAMIC-REF.
I don't like the idea of calling this result a subset. I suspect that
it can be shown that this definition of subset is reflexive and the same
as Turing-equivalence. And since all general purpose programming
languages are Turing equivalent, we end up with a definition of subset
that is practically useless (as you realized when you discovered that
Pascal could be defined this way).
Here's an example that shows how silly this is:
Suppose we remove nothing from Common Lisp. I think everyone would
agree that the result is a subset (NOT a proper "subset", though).
Note, however, that everything remains. Now, suppose I add some
"syntactic sugar" to the subset: DYNAMIC-LET and DYNAMIC-REF (defined
using existing CL features in the obvious ways). Can I still say the
resulting language is a subset? The proposed definition would allow the
answer to be "yes". Yes, you add something and get a subset!
Here's another "subset" that the proposed definition permits: French
Common Lisp, which is Common Lisp except with all the defined names
translated from English to French (does this mean that a cons cell would
have a VOITURE and a VOITDRE?).
Mind you, I have nothing against standardizing these kinds of things.
But I see no reason to overload the word "subset" for this. I think
this is being done because there's already agreement that subsets are
OK, so they're trying to stretch the definition to allow them, rather
than just coming out and deciding that they want to standardize a
"similar" language that can be implemented relatively easily within
Common Lisp (the "relatively easily" criterion is what disallows
Pascal).
barmar
∂23-Oct-89 1824 X3J13-mailer issue READER-ERROR
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 23 Oct 89 18:24:10 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Mon, 23 Oct 89 21:25:50 -0400
Date: Mon, 23 Oct 89 21:21 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue READER-ERROR
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8910232230.AA07983@defun.utah.edu>
Message-Id: <19891024012100.1.BARMAR@OCCAM.THINK.COM>
Date: Mon, 23 Oct 89 16:30:15 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Forum: Cleanup
Issue: READER-ERROR
References: Chapter 3, "Syntax"
Section 2.2, "Types"
Category: ADDITION, CHANGE
Edit History: V1, 23 Oct 1989, Sandra Loosemore
Proposal (READER-ERROR:NEW-TYPE):
Add a new type specifier, READER-ERROR. This is a subtype of the
types ERROR, SERIOUS-CONDITION, CONDITION, and T. The type
READER-ERROR consists of serious conditions that relate to lexical
analysis (the building and interpretation of tokens) and parsing
(errors in reader macro syntax) by the Lisp reader.
I like this. I'd also like to suggest a slot, STREAM, which would hold
the stream the error occurred on. It would be nice if there were some
generic way to include more of the context, but I'm not sure how.
barmar
∂23-Oct-89 1835 X3J13-mailer issue INSPECT-RETURN-VALUE
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 23 Oct 89 18:31:48 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Mon, 23 Oct 89 21:33:25 -0400
Date: Mon, 23 Oct 89 21:28 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue INSPECT-RETURN-VALUE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8910232242.AA07990@defun.utah.edu>
Message-Id: <19891024012833.2.BARMAR@OCCAM.THINK.COM>
Date: Mon, 23 Oct 89 16:42:09 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Forum: Cleanup
Issue: INSPECT-RETURN-VALUE
References: CLtL p442,
issue RETURN-VALUES-UNSPECIFIED
issue DESCRIBE-INTERACTIVE
Category: CHANGE
Edit History: V1, 23 Oct 1989, Sandra Loosemore
Proposal (INSPECT-RETURN-VALUE:SPECIFY):
Specify that INSPECT returns the object being inspected. It is
possible that some implementations might permit the user to specify a
replacement object within the inspector, in which case that object
should be returned instead. (In other words, the return value need
not be EQL to the argument.)
This is a confusing way to describe it. How about:
Specify that by default INSPECT returns the object being inspected, but
an implementation may allow the user to specify the value interactively
instead.
barmar
∂23-Oct-89 2115 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-OPTIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Oct 89 21:15:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 680552; 23 Oct 89 23:44:39 EDT
Date: Mon, 23 Oct 89 23:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFSTRUCT-CONSTRUCTOR-OPTIONS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8910112103.AA21802@defun.utah.edu>
Message-ID: <19891024034439.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Seems okay, and conforms to Symbolics Genera current parctice.
∂24-Oct-89 0725 X3J13-mailer November Attendee List
Received: from cambridge.apple.com (brazil.cambridge.apple.com) by SAIL.Stanford.EDU with TCP; 24 Oct 89 07:25:46 PDT
Received: by cambridge.apple.com (4.1/SMI-DDN) id AA01289; Tue, 24 Oct 89 10:27:46 EDT
Date: Tue, 24 Oct 89 10:27:46 EDT
From: bill@cambridge.apple.com (Bill St. Clair)
Message-Id: <8910241427.AA01289.bill@cambridge.apple.com>
To: mit-eddie!lucid.com!jlz
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Tue, 10 Oct 89 07:54:46 PDT <8910101454.AA01902@rose>
Subject: November Attendee List
Jan,
You got my info right, but there's only one of me.
Instead of "Bills St. Clair", my name is "Bill St. Clair".
Probably a slip of the finger.
See you in two weeks.
Bill
∂24-Oct-89 0925 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Oct 89 09:25:00 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA00297; Tue, 24 Oct 89 10:24:44 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA08645; Tue, 24 Oct 89 10:24:40 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910241624.AA08645@defun.utah.edu>
Date: Tue, 24 Oct 89 10:24:39 MDT
Subject: issue DEFMACRO-BLOCK-SCOPE
To: x3j13@sail.stanford.edu
This is issue #23 from my list.
Forum: Cleanup
Issue: DEFMACRO-BLOCK-SCOPE
References: Issue FLET-IMPLICIT-BLOCK
Category: CLARIFICATION
Edit History: V1, 24 Oct 1989, Sandra Loosemore
Problem Description:
Does the scope of the implicit BLOCK that surrounds the body of
DEFMACRO, MACROLET, DEFINE-SETF-METHOD, DEFTYPE, and
DEFINE-COMPILER-MACRO (the forms that define functional objects that
also support destructuring) include the bindings of the variables in
the destructuring pattern? In other words, is the BLOCK visible
during the evaluation of initialization forms included in the lambda
list?
It seems clear that in forms such as DEFUN which do not support
destructuring, the BLOCK surrounds only the body and includes none of
the lambda-variable binding forms.
There are two proposals, INCLUDES-BINDINGS and EXCLUDES-BINDINGS.
Proposal (DEFMACRO-BLOCK-SCOPE:INCLUDES-BINDINGS):
Clarify that the scope of the implicit BLOCK in the functions defined
by the forms listed above does include the initialization forms within
the lambda list as well as the body forms.
Rationale:
One can view the destructuring code which binds the variables in the
lambda list as part of the body of the function (for example, as
equivalent to a LET* or DESTRUCTURING-BIND construct), which would
be inside the scope of the BLOCK in an ordinary function-defining form.
Some users might find this behavior marginally more useful than the
other alternative.
Proposal (DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS):
Clarify that the scope of the implicit BLOCK in the functions defined
by the forms listed above includes only the body forms and not the
initialization forms within the lambda list.
Rationale:
One can view the destructuring code which binds the variables in the
lambda list as part of the ordinary lambda-list processing (for example,
as equivalent to binding &AUX variables), which would be outside the
scope of the BLOCK in an ordinary function-defining form. Some people
might find this to be more consistent with the scoping of the BLOCK
in the non-destructuring cases.
Current Practice:
Lucid CL, Utah CL, and CMU Common Lisp currently implement proposal
INCLUDES-BINDINGS. Kyoto CL implements proposal EXCLUDES-BINDINGS.
Cost to implementors:
Probably not too much effort involved to fix it.
Cost to users:
Currently nonportable user programs that depend on this being done the
other way will break, but this is a rather obscure point and it is
unlikely that there would be many programs affected.
Benefits:
The specification of the language is made more precise.
Discussion:
Sandra Loosemore says:
I don't think this issue is worth spending a lot of time arguing over,
since both alternatives seem equally plausible to me. I suggest we
just adopt whichever alternative that is closest to current practice.
I'm missing information on several implementations.
-------
∂24-Oct-89 0955 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 24 Oct 89 09:53:31 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Tue, 24 Oct 89 12:55:09 -0400
Date: Tue, 24 Oct 89 12:50 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFMACRO-BLOCK-SCOPE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8910241624.AA08645@defun.utah.edu>
Message-Id: <19891024165015.0.BARMAR@OCCAM.THINK.COM>
Symbolics Genera 7.2 seems to implement INCLUDES-BINDINGS (I only tried
DEFMACRO, though), so this seems like the concensus.
You didn't include an Aesthetics section in your writeup, so I thought
I'd just remark that I don't care for the fact that DEFMACRO and DEFUN
initializations have different scoping rules. But it's not a big deal.
Standardizing current practice is probably the best idea for this.
barmar
∂24-Oct-89 1036 X3J13-mailer issue &ENVIRONMENT-BINDING-ORDER
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Oct 89 10:36:30 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA03120; Tue, 24 Oct 89 11:36:15 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA08712; Tue, 24 Oct 89 11:36:13 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910241736.AA08712@defun.utah.edu>
Date: Tue, 24 Oct 89 11:36:11 MDT
Subject: issue &ENVIRONMENT-BINDING-ORDER
To: x3j13@sail.stanford.edu
This is issue #24 from my list.
Forum: Cleanup
Issue: &ENVIRONMENT-BINDING-ORDER
References: CLtL p. 145-146, 63
Issue DEFMACRO-LAMBDA-LIST
Category: CLARIFICATION
Edit History: V1, 24 Oct 1989, Sandra Loosemore
Problem Description:
Issue DEFMACRO-LAMBDA-LIST states that &ENVIRONMENT can appear once
anywhere at top level of a macro lambda list, but doesn't say anything
about the order in which the &ENVIRONMENT variable is bound relative
to the other lambda-list variables.
Some implementations treat &ENVIRONMENT as a mechanism for naming the
second argument to the macro function, in which case it is bound
before any of the variables in the actual destructuring pattern.
Other implementations bind it with the other lambda parameters in the
usual left-to-right order.
There are two proposals, FIRST and LEFT-TO-RIGHT.
Proposal (&ENVIRONMENT-BINDING-ORDER:FIRST):
Clarify that the &ENVIRONMENT parameter is bound along with &WHOLE
before any of other variables in the lambda list, regardless of where
&ENVIRONMENT appears in the lambda list.
Rationale:
This proposal provides a convenient explanation for the special
treatment of &WHOLE and &ENVIRONMENT at top-level in a DEFMACRO-style
lambda list. Basically, these two parameters are stripped out and
used to name the two arguments to the macro function, then the binding
of the remaining arguments is handled exactly the same as at
non-top-level or in a DESTRUCTURING-BIND. It is also very
straightforward to implement this model (as opposed to having
special parsing code for destructuring top-level DEFMACRO lambda
lists).
Proposal (&ENVIRONMENT-BINDING-ORDER:LEFT-TO-RIGHT):
Clarify that the all lambda variables in a DEFMACRO-style lambda list
are bound left-to-right, including the &ENVIRONMENT parameter.
Rationale:
This is more consistent with the order in which variables in ordinary
lambda lists are bound.
Current Practice:
Lucid CL, Utah CL, and KCL implement proposal BEFORE. CMU CL
implements proposal LEFT-TO-RIGHT.
Cost to implementors:
The changes are probably localized but potentially hairy. It is
possible that in some implementations it might be easier to completely
replace the code which handles lambda-list parsing and destructuring
than to try to patch it. Proposal BEFORE is probably easier to
implement initially but the cost of converting an existing
implementation is probably about the same for both proposals.
Cost to users:
There are probably few user programs that would be affected by a
change in the binding order of &ENVIRONMENT parameters.
Benefits:
The language specification is made more precise.
Discussion:
-------
∂24-Oct-89 1221 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 24 Oct 89 12:21:19 PDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA03410; Tue, 24 Oct 89 15:21:05 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA20011; Tue, 24 Oct 89 11:44:18 PDT
Received: by fiona.Franz.COM (3.2/FI-1.0)
id AA02184; Tue, 24 Oct 89 11:44:10 PDT
Date: Tue, 24 Oct 89 11:44:10 PDT
From: smh@Franz.COM (Steve Haflich)
Message-Id: <8910241844.AA02184@fiona.Franz.COM>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 24 Oct 89 10:24:39 MDT <8910241624.AA08645@defun.utah.edu>
Subject: issue DEFMACRO-BLOCK-SCOPE
Franz's Allegro Common Lisp also implements INCLUDES-BINDINGS.
∂24-Oct-89 1250 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Oct 89 12:50:22 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA18622; Tue, 24 Oct 89 13:50:04 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA08819; Tue, 24 Oct 89 13:49:58 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910241949.AA08819@defun.utah.edu>
Date: Tue, 24 Oct 89 13:49:56 MDT
Subject: issue DEFINE-COMPILER-MACRO, version 3
To: x3j13@sail.stanford.edu
We passed version 2 (proposal NEW-FACILITY) of this issue at the June
meeting. Since then there has been some confusion about what exactly
was voted on, and some additional suggestions for changes to this
feature.
This writeup includes the unchanged proposal NEW-FACILITY and a new
proposal, FIX-BUGS, that is a list of amendments to NEW-FACILITY. I
thought this organization would make it easier to understand what the
differences are and why. We might want to consider voting on the
items separately.
Forum: Cleanup
Issue: DEFINE-COMPILER-MACRO
Related Issues: Issue DEFINE-OPTIMIZER
Issue SYNTACTIC-ENVIRONMENT-ACCESS
Issue LISP-SYMBOL-REDEFINITION
References: CLtL p. 151, p. 152
Category: ADDITION
Edit-History: 28-Jun-89, Version 1 by JonL White and Steve Haflich
12-Jul-89, Version 2 by Loosemore
24-Oct-89, Version 3 by Loosemore
Status: Version 2 (proposal NEW-FACILITY) passed at June 89 meeting
Problem Description:
Occasionally one would like to define a macro which is expanded only
"in the compiler", but which would not normally affect the actions of
the interpreter. For example, the OSS/Generator proposal has several
functions for which it would like to specify some alternative source
code sequences for the compiler to compiler, rather than just
compiling a closed-call to the function.
Also, it is occasionally desirable for a macro expansion to be
different based on the various compiler optimization qualities (e.g.,
SPEED, SAFETY, and so on); but if the expansion is for the interpreter
rather than the compiler, then such variation based on compiler
optimizers is not needed.
So-called "compiler optimizers" are just a special case of macro-like
expansions, which are limited to being done "in the compiler" and
which are generally required to produce semantically equivalent code
to replace an apparent function call. There is a need for a facility
that at least covers this capability.
Proposal: (DEFINE-COMPILER-MACRO:NEW-FACILITY):
Introduce a new facility by additions as follows:
Macro:
DEFINE-COMPILER-MACRO name lambda-list {doc-string} {declarations}* {form}*
This is just like DEFMACRO except the definition isn't stored in the
symbol function cell of 'name', and isn't seen by MACROEXPAND-1 (but
is seen by COMPILER-MACROEXPAND-1 -- see below). Like DEFMACRO, the
lambdalist may include &ENVIRONMENT and &WHOLE. The definition is
"global"; there is no explicit provision for defining local compiler
macros in the way that MACROLET defines local macros.
A toplevel call to DEFINE-COMPILER-MACRO in a file being compiled by
COMPILE-FILE has an effect on the compilation environment similar to
what a call to DEFMACRO would have, except it is noticed as a
"compiler macro".
Function:
COMPILER-MACRO-FUNCTION name &OPTIONAL env
If 'name' is a symbol that has been defined as a compiler macro, then
calling COMPILER-MACRO-FUNCTION on it returns the macro expansion
function; otherwise it returns NIL. 'name' must be a symbol. The
local lexical environment may override a global definition for 'name'
by defining a local function or local macro (such as by FLET,
MACROLET, etc.), in which case NIL is returned; the optional argument
'env' is provided so that clients may pass in &environment objects for
this purpose.
SETF may be used with COMPILER-MACRO-FUNCTION to install a function as
the expansion function for the compiler macro 'name', analogously to
using SETF on MACRO-FUNCTION. SETF'ing to NIL removes any existing
compiler macro definition. Like MACRO-FUNCTION, the SETF value (if not
NIL) must be a function of two arguments: the entire macro call, and
the environment. The second argument to COMPILER-MACRO-FUNCTION must
be omitted when it is SETFed.
Functions:
COMPILER-MACROEXPAND form &OPTIONAL env
COMPILER-MACROEXPAND-1 form &OPTIONAL env
This is just like MACROEXPAND and MACROEXPAND-1 (see CLtL p.151)
except that the expander function is obtained as if by a call to
COMPILER-MACRO-FUNCTION on the CAR of 'form' rather than by a call to
MACRO-FUNCTION. There are three cases wherein no expansion happens:
(1) There is no compiler macro definition for the CAR of 'form';
(2) There is such a definition but there is also a NOTINLINE
declaration, either globally or in the lexical environment 'env';
(3) A global compiler macro definition is shadowed by a local
function or macro definition (such as by FLET, LABELS, or MACROLET).
Note that if there is no expansion, the original form is returned as
the first value, and NIL as the second value.
When COMPILER-MACROEXPAND-1 discovers that there is to be an expansion
it does it by calling the function in *MACROEXPAND-HOOK* (see CltL p.152).
The purpose of this facility is to permit selective source-code
transformations based on whether the compiler is processing the code.
When the compiler is about to compile a nonatomic form, it first calls
COMPILER-MACROEXPAND-1 repeatedly until there is no more expansion
(there might not be any to begin with). Then it continues its
remaining processing, which may include calling MACROEXPAND-1 etc.
The compiler is required to expand compiler macros; it is unspecified
whether the interpreter does so. The intention is that only the
compiler will do so, but the range of possible "compiled-only"
implementation strategies precludes any firm specification.
Note that a compiler macro may decline to provide any expansion merely
by returning the original form; this is useful when using the facility
to put "compiler optimizers" on various function names. For example,
here is a compiler macro that "optimizes" the 0- and 1-argument cases of
a function called PLUS:
(define-compiler-macro plus (&whole form &rest args)
(case (length args)
(0 0)
(1 (car args))
(t form)))
The issue LISP-SYMBOL-REDEFINITION precludes user definition of any
compiler macros for symbols external in the Lisp package that have a
definition as a function, macro, or special form.
Note that compiler macros do not appear in information returned by
FUNCTION-INFORMATION; they are global, and their interaction
with other lexical and global definitions can be reconstructed by
COMPILER-MACRO-FUNCTION. It is up to code-walking programs to decide
whether to invoke compiler macro expansion.
Rationale:
Many implementations have it. Many users have requested a way to add
source-code "optimizers" to the compiler.
Other than INLINE declarations for functions there is no other way to
customize how calls to a specific function are compiled. DEFMACRO is
not usable for this purpose since it requires use of the
symbol-function cell, which would prevent the functional definition
from being active in the compilation environment.
Proposal: (DEFINE-COMPILER-MACRO:FIX-BUGS):
Amend proposal NEW-FACILITY as follows:
(1) Clarify that it is unspecified whether any language processor
(compiler, evaluator, random code walker) must actually use the
expansion of a compiler macro in place of the original call.
Rationale:
A number of people have indicated that this point was discussed and
agreed upon at the June 89 meeting, but there is no record of it in
the minutes and no formal amendment to the proposal was made at that
time. Because of this, there is still some confusion about whether
this was really the intent of the proposal.
(2) Change the proposal to leave it unspecified whether any language
processor must invoke the compiler macro function.
Rationale:
Items (1) and (2) together place compiler-macros in much the same
category as declarations. That is, a language processor can determine
when it is appropriate to apply compiler macros based on declarations
or other implementation-dependent considerations. This is more
consistent with other parts of the language, where we have tried to
minimize the differences between the semantics of interpreted and
compiled code.
One specific reason for removing the requirement that the compiler
always expand compiler macros is that there may be a substantial
compile-time performance penalty involved in doing so.
Implementations might wish to use the COMPILATION-SPEED optimize
quality to control this, for example.
(3) Change the proposal so that expansion of compiler macros by
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1 is not inhibited by
NOTINLINE declarations. Instead, forbid language processors from
making use of compiler macro expansions when the corresponding
function has been declared NOTINLINE, in the same way that they are
now required not to perform inline expansion of functions in the
presence of NOTINLINE declarations.
Rationale:
This is primarily an aesthetic change to make the relationship
between COMPILER-MACROEXPAND/COMPILER-MACROEXPAND-1 and
COMPILER-MACRO-FUNCTION exactly analogous to the relationship between
MACROEXPAND/MACROEXPAND-1 and MACRO-FUNCTION. In addition, in
combination with item (2) it removes the requirement of the unamended
proposal that compilers pay attention to NOTINLINE declarations. (In
other words, processors would only be required to pay attention
to NOTINLINE declarations if they also perform either inline
transformations or compiler macro substitution.)
(4) Clarify that issue LISP-SYMBOL-REDEFINITION does not, in fact,
prohibit user definition of compiler macros for symbols in the
common-lisp package. Instead, this is a constraint which has been
added with this issue. It is consistent with other constraints
in issue LISP-SYMBOL-REDEFINITION but is not implied by that issue.
Rationale:
This was an unintentional mis-statement in the language of the
original proposal.
(5) Clarify that if COMPILE-FILE chooses to use the expansion of a
top-level compiler macro call in place of the original macro call,
then that expansion is also treated as a top-level form by
COMPILE-FILE for the purposes of EVAL-WHEN processing.
Rationale:
The original proposal didn't say anything about this, but it is
consistent with the treatment of ordinary top-level macro calls by
COMPILE-FILE.
Current Practice:
Lucid, Franz, and Symbolics have very similar facilities. Hunoz about
the others?
Cost to Implementors:
Minor: implement a method for storing named expansion functions, and
tweak the compiler in one or two places.
Cost to Users:
None. This is an upward-compatible addition.
Benefits:
Increased portability for clients of the existing facilities.
Discussion:
There has been extensive discussion under the issue DEFINE-OPTIMIZER.
-------
∂24-Oct-89 1638 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 3
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 24 Oct 89 16:38:11 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Tue, 24 Oct 89 19:39:51 -0400
Date: Tue, 24 Oct 89 19:34 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINE-COMPILER-MACRO, version 3
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8910241949.AA08819@defun.utah.edu>
Message-Id: <19891024233456.3.BARMAR@OCCAM.THINK.COM>
Date: Tue, 24 Oct 89 13:49:56 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Forum: Cleanup
Issue: DEFINE-COMPILER-MACRO
Related Issues: Issue DEFINE-OPTIMIZER
Issue SYNTACTIC-ENVIRONMENT-ACCESS
Issue LISP-SYMBOL-REDEFINITION
References: CLtL p. 151, p. 152
Category: ADDITION
Edit-History: 28-Jun-89, Version 1 by JonL White and Steve Haflich
12-Jul-89, Version 2 by Loosemore
24-Oct-89, Version 3 by Loosemore
Status: Version 2 (proposal NEW-FACILITY) passed at June 89 meeting
It would have been better if you'd done this as a separate issue, rather
than a new version of the old issue. It was not obvious which sections
outside the Proposal section were new and which were old. I decided
that the only change was the additional proposal. This means that there
are no Problem Description, Current Practice, Cost to
Implementors/Users, Esthetics, or Discussion sections associated with
your new proposal. If someone were to try to read this issue knowing
the derivation, they'd find it very inconsistent (for instance, the
Current Practice section says that several implementations "have very
similar facilities", but doesn't say which variant they are more similar
to).
Also, it's not clear what you expect us to do with this at the next
meeting? Technically, by combining your amendments into the original
issue, you're requiring us to bring the issue up for reconsideration,
which means that we go back to the state before they were approved; if
we then get deadlocked on it, compiler macros go away (I won't cry, but
others might not like it). If you just want to propose changes to an
existing facility (anything we've approved is has the same status as
CLtL), write a new issue.
Proposal: (DEFINE-COMPILER-MACRO:FIX-BUGS):
Amend proposal NEW-FACILITY as follows:
(2) Change the proposal to leave it unspecified whether any language
processor must invoke the compiler macro function.
Rationale:
Items (1) and (2) together place compiler-macros in much the same
category as declarations. That is, a language processor can determine
when it is appropriate to apply compiler macros based on declarations
or other implementation-dependent considerations. This is more
consistent with other parts of the language, where we have tried to
minimize the differences between the semantics of interpreted and
compiled code.
One specific reason for removing the requirement that the compiler
always expand compiler macros is that there may be a substantial
compile-time performance penalty involved in doing so.
Implementations might wish to use the COMPILATION-SPEED optimize
quality to control this, for example.
There was quite a bit of discussion about this, and NEW-FACILITY is the
result of this. It was intentional that the language require compiler
macros to be invoked. Some people suggested that compiler macros might
try to communicate with each other, and licensing the implementation to
arbitrarily decide not to invoke one of the compiler macros would screw
up such code.
∂24-Oct-89 2110 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 89 21:10:52 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 25 Oct 89 00:10:19 EDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@sail.stanford.edu
Subject: Re: issue INSPECT-RETURN-VALUE
In-reply-to: Your message of Mon, 23 Oct 89 16:42:09 -0600.
<8910232242.AA07990@defun.utah.edu>
Date: Wed, 25 Oct 89 00:10:09 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I'm very strongly oppposed to Sandra's proposal for INSPECT. INSPECT is
primarily useful for interactively crawling around on really big (perhaps
circular) objects; little tiny objects you just print and look at. If
INSPECT insists on returning (and therefore printing) the original object,
that makes it *much* less useful as an interactive debugging tool. That's
the point Guy made some time ago, and I agree with him. I'd favor leaving
the return value of INSPECT unspecified, but if we do specify it, it should
return NIL or no values.
Sandra's response to this is unconvincing. I don't want to have to mess
with all the damned print switches every time I'm about to use INSPECT,
just so that it won't gratuitously print too much when it exits.
If an implemenation wants to provide a way of returning a modified data
structure from inspect, that's fine, but I still wouldn't want this
modified structure just to be returned as a value.
-- Scott
∂25-Oct-89 0351 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Oct 89 03:51:41 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA17377g; Wed, 25 Oct 89 03:48:48 PDT
Received: by bhopal id AA27966g; Wed, 25 Oct 89 03:50:42 PDT
Date: Wed, 25 Oct 89 03:50:42 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910251050.AA27966@bhopal>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 24 Oct 89 10:24:39 MDT <8910241624.AA08645@defun.utah.edu>
Subject: issue DEFMACRO-BLOCK-SCOPE
Although as Barry says, this issue is "no big deal", EXCLUDES-BINDINGS
certainly has simplicity of specification in its favor, as well as
consistency with the semantics of block scope for initforms in DEFUN.
I'd find it very hard to believe that even the "incompatible" change of
EXCLUDES-BINDINGS would be an imposition for anyone (because -- it seems
to me -- it's very unlikely that any existing code depends upon either
behaviour). Evidence to the contrary is hereby solicited.
-- JonL --
∂25-Oct-89 0539 X3J13-mailer issue INSPECT-RETURN-VALUE
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Oct 89 05:39:21 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA18125g; Wed, 25 Oct 89 05:36:36 PDT
Received: by bhopal id AA28089g; Wed, 25 Oct 89 05:38:35 PDT
Date: Wed, 25 Oct 89 05:38:35 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910251238.AA28089@bhopal>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 23 Oct 89 16:42:09 MDT <8910232242.AA07990@defun.utah.edu>
Subject: issue INSPECT-RETURN-VALUE
re: Specify that INSPECT returns the object being inspected. ...
This is ambiguous. Does it refer to the object that was used as the
argument to INSPECT, or does it mean some randomly-selected object?
[The "random selection" capability is implicit in the interactive
and otherwise unspecified nature of the operation of INSPECT].
Although Lucid's INSPECT returns the most recently "selected" object,
I agree with Scott and Guy that there has not been a demonstration
of need to pin this one down, other than to say that the return value
may be implementation dependent.
-- JonL --
∂25-Oct-89 0702 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Oct 89 07:02:28 PDT
Received: by ti.com id AA15595; Wed, 25 Oct 89 09:03:05 -0500
Received: from m2.csc.ti.com by tilde id AA28421; Wed, 25 Oct 89 08:52:38 CDT
Received: by m2.csc.ti.com (5.52/4.7)
id AA05240; Wed, 25 Oct 89 08:52:34 CDT
Date: Wed, 25 Oct 89 08:52:34 CDT
From: bartley@m2.csc.ti.com (David Bartley)
Message-Id: <8910251352.AA05240@m2.csc.ti.com>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
Subject: Re: issue INSPECT-RETURN-VALUE
Reply-To: Bartley@ti-csl.csc.ti.com
I also oppose Sandra's proposal that INSPECT be required to return the
inspected (and possibly large or circular) value. I should think her
needs would be better met by having an interactive command that exits
INSPECT with whatever value she wants. In other words, leaving the
returned value unspecified allows implementations to give users the
capability to return whatever value they want.
--db--
∂25-Oct-89 0757 X3J13-mailer Query on ISSUE: LOAD-OBJECTS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Oct 89 07:57:00 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA18878g; Wed, 25 Oct 89 07:54:14 PDT
Received: by bhopal id AA28268g; Wed, 25 Oct 89 07:56:12 PDT
Date: Wed, 25 Oct 89 07:56:12 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910251456.AA28268@bhopal>
To: X3J13@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Query on ISSUE: LOAD-OBJECTS
It says somewhere in this proposal:
MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
an error.
Surely this can't mean "user-defined", since that would effectively prohibit
an implementation from using STANDARD-OBJECTs for internal purposes. Perhaps
the next sentence in that paragraph is all that is really needed:
It is valid to implement this [default error-signaling behaviour] either
by defining default methods on STANDARD-OBJECT and STRUCTURE-OBJECT that
signal an error or by having no applicable method for those classes.
with the implication that user-defined classes of metaclass either
STANDARD-CLASS or STRUCTURE-CLASS will see no other system-provided
methods on MAKE-LOAD-FORM.
-- JonL --
∂25-Oct-89 0805 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Oct 89 08:05:43 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA22052; Wed, 25 Oct 89 09:05:30 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA09630; Wed, 25 Oct 89 09:05:27 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910251505.AA09630@defun.utah.edu>
Date: Wed, 25 Oct 89 09:05:26 MDT
Subject: Re: issue INSPECT-RETURN-VALUE
To: x3j13@sail.stanford.edu
In-Reply-To: Bartley@ti-csl.csc.ti.com, Wed, 25 Oct 89 08:52:34 CDT
Perhaps I should have been a little more explicit in the writeup about
why I wanted this feature.
I have been working on developing some debugging tools lately.
Although this stuff is probably going to eventually be incorporated
into Utah Common Lisp, the parts I have working now are mostly
portable, assuming you have things like CLX and CLUE working in your
favorite Lisp implementation. One of the features my stepper supports
is that users can inspect the values of lexical variable bindings,
arguments to function applications, return values, etc. from within
the debugger. Basically, I want to be able to use this mechanism to
let the user modify the value as well as examine it. I do have an
X-based graphical inspector that works well for this, but sometimes
it's useful to see text instead of pictures, especially since you
might feel more familiar and comfortable with the user interface of
the standard system inspector. But I can't do this unless INSPECT is
guaranteed to return a useful value. Merely leaving the possibility
open that it *might* return a useful value is not enough. Also, I
would like to be able to recursively invoke the standard system
INSPECT utility from my graphical inspector so that users again have
the choice of pictures or text for browsing through substructure.
If everybody else is firmly convinced that supporting this kind of
application is not important, I will withdraw my proposal. I guess
the real question is whether we want to treat INSPECT as something
that is invoked only from the read/eval/print loop or whether it is
something that might usefully be called from programs.
-Sandra
-------
∂25-Oct-89 0806 X3J13-mailer issue INSPECT-RETURN-VALUE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Oct 89 08:06:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 681304; 25 Oct 89 11:04:33 EDT
Date: Wed, 25 Oct 89 11:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue INSPECT-RETURN-VALUE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Scott.Fahlman@B.GP.CS.CMU.EDU,
Jon L White <jonl@lucid.com>, Bartley@ti-csl.csc.ti.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8910232242.AA07990@defun.utah.edu>,
The message of 25 Oct 89 00:10 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
<8910251238.AA28089@bhopal>,
<8910251352.AA05240@m2.csc.ti.com>
Message-ID: <19891025150420.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
If I may summarize this conversation, Sandra wants to be able to call
INSPECT from a program and have it serve as a useful front end between
that program and the user, while her interlocutors want to call INSPECT
from the read-eval-print loop.
What we are seeing is, of course, the tension between the use of INSPECT
as a function and the use of INSPECT as a command. It is silly of
Common Lisp to confuse the two. Just because it is an extremely useful
and powerful feature of almost all Lisp systems that the full
programming language can be used as part of the command language,
doesn't mean that the command language must be 100% identical to the
programming language. A more reasonable approach would be to have an
INSPECT function that behaves appropriately for a function and an
INSPECT command that behaves appropriately for a command. Then of
course the function would return a useful value, and of course the
command would not print something stupid when it exits, and the two
could coexist peacefully. I suppose there is no chance of reaching
concensus that Common Lisp, the language, should not contain a
half-baked attempt at programming environment commands. As it is,
functions like INSPECT, DESCRIBE, and ED aren't sure whether they are
supposed to be called by programs or are supposed to be used as commands
by users. Sandra's program will have to be mildly non-portable and call
the internal function version of INSPECT that has a different name in
every implementation, and users will have to either use Common Lisp's
feeble attempt at a programming environment that is somewhat the same in
every implementation, or learn a powerful but idiosyncratic set of
commands afresh each time they use a new implementation.
∂25-Oct-89 0846 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 89 08:45:55 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 25 Oct 89 11:45:17 EDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@sail.stanford.edu
Subject: Re: issue INSPECT-RETURN-VALUE
In-reply-to: Your message of Wed, 25 Oct 89 09:05:26 -0600.
<8910251505.AA09630@defun.utah.edu>
Date: Wed, 25 Oct 89 11:45:14 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Sandra,
I am not suggesting that "supporting this kind of application" is not
useful. I am suggesting that destroying the usefulness of INSPECT as an
interactive tool in order to make such applications a bit easier is not a
good idea. Let me suggest that we leave INSPECT alone and that you use the
following construct within your portable toolkit:
(defun object-returning-inspect (object)
(inspect object)
object)
-- Scott
∂25-Oct-89 0906 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Oct 89 09:06:39 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA24499; Wed, 25 Oct 89 10:06:23 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA09730; Wed, 25 Oct 89 10:06:19 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910251606.AA09730@defun.utah.edu>
Date: Wed, 25 Oct 89 10:06:18 MDT
Subject: Re: issue INSPECT-RETURN-VALUE
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, x3j13@sail.stanford.edu
In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU, Wed, 25 Oct 89 11:45:14 EDT
> Date: Wed, 25 Oct 89 11:45:14 EDT
> From: Scott.Fahlman@B.GP.CS.CMU.EDU
>
> Let me suggest that we leave INSPECT alone and that you use the
> following construct within your portable toolkit:
>
> (defun object-returning-inspect (object)
> (inspect object)
> object)
That is, in fact, what I am now doing. The problem is that in some
implementations, INSPECT does allow the user to specify a replacement
object and/or destructively modify the object -- that is, it acts as
an input tool as well as an output tool. Simply returning the
original object all the time, even when the user tried to specify some
other object, is less than satisfactory.....
-Sandra
-------
∂25-Oct-89 1018 X3J13-mailer Query on ISSUE: LOAD-OBJECTS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Oct 89 10:18:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 681390; 25 Oct 89 13:16:47 EDT
Date: Wed, 25 Oct 89 13:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Query on ISSUE: LOAD-OBJECTS
To: Jon L White <jonl@lucid.com>
cc: X3J13@SAIL.Stanford.edu, Common-Lisp-Object-System@SAIL.Stanford.edu
In-Reply-To: <8910251456.AA28268@bhopal>
Message-ID: <19891025171650.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 25 Oct 89 07:56:12 PDT
From: Jon L White <jonl@lucid.com>
It says somewhere in this proposal:
MAKE-LOAD-FORM of an object of * metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
an error.
Surely this can't mean "user-defined", since that would effectively prohibit
an implementation from using STANDARD-OBJECTs for internal purposes.
At the asterisk above I would insert "user-defined class and".
Perhaps
the next sentence in that paragraph is all that is really needed:
It is valid to implement this [default error-signaling behaviour] either
by defining default methods on STANDARD-OBJECT and STRUCTURE-OBJECT that
signal an error or by having no applicable method for those classes.
with the implication that user-defined classes of metaclass either
STANDARD-CLASS or STRUCTURE-CLASS will see no other system-provided
methods on MAKE-LOAD-FORM.
Yes, the idea was that user-defined objects would not inherit a method that
would do something they didn't want.
I don't know whether MAKE-LOAD-FORM has been put into the specification
yet. Perhaps the best way to address this issue would be to make the
writeup for MAKE-LOAD-FORM speak about conforming programs, rather than
about implementations. Then it wouldn't accidentally imply anything about
what implementations can and cannot do with their own internal objects.
∂25-Oct-89 1026 X3J13-mailer Re: issue INSPECT-RETURN-VALUE
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Oct 89 10:25:15 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Wed, 25 Oct 89 13:26:13 -0400
Date: Wed, 25 Oct 89 13:21 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: issue INSPECT-RETURN-VALUE
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, x3j13@sail.stanford.edu
In-Reply-To: <8910251553.AA00797@Think.COM>
Message-Id: <19891025172143.6.BARMAR@OCCAM.THINK.COM>
Date: Wed, 25 Oct 89 11:45:14 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Let me suggest that we leave INSPECT alone and that you use the
following construct within your portable toolkit:
(defun object-returning-inspect (object)
(inspect object)
object)
Give Sandra some credit; if it were this simple, she wouldn't be
fighting this battle. The above definition doesn't provide a way for
the user to specify an alternate return value, which is what she wants.
However, I think I've got an idea. Some inspectors provide some form of
read-eval-inspect loop within the inspector (Genera does), as well as a
way to set a variable to a component being displayed (Genera has "Set
/" in the inspector menu). Then define
(defun my-inspect (object)
(let ((*inspect-value* object))
(declare (special *inspect-value*))
(inspect object)
*inspect-value*))
Then document that the user should use the above features to set
*inspect-value* to the object they wish to return, if the inspector
provides a way to set a variable. For instance, in Genera's inspector,
I could use "Set /" to select an object, then type (setq *inspect-value*
/) in the read-eval-inspect loop before exiting.
barmar
∂25-Oct-89 1035 X3J13-mailer Meeting at PARC
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Oct 89 10:35:17 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 OCT 89 10:34:53 PDT
Date: Wed, 25 Oct 89 10:13 PDT
From: Gregor.pa@Xerox.COM
Subject: Meeting at PARC
To: X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
Message-ID: <19891025171315.4.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Just to clarify, the X3J13 meeting is still on at PARC. The Hyatt and
PARC both survived the quake.
You out of town people will get an interesting chance to see what it
means for a building to suffer "only cosmetic damage". PARC is a mess.
Floor tiles, walls, and ceiling tiles are broken all over the building.
It is a deliberate part of the design of the building for parts of it to
separate and vibrate. That prevents real structural damage. But, we
get the cosmetic damage you will see.
One of the HP buildings down the road was condemned and will, I heard,
have to be torn down.
-------
∂25-Oct-89 1041 X3J13-mailer define-method-combination
Received: from cambridge.apple.com (brazil.cambridge.apple.com) by SAIL.Stanford.EDU with TCP; 25 Oct 89 10:41:30 PDT
Received: by cambridge.apple.com (4.1/SMI-DDN) id AA11484; Wed, 25 Oct 89 13:43:31 EDT
Date: Wed, 25 Oct 89 13:43:31 EDT
From: bill@cambridge.apple.com (Bill St. Clair)
Message-Id: <8910251743.AA11484.bill@cambridge.apple.com>
To: x3j13@SAIL.Stanford.EDU
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra@cs.utah.edu,
RPG@SAIL.Stanford.EDU
Subject: define-method-combination
I have been very converned about the definition of define-method-combination
since reading over the description and thinking about implementing it, so
I was glad to see that Sandra had the same argument as I. Apple will also
complain loudly during the public review if define-method-combination is not
modified or removed.
I have no argument with the definition per se, but it requires an
evaluator or compiler at run-time, something that severely impacts
using Lisp as a delivery vehicle. I have seen tools from Symbolics &
Lucid that work at making small Lisp delivery tools. We are working
on one here at Apple, and I'm sure there are others who will be very
unhappy about including the compiler in their run-time worlds in order to
support define-method-combination.
I will be implementing a function-returning define-method-combination in
the near future, but will not complete it before the upcoming meeting. I
suggest that we remove define-method-combination from the standard (or include
only the short form), until enough research has been done to include a version
that has acceptable run-time behavior.
Bill St. Clair
Disclaimer: These opinions are mine, not necessarily those of Apple Computer.
(I hate disclaimers).
∂25-Oct-89 1145 X3J13-mailer define-method-combination
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Oct 89 11:45:18 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Wed, 25 Oct 89 14:46:24 -0400
Date: Wed, 25 Oct 89 14:41 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: define-method-combination
To: Bill St. Clair <bill@cambridge.apple.com>
Cc: x3j13@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
sandra@cs.utah.edu, RPG@SAIL.Stanford.EDU
In-Reply-To: <8910251743.AA11484.bill@cambridge.apple.com>
Message-Id: <19891025184155.9.BARMAR@OCCAM.THINK.COM>
Date: Wed, 25 Oct 89 13:43:31 EDT
From: bill@cambridge.apple.com (Bill St. Clair)
I have no argument with the definition per se, but it requires an
evaluator or compiler at run-time, something that severely impacts
using Lisp as a delivery vehicle.
It only needs this at runtime if the application actually uses the long
form of DEFINE-METHOD-COMBINATION. I assume that your tool for building
delivery images leaves the evaluator in if EVAL is used explicitly; in
this case, DEFINE-METHOD-COMBINATION would also have to cause this. I
submit that applications are more likely to use EVAL than the long form
of DEFINE-METHOD-COMBINATION.
barmar
∂25-Oct-89 1221 X3J13-mailer issue INSPECT-RETURN-VALUE
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Oct 89 12:21:48 PDT
Received: from edsel ([192.9.200.1]) by heavens-gate id AA20452g; Wed, 25 Oct 89 12:18:49 PDT
Received: from chappaquiddick. by edsel id AA17532g; Wed, 25 Oct 89 12:14:21 PDT
Received: by chappaquiddick. (4.0/SMI-4.0)
id AA05315; Wed, 25 Oct 89 12:23:31 PDT
Date: Wed, 25 Oct 89 12:23:31 PDT
From: jlm@lucid.com (Jim McDonald)
Message-Id: <8910251923.AA05315@chappaquiddick.>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 25 Oct 89 09:05:26 MDT <8910251505.AA09630@defun.utah.edu>
Subject: issue INSPECT-RETURN-VALUE
INSPECT could return an encapsulation with a short print form and with
the real object easily accessible. E.g.,
(setq result (inspect *very-large-structure*))
...user rummages around and chooses to return <very-large-component>...
-> :Q [or whatever]
#<ENCAPSULATED 0x12345>
> (contents result)
<very-large-component>
>
There might be other contexts in which this would be a useful trick...
jlm
∂25-Oct-89 1225 X3J13-mailer define-method-combination
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Oct 89 12:25:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 681523; 25 Oct 89 15:23:31 EDT
Date: Wed, 25 Oct 89 15:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Barry Margolin <barmar@Think.COM>, Bill St. Clair <bill@cambridge.apple.com>
cc: x3j13@SAIL.Stanford.EDU, sandra@cs.utah.edu, RPG@SAIL.Stanford.EDU
In-Reply-To: <19891025184155.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <19891025192321.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 25 Oct 89 14:41 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Wed, 25 Oct 89 13:43:31 EDT
From: bill@cambridge.apple.com (Bill St. Clair)
I have no argument with the definition per se, but it requires an
evaluator or compiler at run-time, something that severely impacts
using Lisp as a delivery vehicle.
It only needs this at runtime if the application actually uses the long
form of DEFINE-METHOD-COMBINATION. I assume that your tool for building
delivery images leaves the evaluator in if EVAL is used explicitly; in
this case, DEFINE-METHOD-COMBINATION would also have to cause this. I
submit that applications are more likely to use EVAL than the long form
of DEFINE-METHOD-COMBINATION.
I've been too busy to write my intended long answer to this canard, so
I'll just send the short answer, and for now you'll have to trust me
that it's true.
Method combination does not require EVAL or COMPILE at run time. Yes,
it is possible to implement it in such a way that these are required.
That would be a poor implementation. It is also possible to implement
it in such a way that EVAL and COMPILE at run time are not required.
Depending on how your compiler works, the good implementation might
require COMPILE at load time, but not at run time. It doesn't require
EVAL at all.
I believe at least as strongly as anyone else in Lisp as a delivery
vehicle, and I wouldn't have promoted anything for CLOS that made using
Lisp for delivery impossible or extra difficult. On the other hand, I
had and have no objection to features that take some thought to figure
out how to implement in the Lisp in such a way as not to impact
delivery, and Common Lisp surely has its share of those.
∂25-Oct-89 1503 X3J13-mailer define-method-combination
Received: from cambridge.apple.com (brazil.cambridge.apple.com) by SAIL.Stanford.EDU with TCP; 25 Oct 89 15:03:49 PDT
Received: by cambridge.apple.com (4.1/SMI-DDN) id AA01198; Wed, 25 Oct 89 18:05:25 EDT
Date: Wed, 25 Oct 89 18:05:25 EDT
From: bill@cambridge.apple.com (Bill St. Clair)
Message-Id: <8910252205.AA01198.bill@cambridge.apple.com>
To: barmar@Think.COM
Cc: x3j13@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
sandra@cs.utah.edu, RPG@SAIL.Stanford.EDU
In-Reply-To: Barry Margolin's message of Wed, 25 Oct 89 14:41 EDT <19891025184155.9.BARMAR@OCCAM.THINK.COM>
Subject: define-method-combination
Date: Wed, 25 Oct 89 14:41 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Wed, 25 Oct 89 13:43:31 EDT
From: bill@cambridge.apple.com (Bill St. Clair)
I have no argument with the definition per se, but it requires an
evaluator or compiler at run-time, something that severely impacts
using Lisp as a delivery vehicle.
It only needs this at runtime if the application actually uses the long
form of DEFINE-METHOD-COMBINATION. I assume that your tool for building
delivery images leaves the evaluator in if EVAL is used explicitly; in
this case, DEFINE-METHOD-COMBINATION would also have to cause this. I
submit that applications are more likely to use EVAL than the long form
of DEFINE-METHOD-COMBINATION.
barmar
True, EVAL is as bad as DEFINE-METHOD-COMBINATION as far as application size
goes, e.g. both are unuseable for users who want their applications to fit
on a single floppy disk. The difference is that EVAL (or COMPILE) is
necessary for development, and usually disappears by delivery time.
DEFINE-METHOD-COMBINATION as currently defined is unuseable for people
who want to generate small applications, not only will the code it generates
be big, but it will be slow, and will cons ravenously (OK, so I'm
exagerating a little).
Users should have a way to define their own method combination types. But,
unless we have an option to DEFINE-METHOD-COMBINATION or a function-returning
dual to it, we're including a feature in Common Lisp that is primarily useful
for research. I think this puts define-method-combination in the same class
with the rest of the Meta-Object Protocol: something that's not ready to be
in the standard this time around.
Bill
∂25-Oct-89 1518 X3J13-mailer define-method-combination
Received: from cambridge.apple.com (brazil.cambridge.apple.com) by SAIL.Stanford.EDU with TCP; 25 Oct 89 15:18:51 PDT
Received: by cambridge.apple.com (4.1/SMI-DDN) id AA01302; Wed, 25 Oct 89 18:20:53 EDT
Date: Wed, 25 Oct 89 18:20:53 EDT
From: bill@cambridge.apple.com (Bill St. Clair)
Message-Id: <8910252220.AA01302.bill@cambridge.apple.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, x3j13@SAIL.Stanford.EDU, sandra@cs.utah.edu,
RPG@SAIL.Stanford.EDU
In-Reply-To: David A. Moon's message of Wed, 25 Oct 89 15:23 EDT <19891025192321.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: define-method-combination
Date: Wed, 25 Oct 89 15:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
<stuff>
Method combination does not require EVAL or COMPILE at run time. Yes,
it is possible to implement it in such a way that these are required.
That would be a poor implementation. It is also possible to implement
it in such a way that EVAL and COMPILE at run time are not required.
Depending on how your compiler works, the good implementation might
require COMPILE at load time, but not at run time. It doesn't require
EVAL at all.
If this is indeed true, then I retract all my flames. I'll be very interested
in talking with you about it at PARC.
I believe at least as strongly as anyone else in Lisp as a delivery
vehicle, and I wouldn't have promoted anything for CLOS that made using
Lisp for delivery impossible or extra difficult. On the other hand, I
had and have no objection to features that take some thought to figure
out how to implement in the Lisp in such a way as not to impact
delivery, and Common Lisp surely has its share of those.
Touche.
∂25-Oct-89 1536 X3J13-mailer Re: define-method-combination
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Oct 89 15:36:47 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA10400; Wed, 25 Oct 89 16:36:20 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA10155; Wed, 25 Oct 89 16:36:17 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910252236.AA10155@defun.utah.edu>
Date: Wed, 25 Oct 89 16:36:16 MDT
Subject: Re: define-method-combination
To: bill@cambridge.apple.com (Bill St. Clair)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM,
x3j13@SAIL.Stanford.EDU, sandra@cs.utah.edu, RPG@SAIL.Stanford.EDU
In-Reply-To: bill@cambridge.apple.com (Bill St. Clair), Wed, 25 Oct 89 18:20:53 EDT
I also want to hear more about this technique for implementing method
combinations. It seems to me that any scheme that involves
precomputing or caching of effective methods, such as those that are
suggested in the CLOS document, can be defeated by the dynamic nature
of the class hierarchy (i.e., the ability to redefine a class at
runtime, changing its subclass/superclass relationships).
-Sandra
-------
∂26-Oct-89 0652 X3J13-mailer define-method-combination
Received: from goldhill.com (goddard.goldhill.com) by SAIL.Stanford.EDU with TCP; 26 Oct 89 06:52:24 PDT
Received: from god.goldhill.com by goddard.goldhill.com; Thu, 26 Oct 89 09:52:44 EDT
Received: by god.goldhill.com (4.0/SMI-4.0)
id AA02022; Thu, 26 Oct 89 09:48:52 EDT
Date: Thu, 26 Oct 89 09:48:52 EDT
From: phil@goldhill.com
Message-Id: <8910261348.AA02022@god.goldhill.com>
To: x3j13@sail.stanford.edu
In-Reply-To: Bill St. Clair's message of Wed, 25 Oct 89 13:43:31 EDT <8910251743.AA11484.bill@cambridge.apple.com>
Subject: define-method-combination
>From: bill@cambridge.apple.com
>
>I have been very converned about the definition of define-method-combination
>since reading over the description and thinking about implementing it, so
>I was glad to see that Sandra had the same argument as I. Apple will also
>complain loudly during the public review if define-method-combination is not
>modified or removed.
>
>I have no argument with the definition per se, but it requires an
>evaluator or compiler at run-time, something that severely impacts
>using Lisp as a delivery vehicle. I have seen tools from Symbolics &
>Lucid that work at making small Lisp delivery tools. We are working
>on one here at Apple, and I'm sure there are others who will be very
>unhappy about including the compiler in their run-time worlds in order to
>support define-method-combination.
Gold Hill is also concerned about requiring the compiler at runtime. We
do have an interpreter (and will always have EVAL availability for
runtimes) so the issue then becomes more a matter of speed and explaining
to naive users that the simple use of a CL function can incur great
overhead in the size of an application. Unfortuneatly explanations about
the realities of implementing the standard aren't directed at the
CL standards community but rather at relatively naive (from a system and
language implementation point of view) tool users.
∂26-Oct-89 1024 X3J13-mailer attendees of November meeting
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Oct 89 10:24:14 PDT
Received: from rose ([192.9.200.83]) by heavens-gate id AA27475g; Thu, 26 Oct 89 10:20:46 PDT
Received: by rose id AA04619g; Thu, 26 Oct 89 10:22:45 PDT
Date: Thu, 26 Oct 89 10:22:45 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8910261722.AA04619@rose>
To: x3j13@sail.stanford.edu
Subject: attendees of November meeting
Agenda, though sketchy, will go out tomorrow.
As always, send corrections, additions and changes. See you a week from
Monday!
---jan---
X3J13 Attendee Information
10/26/89
Name Institute Paid L1 L2 L3
David Bartley TI -0- y y y
Mary Boelk Johnson Controls -0- y y y
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
George Hadden Honeywell -0- y y y
Steve Haflich Franz, Inc. -0- y y y
Shaun Keller Encore -0- y y y
Timothy Koschmann Southern Illinois -0- y y y
Aaron Larson Honeywell -0- y y y
Joachim Laubsch HP Labs -0- y y y
Thom Linden IBM -0- - - -
David Loeffler MCC -0- y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines -0- y y y
Larry Masinter Xerox PARC -0- y y y
Robert Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Jarl Nilsson Franz -0- y y y
Chris Perdue Sun Microsystems -0- y - y
Dan Pierson Encore -0- y y y
Kent Pitman Symbolics -0- y y y
B. Raghavan NASA Ames Research Center -0- - - -
Bill St. Clair Apple Computer -0- y y y
Philip Stanhope Goldhill -0- y y y
Guy Steele Thinking Machines -0- y y y
Paul Tucker IBM -0- y y y
Walter van Roggen DEC -0- y y y
Ellen Waldrum TI -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂26-Oct-89 1118 X3J13-mailer issue MACRO-DECLARATIONS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Oct 89 11:17:56 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA07292; Thu, 26 Oct 89 12:17:45 -0600
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA10780; Thu, 26 Oct 89 12:17:42 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910261817.AA10780@defun.utah.edu>
Date: Thu, 26 Oct 89 12:17:40 MDT
Subject: issue MACRO-DECLARATIONS
To: x3j13@sail.stanford.edu
This is issue #3 from the list I mailed out earlier.
I wasn't sure exactly how to proceed with this issue, so I ended up
writing a proposal that agrees with the implementation I've been
working on myself. I think this is also compatible with everything we
have already voted on relating to declarations. I won't object if the
consensus is that more things should be left unspecified, but I do
think the standard ought to at least be explicit about the vagueness.
Forum: Cleanup
Issue: MACRO-DECLARATIONS
References: Issue SYMBOL-MACROLET-DECLARE
Issue DECLARATION-SCOPE
Issue DECLARE-TYPE-FREE
Issue DEFINE-COMPILER-MACRO
Issue DYNAMIC-EXTENT
Issue DYNAMIC-EXTENT-FUNCTION
Declarations (CLtL chapter 9)
Category: CLARIFICATION
Edit History: V1, 26 Oct 1989, Sandra Loosemore
Problem Description:
Issue SYMBOL-MACROLET-DECLARE defines a meaning for TYPE declarations
when the lexically visible "binding" of the symbol names a
symbol-macro. It also requires SYMBOL-MACRO to signal an error if a
SPECIAL declaration is provided in the body for a symbol which it
defines as a symbol-macro.
What is the meaning of a SPECIAL declaration appearing in some other
context (such as in a LOCALLY construct), for a symbol for which the
lexically apparent "binding" is a symbol-macro definition? How about
any other declaration which normally applies to a variable or function
binding (IGNORE, DYNAMIC-EXTENT, FTYPE, INLINE, NOTINLINE) when the
lexically apparent "binding" is a macro or symbol-macro definition?
Proposal (MACRO-DECLARATIONS:MAKE-EXPLICIT):
Clarify that the standard declarations that apply to function or variable
bindings have the following effects when the binding is a macro or
symbol-macro:
SPECIAL
SYMBOL-MACROLET signals an error if it includes a SPECIAL declaration
for any symbol that it binds as a symbol-macro. [Issue
SYMBOL-MACROLET-DECLARE] Presumably, this error is of type
PROGRAM-ERROR and is signalled at compile-time rather than run-time.
A SPECIAL declaration for a symbol whose lexically visible binding
is a symbol-macro causes that binding to be shadowed, in the same way
that a SPECIAL declaration shadows lexical variable bindings.
TYPE
A TYPE declaration for a symbol that names a symbol-macro is equivalent
to wrapping a THE expression around the expansion of that symbol-macro.
[Issue SYMBOL-MACROLET-DECLARE] This is meaningful regardless of whether
the declaration appears in the form that bound the symbol-macro or as a
free declaration within the scope of the symbol-macro binding. Multiple
TYPE declarations applying to a single symbol-macro binding are handled
in the same way as multiple TYPE declarations that apply to a
single variable binding.
FTYPE
This declaration is not valid when the lexically apparent binding
is a macro binding rather than a function binding.
IGNORE
This declaration is not valid when the lexically apparent binding
is a symbol-macro binding rather than a variable binding.
DYNAMIC-EXTENT
This declaration is not valid when the lexically apparent binding
is a symbol-macro or macro binding rather than a variable or
function binding.
NOTINLINE
In the presence of compiler-macro definitions, this declaration
affects references to macros in exactly the same way that it affects
references to functions. When the lexically apparent binding is a
macro that also has a compiler-macro definition, this declaration can
be used to indicate to a language processor that the macro (and not the
compiler-macro) definition should be used. [Issue DEFINE-COMPILER-MACRO.]
A NOTINLINE declaration for a macro has otherwise has no effect on
its expansion. Implementations are not free to ignore this declaration.
INLINE
To parallel treatment of NOTINLINE, in the presence of compiler-macro
definitions, this declaration affects references to macros in exactly
the same way that it affects references to functions. When the lexically
apparent binding is a macro that also has a compiler-macro definition,
this declaration can be used to indicate to a language processor that
the compiler-macro (and not the macro) definition should be used. An
INLINE declaration for a macro otherwise has no effect on its expansion.
Implementations are free to ignore this declaration.
In those situations where the use of the declaration is not valid, the
consequences of evaluating or compiling the program are undefined.
Rationale:
This proposal is primarily an explicit restatement of things which have
already been stated in other places, with some obvious interpolations
added.
Leaving the consequences undefined permits implementations to signal
an error, to assign some implementation-specific interpretation to
the declaration, or simply to ignore the declaration.
Current Practice:
Utah Common Lisp implements this proposal. It currently ignores all
declarations that apply to function or variable bindings when the
lexically visible binding is a macro or symbol-macro. The
declarations are added to the environment in the normal way but are
never examined by the interpreter or compiler. The exception is that
a SPECIAL declaration will shadow a symbol-macro definition in the
same way that it will shadow a lexical variable binding.
Neither HPCL-I nor Lucid CL complain about FTYPE or INLINE/NOTINLINE
declarations when the lexically visible function "binding" is a macro.
They are apparently being ignored. KCL ignores all declarations
that apply to function bindings (and doesn't yet support symbol-macros).
Cost to implementors:
Presumably small.
Cost to users:
It seems unlikely that this proposal would be an incompatible change
that causes many user programs to break, particularly given the
relative newness of symbol-macros and compiler-macros.
Benefits:
More complete specification of the language and less chance for confusion
to arise later on.
Aesthetics:
Some people might be bothered by the asymmetry between the handling of
TYPE and FTYPE declarations. Strictly speaking, the special handling for
TYPE declarations is unnecessary since one could explicitly include the
THE form in the expansion of the symbol-macro. Other people probably
think that the notational convenience outweighs the asymmetry.
Discussion:
-------
∂26-Oct-89 1216 X3J13-mailer WG16 Action Items
To: x3j13@SAIL.Stanford.EDU
CC: chaynes@IUVAX.CS.INDIANA.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The following are the action items sent from WG16 to be done before
the next WG16 meeting, which is the first week of February. I quote:
1 - Short-term standard
Each member body willing to participate to the ``CL subset approach'' is
requested to produce for the next WG16 meeting (by end of 1989):
- Its definition of ``Kernel'' concept
- The list of features that must be present in the Kernel.
It is stressed that these informations must be electronically
circulated with WG16 *before* the next meeting to be held in
USA 1990-02-01/02.
2 - Long term standard
Each member body is requested to identify their long term
goals and starting preferances and to communicate them to WG16
Secretariat.
*******************************************************************
The following is the progress report on WG16 delivered to the
SC22 Plenary Meeting in Berlin. I quote:
Report from ISO/IEC JTC1/SC22/WG16 Lisp
Convenor to SC22 Plenary Meeting
Berlin 1989-09-25/29
I ) Past and Next Meetings
<elided>
II) Progression of Work
The situation is somewhat complex. Two major dialects fulfill
the needs of the US Common Lisp and Scheme.
While the first one is a large industrial product, the second one
serves academic world. Common Lisp and Scheme are simultaneously
being standardized within ANSI and IEEE respectively. Three others
major efforts exist in the world. Le-Lisp is a full-strength industrial
product mainly sold in Western Europe.
Eulisp is a new dialect designed to serve the future European industrial
and academics needs. Roughly EuLisp extends Scheme.
The final and most recently developed by Japan is named Kernel Lisp
and tends to be a subset of Common Lisp designed for high portability
and efficiency together with clear semantics. All the drafts describing
rgese dialects are currently under review within the WG.
It seems that the WG has three options (not including variants):
- Define a long term standard taking into account the problems
already addressed and some more now considered important.
- Adopt an existing dialect. None covers all current practice and some
refusal is shown to adopt any of them.
- Recognize that there exists a small kernel unifying the more fundamental
features of the two major industrial Lisps. This kernel could be extended in
later steps.
The US says it does not care which of the approaches is taken provided it does
not conflict with their Common Lisp standardization.
The WG decides to define the skeleton of a Common Lisp subset as well
as retaining the vague options of a long term standard.
***********************************************************************
Note: I believe the WG decided to ``define the skeleton of a Common Lisp
subset'' only in the sense of asking the delegations what their definition
of ``the skeleton'' would be.
-rpg-
∂26-Oct-89 1241 X3J13-mailer Re: issue DEFMACRO-BLOCK-SCOPE
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 89 12:41:34 PDT
Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa01751;
26 Oct 89 15:40:15 EDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@SAIL.Stanford.EDU
Subject: Re: issue DEFMACRO-BLOCK-SCOPE
In-reply-to: Your message of Tue, 24 Oct 89 10:24:39 -0600.
<8910241624.AA08645@defun.utah.edu>
Date: Thu, 26 Oct 89 15:39:54 EDT
From: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU
I strongly oppose INCLUDES-BINDINGS since it prevents DEFUN from having any
reasonable Common Lisp expansion. In addition to being contrary to the
goal (now required?) that standard macros not expand into
implementation-dependent special forms, this also prevents users from
defining new macros "just like DEFUN".
The only expansion I can think of that would include the binding forms is
the following:
(defun foo <args> <body>) ==>
#'(lambda (&rest args)
(block foo
(apply #'(lambda <args>
<body>)
args)))
This is pretty inefficient. I am not saying that INCLUDES-BINDINGS cannot
be implemented efficiently, only that there is no way *in Common Lisp* to
do so. If there is overwhelming sentiment that INCLUDES-BINDINGS is
better, then we should make NAMED-LAMBDA a Common Lisp feature. I
personally think that this is a wart we can do without.
By the way, CMU CL does not implement INCLUDES-BINDINGS.
Rob
∂26-Oct-89 1257 X3J13-mailer Re: issue DEFMACRO-BLOCK-SCOPE
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 89 12:57:28 PDT
Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa01772;
26 Oct 89 15:56:36 EDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@SAIL.Stanford.EDU
Subject: Re: issue DEFMACRO-BLOCK-SCOPE
In-reply-to: Your message of Thu, 26 Oct 89 15:39:54 -0400.
Date: Thu, 26 Oct 89 15:56:26 EDT
From: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU
Oops... I seem to have misread DEFUN for DEFMACRO. Perhaps I was making
the assumption that the scope of the BLOCK in DEFUN would be the same as in
DEFMACRO. You may replace my flamage with much milder opposition based on
the undesirability of this inconsistency.
Rob
∂26-Oct-89 1443 X3J13-mailer Re: issue DEFMACRO-BLOCK-SCOPE
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 26 Oct 89 14:37:20 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Thu, 26 Oct 89 17:37:30 -0400
Date: Thu, 26 Oct 89 17:32 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: issue DEFMACRO-BLOCK-SCOPE
To: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, x3j13@SAIL.Stanford.EDU
In-Reply-To: <8910261947.AA09654@Think.COM>
Message-Id: <19891026213237.3.BARMAR@OCCAM.THINK.COM>
Date: Thu, 26 Oct 89 15:39:54 EDT
From: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU
I strongly oppose INCLUDES-BINDINGS since it prevents DEFUN from having any
reasonable Common Lisp expansion.
The proposal didn't address DEFUN at all. The name of the issue is
DEF*MACRO*-BLOCK-SCOPE. The second paragraph of the issue was:
It seems clear that in forms such as DEFUN which do not support
destructuring, the BLOCK surrounds only the body and includes none of
the lambda-variable binding forms.
Defining macros that permit destructing are expected to actually define
functions where the entire list structure is passed as a single
argument, and the destructuring happens inside that function. For
example:
(defmacro foo <args> <body>) ==>
(defun <internal foo> (#:args <env-var>)
(destructuring-bind <args> #:args
<body>))
There should also be a (block foo ...) somewhere, and the issue is
whether it's inside or outside the destructuring-bind.
In addition to being contrary to the
goal (now required?) that standard macros not expand into
implementation-dependent special forms,
I know of no such requirement. If a standard macro expands into an
implementation-specific special form, that special form must also have a
macro definition so that program-manipulation functions can understand
it.
The rest of my response addresses the issues involved if someone were to
propose changing DEFUN the way you thought Sandra was.
The only expansion I can think of that would include the binding forms is
the following:
(defun foo <args> <body>) ==>
#'(lambda (&rest args)
(block foo
(apply #'(lambda <args>
<body>)
args)))
This is pretty inefficient.
It's only inefficient if the compiler doesn't do much optimization.
Well-known compiler transformations can optimize away the internal
function.
Also, the expansion could be:
(defun foo (&optional (arg1 <init1>) (arg2 <init2>) ...) <body>
#'(lambda (&optional (#:opt1 nil #:opt1-p) (#:opt2 nil #:opt2-p) ...)
(block foo
(let* ((arg1 (if #:opt1-p
#:opt1
<init1>))
(arg2 (if #:opt2-p
#:opt2
<init2>))
...)
<body>)))
This isn't as efficient as is possible without the block, but it's
pretty close.
barmar
∂27-Oct-89 0846 X3J13-mailer Re: define-method-combination
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 27 Oct 89 08:45:58 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa07087; 27 Oct 89 16:22 BST
Date: Fri, 27 Oct 89 16:27:32 BST
Message-Id: <22207.8910271527@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: define-method-combination
To: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>,
Barry Margolin <barmar@think.com>,
"Bill St. Clair" <bill%cambridge.apple.com@NSFnet-Relay.AC.UK>
In-Reply-To: David A. Moon's message of Wed, 25 Oct 89 15:23 EDT
Cc: x3j13@sail.stanford.edu, sandra@cs.utah.edu, RPG@sail.stanford.edu
> Date: Wed, 25 Oct 89 14:41 EDT
> From: Barry Margolin <barmar@Think.COM>
>
> It only needs this at runtime if the application actually uses the long
> form of DEFINE-METHOD-COMBINATION. [...]
>
> I've been too busy to write my intended long answer to this canard, so
> I'll just send the short answer, and for now you'll have to trust me
> that it's true.
>
> Method combination does not require EVAL or COMPILE at run time. Yes,
> it is possible to implement it in such a way that these are required.
> That would be a poor implementation. It is also possible to implement
> it in such a way that EVAL and COMPILE at run time are not required.
> Depending on how your compiler works, the good implementation might
> require COMPILE at load time, but not at run time. It doesn't require
> EVAL at all.
I can imagine all this working _if_ the user is not allowed to define
new methods at run time. Since we're talking about delivery, that may
be a reasonable assumption to make, in many cases at least.
However, it is difficult for me, and presumably for a number of other
people, to speak with much confidence about the much-discussed "good
implementation" of CLOS. What we have to go on is PCL, which we're
told is not a particularly efficient implementation, and our experience
with Lisp and with other Lisp object systems, which appears to be
insufficient to let us reach, with confidence, the same conclusions
as the CLOS experts.
The recent discussion follows a pattern I have seen several times
in meetings of the ISO Working Group WG-16 and other places.
Random Lisp Person:
CLOS has feature F, and F must be implemented using techniques T;
those techniques are going to be inefficient, or lead to giant
systems, or (some other bad thing). So F should be modified or
removed.
CLOS Expert:
That's not right. You don't have to use those losing techniques
at all.
Random Lisp Person:
But PCL uses those techniques.
CLOS Expert:
CLOS is designed for portability, not efficiency. You can't judge
CLOS by PCL.
Now, at this point, it would be nice if the CLOS Expert would explain
the winning techniques, or point to other, accessible implementations,
but in many cases that doesn't happen. This leaves the Random Lisp
People in a difficult position, wanting to believe the CLOS Expert but
worried nonetheless. Maybe the CLOS Expert is wrong. After all,
there doesn't seem to be an implementation the RLPs can turn to in
order to check. Maybe the CLOS Expert is right but the techniques are
so difficult to discover that only those who employ the CLOS Experts
will ever have a "good implementation". Since the winning techniques
have not yet been explained, the RLPs may find it hard to see how to
become CLOS Experts themselves.
I am not trying to imply that there is a conspiracy to hide the true
inefficiencies of CLOS or to keep the secret knowledge in the hands of
the select few. I am happy to accept David Moon's short answer for
now and can well understand how he might not have time to write a
longer one. Moreover, I suspect this sort of problem may be
inevitable where new and complex designs are concerned.
However, it seems likely that such problems will occur again, and
we already have people saying that they will raise issues during
public review. It would be better if everyone in x3j13 (at least)
could be confident that the draft we are producing will define a
language that can be implemented efficiently by a fairly wide range
of implementors.
-- Jeff
∂28-Oct-89 0331 X3J13-mailer November DRAFT Agenda
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Oct 89 03:30:32 PDT
Received: from rose ([192.9.200.83]) by heavens-gate id AA05764g; Sat, 28 Oct 89 03:27:42 PDT
Received: by rose id AA05592g; Sat, 28 Oct 89 03:30:03 PDT
Date: Sat, 28 Oct 89 03:30:03 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8910281030.AA05592@rose>
To: x3j13@sail.stanford.edu
Subject: November DRAFT Agenda
Please let me know if you have anything to add.
---jan---
X3J13 Committee Meeting Agenda DRAFT
November 6 - 8, 1989
1 Call to Order, Monday, November 6, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Guy Steele (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 ISO Report, Dick Gabriel (2 hours)
7 Coffee Break 10:30
8 ISO Report continuation
9 LUNCH 12:00
10 Drafting Committee Report
11 Break 3:15
12 Drafting Committee Report Continuation
13 Recess, 5:00pm
14 Call to Order, Tuesday, November 7, 9:00am
15 Drafting Committee Report Continuation
16 Breaks, Lunch
17 Recess, 5:00pm
18 Call to Order, Tuesday, November 7, 9:00am
19 Drafting Committee Report Continuation
20 Breaks, Lunch
21 Adjournment, 5:00pm
∂29-Oct-89 1230 X3J13-mailer issue MACROEXPAND-RETURN-VALUE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Oct 89 12:30:07 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA12899; Sun, 29 Oct 89 13:29:58 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA13445; Sun, 29 Oct 89 13:29:55 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910292029.AA13445@defun.utah.edu>
Date: Sun, 29 Oct 89 13:29:54 MST
Subject: issue MACROEXPAND-RETURN-VALUE
To: x3j13@sail.stanford.edu
This is issue #26 from my list.
Forum: Cleanup
Issue: MACROEXPAND-RETURN-VALUE
References: MACROEXPAND, MACROEXPAND-1
(CLtL p151)
COMPILER-MACROEXPAND, COMPILER-MACROEXPAND-1
(issue DEFINE-COMPILER-MACRO)
Category: CHANGE
Edit History: V1, 29 Oct 1989, Sandra Loosemore
Problem Description:
CLtL says that the second value returned by MACROEXPAND and
MACROEXPAND-1 is T if the argument form is a macro call. Presumably
this is also the case for COMPILER-MACROEXPAND and
COMPILER-MACROEXPAND-1, since these functions are intended to be "just
like" their counterparts. Specifying a return value of T is
inconsistent with other predicates in the language, where a return
value of "true" is normally specified instead.
Proposal (MACROEXPAND-RETURN-VALUE:TRUE):
Change the specification so that the second return value from
MACROEXPAND, MACROEXPAND-1, COMPILER-MACROEXPAND, and
COMPILER-MACROEXPAND-1 is a boolean instead of one of the symbols T or
NIL. In other words, if the form represents a macro call (or a
compiler macro call, as appropriate), the second return value is true.
Rationale:
This is more consistent with other predicates in the language.
Current Practice:
Presumably all conforming implementations now return T.
Cost to implementors:
None, except possibly for the cost of changing documentation.
Cost to users:
It seems unlikely that user programs would explicitly test for the
return value being T, or otherwise depend on this.
Benefits:
Increased consistency in the language design.
Discussion:
Loosemore notes:
In some implementations, there is a slight performance advantage in
allowing the return values from predicates to be any non-NIL value
instead of the symbol T. Some functions such as MEMBER are required
to return a particular truth value that conveys extra information back
to the caller, but there doesn't appear to be similar motivation for
making an exception to the general rule in this situation.
-------
∂29-Oct-89 1308 X3J13-mailer issue DEFINE-DECLARATION-RETURN-VALUE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Oct 89 13:08:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA13638; Sun, 29 Oct 89 14:08:36 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA13479; Sun, 29 Oct 89 14:08:32 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910292108.AA13479@defun.utah.edu>
Date: Sun, 29 Oct 89 14:08:30 MST
Subject: issue DEFINE-DECLARATION-RETURN-VALUE
To: x3j13@sail.stanford.edu
This is issue #4 from my list.
Forum: Cleanup
Issue: DEFINE-DECLARATION-RETURN-VALUE
References: DEFINE-DECLARATION (issue SYNTACTIC-ENVIRONMENT-ACCESS)
Category: CHANGE
Edit History: V1, 29 Oct 1989, Sandra Loosemore
Problem Description:
The specification of the return values from handlers defined with
DEFINE-DECLARATION (added to the language at the June 89 meeting) only
permits a declaration to apply either to variable bindings, to
function bindings, or to neither. The first return value from the
handler function indicates which of these cases it is, and the second
return value is a list containing information about the declaration.
The DYNAMIC-EXTENT declaration cannot be handled with this mechanism
since it can apply to both variable and function bindings. It seems
reasonable for both users and implementations to define other kinds of
declarations that use a similar syntax, and DEFINE-DECLARATION ought
to be able to handle these cases.
Proposal (DEFINE-DECLARATION-RETURN-VALUE:THREE-VALUES):
Change the specification of DEFINE-DECLARATION to require handler
functions to return three values.
The first value is a list which corresponds to information about
variable bindings specified by the declaration. The format of this
list is the same as is now required to be returned as the second value
of DEFINE-DECLARATION when the first value is :VARIABLE; that is, a
list of (binding-name key value) lists.
The second value is a list which corresponds to information about
function bindings specified by the declaration. The format of this
list is the same as is now required to be returned as the second value
of DEFINE-DECLARATION when the first value is :FUNCTION; that is, a
list of (binding-name key value) lists.
The third value is a list which corresponds to information about
declarations that do not apply to either variable or function
bindings. The format of this list is the same as is now required to
be returned as the second value of DEFINE-DECLARATION when the first
value is :DECLARE; that is, a list whose CAR is a key (used by the
function DECLARATION-INFORMATION) and whose CDR is the associated
return value.
Rationale:
This proposal fixes a deficiency in the original specification of
DEFINE-DECLARATION, while minimizing the change to the format of the
information that is returned.
Current Practice:
Has anybody even implemented DEFINE-DECLARATION (as originally
specified in issue SYNTACTIC-ENVIRONMENT-ACCESS) yet?
Cost to implementors:
Probably minor.
Cost to users:
Probably minor.
Benefits:
DEFINE-DECLARATION is made more powerful.
Discussion:
-------
∂29-Oct-89 2301 X3J13-mailer my list of cleanup issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Oct 89 23:01:46 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA14962; Sun, 29 Oct 89 15:38:18 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA13520; Sun, 29 Oct 89 15:38:16 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910292238.AA13520@defun.utah.edu>
Date: Sun, 29 Oct 89 15:38:14 MST
Subject: my list of cleanup issues
To: x3j13@sail.stanford.edu
Here's a quick summary of what's happened to the issues on my original
list:
(1) new issue, EVALHOOK-STEP-CONFUSION
(2) new issue, INSPECT-RETURN-VALUE
(3) new issue, MACRO-DECLARATIONS
(4) new issue, DEFINE-DECLARATION-RETURN-VALUE
(5) (about DEFGENERIC redefinition) editorial, maybe raise again later
(6) (about binding of lambda variables in generic function) editorial
(7) (ENSURE-GENERIC-FUNCTION usage) editorial
(8) (method combinations) nothing ready yet, will raise again later
(9) new issue, DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
(10) new issue, DEFSTRUCT-CONSTRUCTOR-OPTIONS
(11) new issue, DEFSTRUCT-SYNTAX-ERRORS
(12) new issue, DEFSTRUCT-CONSTRUCTOR-OPTIONS
(13) (circular code not valid) editorial?
(14) (nonstandard syntax) editorial?
(15) new proposal for issue DEFINE-COMPILER-MACRO
(16) (&optional default to * in DEFTYPE) editorial
(17) (supplied-p parameters bound left-to-right) editorial
(18) new issue, READER-ERROR
(19) (hash table key modification) editorial
(20) (LISP-SYMBOL-REDEFINITION) ??
(21) (pathname mess) needs more thought, nothing ready yet
(22) (declaration syntax -> PROGRAM-ERROR) ??
(23) new issue, DEFMACRO-BLOCK-SCOPE
(24) new issue, &ENVIRONMENT-BINDING-ORDER
(25) (GO/RETURN-FROM syntax -> PROGRAM-ERROR) ??
(26) new issue, MACROEXPAND-RETURN-VALUE
If anybody wants to see a cleanup-style writeup on any of the issues
that I haven't gotten to yet, let me know ASAP.
Issue 20 can probably be resolved as an editorial issue. Basically,
the question is whether the phrase "symbols in the COMMON-LISP
package" used in the writeup of issue LISP-SYMBOL-REDEFINITION refers
only to *external* symbols. I think the consensus is that that was
the intent.
Issues 22 and 25 (dealing with signalling of PROGRAM-ERRORs) probably
ought to be lumped together and treated as part of a broader issue of
whether we want to require signalling of more program syntax errors.
So far I haven't detected much enthusiasm for doing this.
-Sandra
-------
∂30-Oct-89 0740 X3J13-mailer November DRAFT Agenda
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 30 Oct 89 07:40:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 683809; 30 Oct 89 10:38:20 EST
Date: Mon, 30 Oct 89 10:38 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: November DRAFT Agenda
To: Jan Zubkoff <jlz@lucid.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8910281030.AA05592@rose>
Message-ID: <19891030153831.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
After the first two hours of Drafting Committee Report, I think the
discussion should turn to "Whither?". That is, what is X3J13 going to
do next, when are we going to do it, how are we going to do it, and
who's going to be responsible for seeing that it gets done. This
definitely should come after the ISO and Drafting reports, as it will be
affected by their content.
After that's complete, we might want to talk about whatever specific
issues with the draft have come up. Sandra Loosemore has done a
good job of writing up some of them. Other people may also have their
issues and concerns in shape for discussion by the time of the meeting.
(Symbolics will not have the bulk of our comments on the draft ready
for this meeting, but we may have a few things to talk about.) I
think the discussion on specific issues should take a back seat to the
general discussion of where we are going and how we are going to get
there, but assuming that time is available, it wouldn't hurt to talk
over specific issues too.
Is the Wednesday portion of the meeting cancelled?
∂30-Oct-89 0942 X3J13-mailer November DRAFT Agenda
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Oct 89 09:42:46 PST
Received: from rose ([192.9.200.83]) by heavens-gate id AA16194g; Mon, 30 Oct 89 09:39:48 PST
Received: by rose id AA00687g; Mon, 30 Oct 89 09:42:15 PST
Date: Mon, 30 Oct 89 09:42:15 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8910301742.AA00687@rose>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 30 Oct 89 10:38 EST <19891030153831.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: November DRAFT Agenda
Great, I'll add that to the agenda. No, Wednesday hasn't been cancelled.
I have now received several things to add to the agenda and am confident we
will have enough to fill up all three days.
Thanks,
---jan---
∂30-Oct-89 1133 X3J13-mailer Re: define-method-combination
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 30 Oct 89 11:30:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 684032; 30 Oct 89 14:26:39 EST
Date: Mon, 30 Oct 89 14:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: define-method-combination
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>, phil@goldhill.com,
Sandra J Loosemore <sandra%defun@cs.utah.edu>, Bill St. Clair <bill@cambridge.apple.com>,
Dick Gabriel <RPG@SAIL.Stanford.EDU>, Barry Margolin <barmar@Think.COM>
cc: x3j13@sail.stanford.edu
In-Reply-To: <22207.8910271527@aiai.ed.ac.uk>,
<8910261348.AA02022@god.goldhill.com>,
<19891026003149.6.ALAN@MR-BUN.parc.xerox.com>,
<19891025230310.5.ALAN@MR-BUN.parc.xerox.com>,
<8910252236.AA10155@defun.utah.edu>,
<8910252220.AA01302.bill@cambridge.apple.com>,
<8910252205.AA01198.bill@cambridge.apple.com>,
<19891025192321.1.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<8910251743.AA11484.bill@cambridge.apple.com>,
<1pm8Yv@SAIL.Stanford.EDU>,
<19891016164807.5.BARMAR@OCCAM.THINK.COM>,
<19891011233005.3.ALAN@MR-BUN.parc.xerox.com>,
<8910101527.AA20624@defun.utah.edu>,
<8910092328.AA20071@defun.utah.edu>,
<1NiyfW@SAIL.Stanford.EDU>,
<8910082108.AA18897@defun.utah.edu>
Message-ID: <19891030192641.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here is the long essay about method combination that I should have sent
sooner, but didn't have time to write until now.
I apologize to those of you on X3J13 who aren't interested in this issue,
but in this case wide distribution seems appropriate in spite of the length.
Concerns about Method Combination in CLOS
There seem to be three issues that have been raised. One is whether the
value returned by the body of DEFINE-METHOD-COMBINATION should be a form or
a function. The second is whether method-combination requires calling EVAL
at run-time. The third is whether a delivered application that uses
method-combination requires a larger Lisp than it would otherwise require,
because COMPILE or EVAL will be implicitly called by CLOS and thus cannot be
removed from the delivery Lisp.
Briefly, the answers are that using a form turns out to allow for more
optimization than using a function, that EVAL is not called at run time in
most (all?) implementations, and that neither COMPILE nor EVAL needs to be
called at run time in delivery situations, only in development situations.
Now for the details that support those brief answers:
Why did we define the body of DEFINE-METHOD-COMBINATION to return a form
rather than a function? There are several problems with using a function.
A function would basically amount to a special-purpose interpreter,
traversing lists of method metaobjects and calling their method-functions.
The function would be executing the "effective method form" interpretively,
faster than EVAL to be sure, but nonetheless not as fast as a fully compiled
execution. This is one legitimate implementation technique, but we would
like implementations to be able to choose other techniques, such as
compiling the effective method form, or using a special-purpose interpreter
written in an implementation-dependent way (perhaps in assembly language).
The problem with using a function as an interface is that the abstractness
of a function makes it difficult for an implementation to infer what the
function is actually doing and implement it a different way. Using a form
as the interface avoids imposing any particular implementation technique. I
suppose that the research issue that Gabriel referred to was the issue of
taking an interpreter as a semantic specification and producing a program
that has the same semantics but uses a more efficient implementation. This
is similar to what is sometimes called "supercompilers". We don't want to
require an efficient implementation of CLOS to depend on a solution to this
research issue, hence we use a form, rather than an interpreter, as the
semantic specification.
That's not the only problem. It's difficult to see how a method-combination
function could avoid accessing the method metaobjects at run time. In the
interest of efficiency, we would like these metaobjects to be out of the
run-time virtual memory working set. Indeed, in delivery situations we
would like to be able to discard the metaobjects entirely if the application
doesn't use them explicitly. Using a form instead of a function allows us
to have method metaobjects in the form, but compile them out in the process
of compiling the form, and call the method-functions directly.
There are also questions about what would be the lambda-list of this
method-combination function. It would probably have to receive the generic
function's arguments with an &REST parameter and APPLY the method-functions,
which is likely to be less efficient than some implementation-dependent
technique for passing the arguments to the methods. Also, many
implementations pass additional information to methods (used by
optimizations of SLOT-VALUE and CALL-NEXT-METHOD) through some kind of sneak
path, sometimes one or more extra arguments, sometimes a special register.
This additional information can be different for each applicable method.
The method-combination function would have to receive this information and
pass it along to the methods somehow, and it's difficult to see how to do
that without imposing some particular implementation technique. Using a
form instead of a function avoids any question of what the lambda-list is.
Of course, the issue resulting from using a form instead of a function is:
When is this form processed into executable code and how is the code
executed? The CLOS specification (88-002R p.1-27) is written as if the
effective method form is processed every time the generic function is
called, and is executed with EVAL. That's the conceptually simplest way to
explain the semantics, but of course no implementation really works that
way. Compare the explanation of macros (CLtL p.58), which are also
described as if the macro invocation was expanded every time it is executed.
That was even a valid implementation technique until
COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN passed in June, however no
implementation really worked that way. In both cases, an implementation
that is trying to be efficient will compute the expanded macro form or
effective method form once, compile it, and save the compiled result to use
each time it is needed. This explains why EVAL is not called at run time
when a generic function is called.
That leaves the question: When does this once-only compilation happen? The
answer is easy for macros, it's when the function containing the macro
invocation is compiled. For effective method forms, there isn't one place
that defines an effective method (to my mind, that's the whole reason for
having methods and generic functions, so that the definition of the generic
function can be distributed all over the program). The answer is that the
compilation can happen as early as when we know what all the methods are,
and as late as when a particular effective method is actually called.
Implementations are given the freedom to choose a point within that range
based on their local tradeoffs. A development implementation may want to
delay the compilation as long as possible, to minimize the amount of
compilation required to make a change to the program and hence improve
response time. A delivery implementation would like to do the compilation
as soon as possible, so that compilation does not occur at run time. When
do we know what all the methods for a generic function are? My definition
of a delivery situation is that the program does not change. Therefore, we
certainly know what all the methods are as soon as we have finished loading
the program. The effective methods can be computed and compiled at that
time, and then the compiler can be discarded. Alternatively, if the
delivery system allows the compiler to know about the entire program at
COMPILE-FILE time, then the effective methods can be compiled during
COMPILE-FILE and no load-time compilation is required. Common Lisp does not
provide any way for an application to say that it has been completely
loaded, nor any way to tell the compiler the names of all the files in a
program, but surely any delivery system must make such extensions, not only
for CLOS.
Thus the macro-expansion-like behavior of method-combination is not a
run-time behavior, it's a compile-time behavior. An implementation can
choose to perform this operation as soon as it knows what all the methods
for a generic function are, and no compilation will occur thereafter.
In case it is not completely clear how, given knowledge that the entire
program is present and will not change, one finds all the effective methods,
the following simple function shows how to do it. This has been tested and
shown to work. Of course it calls functions from the metaobject protocol,
so it may not run in all ANSI Common Lisp implementations. That doesn't
matter, since this function is part of the Lisp, not part of an application.
;;; Generate a list of all of the effective method forms for a generic function
;;; Each form is paired with a list of the parameter specializers that select it
;;; This uses some functions from the metaobject protocol
(defun all-effective-methods (generic-function)
(let* ((number-of-required-arguments
(loop for param in (generic-function-lambda-list generic-function)
until (member param lambda-list-keywords)
count t))
(specializer-lists (make-list number-of-required-arguments)))
(labels ((process-method (method)
(loop for spec in (method-specializers method)
for list on specializer-lists do
(pushnew spec (car list) :test #'equal-specializers)))
(enumerate-specializers (lists)
(if (null lists)
(list (list))
(let ((rest (enumerate-specializers (rest lists))))
(loop for spec in (car lists)
nconc (loop for r in rest
collect (cons spec r))))))
(equal-specializers (spec1 spec2)
(if (or (atom spec1) (atom spec2))
(eq spec1 spec2)
(and (eq (first spec1) (first spec2))
(eq (second spec1) (second spec2))))))
;; Find all of the parameter specializers that are used
(mapc #'process-method (generic-function-methods generic-function))
;; Enumerate the cartesian product of those parameter specializers
;; and collect the effective method for each combination
(loop for specs in (enumerate-specializers specializer-lists)
collect (list specs
(compute-effective-method
generic-function
(generic-function-method-combination generic-function)
(compute-applicable-methods
generic-function
(loop for spec in specs
collect (if (atom spec)
(class-prototype spec)
(second spec))))))))))
To make more specific what I mean by the "definition of a delivery situation
is that the program does not change", I mean that none of the following CLOS
operators is called after the program has been loaded. (There are also some
straight Common Lisp operators and some chapter-3 metaobject operators that
must not be called, which I will not list here.)
add-method
defclass
defgeneric
define-method-combination
defmethod
ensure-generic-function
remove-method
update-instance-for-redefined-class
Of course, some application programs do change themselves at run-time. This
is particularly common in CAD programs. It shouldn't surprise anyone that
such programs require a compiler at run-time so that they can compile their
changes.
There is some question about whether using GENERIC-FLET, GENERIC-FUNCTION,
GENERIC-LABELS, or WITH-ADDED-METHODS to create new generic functions at run
time constitutes changing the program. For the first three of these, all of
the methods for the generic function are lexically apparent, so these do not
change the program in any deep way, and all of the method combination
calculations for them can be done at compile time. WITH-ADDED-METHODS
inherits methods from an existing generic function, so until those methods
are known, it doesn't know what are all the methods for the new generic
function it creates. However, if the program is not otherwise changed, a
given WITH-ADDED-METHODS form will produce a generic function with an
equivalent set of methods each time it is called. Therefore it should be
possible to do the method combination calculations just once, as for an
ordinary generic function. However, I do not claim to have thought about
these four operators in detail, since they do not reflect any current
practice.
An open question is whether the ANSI Common Lisp specification should
include a set of language restrictions and extensions appropriate for
delivery. For example, should it include a way to specify that the
program has been completely loaded? Should it include a way to specify
that all of the methods for a generic function, and all of the class
definitions needed to compute the class precedence list of each class
used as a parameter specializer in those methods, have been defined at
this point in a COMPILE-FILE and will not change later? Should it
include a way to say "compile this list of files together as a complete
application program"? So far, we have avoided getting into this area
because there are too many implementation-dependent tradeoffs and there
is not enough current practice to go by. I think it would help Lisp
a lot if there was a good standard in this area, but also think X3J13
has more than enough to do just getting the development version of the
language standardized and should not take on any new tasks.
∂30-Oct-89 1246 X3J13-mailer re: define-method-combination
To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
jeff%aiai.edinburgh.ac.uk@NSFNET-RELAY.AC.UK,
phil@GOLDHILL.COM,
sandra%defun@CS.UTAH.EDU, bill@CAMBRIDGE.APPLE.COM,
RPG@SAIL.Stanford.EDU, barmar@THINK.COM
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Mon, 30 Oct 89 14:26 EST.]
Moon writes:
``I suppose that the research issue that Gabriel referred to was the issue
of taking an interpreter as a semantic specification and producing a
program that has the same semantics but uses a more efficient
implementation. This is similar to what is sometimes called
"supercompilers".''
I meant that or something like that: How do you specify the behavior of an
effective method in such a way to gain maximum speed with flexibility. The
approach I would take would be to look at other linguistic means for
specifying behavior. This seems more approachable to me because the issue
is to specify the behavior of a program as a function of other existing
program fragments. One way to specify that behavior is through an
interpreter at a higher level, but that is the boring way to approach it.
Moon remarked on the analogy of defining method combinations to defining
macros. The ``old'' specification of macros left folks in a tizzy because
the form produced by a macro could be apparently specified to depend on
such run-time-only phenomena as the phase of the moon. We tightened that
up a little in the compiler committee (thanks Sandra), but we've left it a
open a bit here for defining method combinations. Moon proposes evaluating
the effective-method-producing code as soon as possible, which is
analogous to what implementational practice for macros has been for decades.
Maybe people don't see this analogy easily enough and that is the problem.
Moon continues:
``There is some question about whether using GENERIC-FLET, GENERIC-FUNCTION,
GENERIC-LABELS, or WITH-ADDED-METHODS to create new generic functions at
run time constitutes changing the program. ...However, I do not claim
to have thought about these four operators in detail, since they do not
reflect any current practice.''
He also says:
``...(to my mind, that's the whole reason for having methods and generic
functions, so that the definition of the generic function can be
distributed all over the program).''
I think only WITH-ADDED-METHOD corresponds to no existing practice in the
following sense. We have always discussed the issue of linguistic versus
environmental features. Incrementality is, I believe, purely environmental -
as long as it is well-specified what a modification means, the environment
can take care of altering an existing program written in an arbitrarily static
programming language. Of course, this requires an implementation that supports
such activities, but isn't the implementation part of the environment because
the language is just symbols on paper?
Having the ability to show method definitions in different contexts is
something that an environment does. As a programmer, I wish to look at
methods near the classes they refer to (all of those classes, at one time
or another), and I also wish to see all the methods at the same time. The
current scheme is to build one of these environmental options into the
language by means of DEFMETHOD. This choice is arbitrary, leaving out
others. Current practice happens to favor this choice because programming
environments are weak.
What is central to the language is to be able to define classes and generic
functions. Having a minimum number of such definitional forms is preferrable
to having many, and the one that defines the entire generic function is
conceptually simplest. With this choice I insist on an environment that
shows me methods (using defmethod syntax, even) in every context where it
is meaningful (and maybe others too) as long as changes are pervasive over
all instances.
Thus, the all-in-one-place forms reflect the deep truth of current practice,
and we have chosen the heathen DEFMETHOD embedding of environment into language
to accomodate those with weak programming environments - oops, which happens to
be all of us!
-rpg-
∂30-Oct-89 1252 X3J13-mailer Re: define-method-combination
Received: from encore.encore.com (multimax.encore.COM) by SAIL.Stanford.EDU with TCP; 30 Oct 89 12:52:19 PST
Received: from xenna.encore.COM by encore.encore.com with SMTP (5.61/25-eef)
id AA01271; Mon, 30 Oct 89 15:53:27 -0500
Received: by xenna. (4.0/SMI-4.0)
id AA11310; Mon, 30 Oct 89 15:53:07 EST
Date: Mon, 30 Oct 89 15:53:07 EST
From: Dan Pierson <pierson@xenna.encore.com>
Message-Id: <8910302053.AA11310@xenna.>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: x3j13@sail.stanford.edu
In-Reply-To: <19891030192641.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Re: define-method-combination
David A. Moon writes:
> Here is the long essay about method combination that I should have sent
> sooner, but didn't have time to write until now.
Thank you.
> An open question is whether the ANSI Common Lisp specification should
> include a set of language restrictions and extensions appropriate for
> delivery. For example, should it include a way to specify that the
> program has been completely loaded? Should it include a way to specify
> that all of the methods for a generic function, and all of the class
> definitions needed to compute the class precedence list of each class
> used as a parameter specializer in those methods, have been defined at
> this point in a COMPILE-FILE and will not change later? Should it
> include a way to say "compile this list of files together as a complete
> application program"? So far, we have avoided getting into this area
> because there are too many implementation-dependent tradeoffs and there
> is not enough current practice to go by. I think it would help Lisp
> a lot if there was a good standard in this area, but also think X3J13
> has more than enough to do just getting the development version of the
> language standardized and should not take on any new tasks.
I agree that it's too late for this. For one thing, this should be
addressed as part of the DEFSYSTEM problem. It's a very great pity
that we didn't solve that one in this standard (if you're familiar
with Unix, think about what MAKE, with all of its faults, has done for
the Unix world), but, since we didn't get to DEFSYSTEM this time,
trying to hack on a piece of it without considering the rest is just
asking for trouble.
∂30-Oct-89 1442 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Oct 89 14:41:58 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA26494; Mon, 30 Oct 89 15:41:43 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA14535; Mon, 30 Oct 89 15:41:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910302241.AA14535@defun.utah.edu>
Date: Mon, 30 Oct 89 15:41:34 MST
Subject: Re: issue DEFINE-COMPILER-MACRO, version 3
To: Barry Margolin <barmar@Think.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin <barmar@Think.COM>, Tue, 24 Oct 89 19:34 EDT
> Date: Tue, 24 Oct 89 19:34 EDT
> From: Barry Margolin <barmar@Think.COM>
>
> Also, it's not clear what you expect us to do with this at the next
> meeting? Technically, by combining your amendments into the original
> issue, you're requiring us to bring the issue up for reconsideration,
> which means that we go back to the state before they were approved; if
> we then get deadlocked on it, compiler macros go away (I won't cry, but
> others might not like it).
We've brought up revised versions of issues that had previously been
passed before, with the understanding that the previous version would
stand if the new one failed. That is what I expect to happen here.
Some people might also think it is appropriate to take a vote to
confirm that proposal NEW-FACILITY reflects what was actually approved
at the June meeting, since earlier some questions were raised about
whether the writeup was accurate. (We've done that before with other
issues too.)
> Some people suggested that compiler macros might
> try to communicate with each other, and licensing the implementation to
> arbitrarily decide not to invoke one of the compiler macros would screw
> up such code.
I can't take this argument seriously. For one thing, various people
have indicated that it was agreed at the last meeting that, although
the compiler must call the compiler macro function, it need not
actually use the result. So that would already break any user program
that depends on compiler macros that communicate with each other
through their expansions. The other possibility is that they try to
communicate with each other by side-effects in the expander function
itself. CLtL is already quite clear (see pages 143-144) that this
won't work for ordinary macros, since there are no guarantees about
the expander functions being called at any particular time, in any
particular order, or in any particular execution environment. Why
should compiler-macros be any different (especially since the original
proposal says they're "just like" ordinary macros)?
-Sandra
-------
∂30-Oct-89 1905 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Oct 89 19:05:00 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA00451g; Mon, 30 Oct 89 19:01:59 PST
Received: by bhopal id AA06510g; Mon, 30 Oct 89 19:03:55 PST
Date: Mon, 30 Oct 89 19:03:55 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8910310303.AA06510@bhopal>
To: x3j13@sail.stanford.edu
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
Looking over past "cleanup" discussions, I see that we never got around
to finishing the work on floating-point traps. I realize this is a bit
late, but the addition suggested below seems so short to describe, so non-
controversial (I hope!), and turns out to be so important to portability,
that it would be a shame if we couldn't agree on it next week.
Forum: Cleanup
Issue: FLOATING-POINT-CONDITION-NAMES
References: CLtL, Section 12.10 "Implementation Parameters" (for floats)
CLtL, P.448 "*features*"
IEEE Standard for Binary Floating-Point Arithmetic
Related Issues: FLOAT-UNDERFLOW
ERROR-CHECKING-IN-NUMBERS-CHAPTER
Category: ADDITION
Edit History: V1, 30 Oct 1989, JonL White
Problem Description:
The currently proposed error system contains names for three conditions
related to floating-point operations: floating-point-underflow,
floating-point-overflow, and division-by-zero. Probably a majority
of implementation will be running on machines that support the IEEE
floating point standard; but there is no name for the remaining two out
of the five mandated trapping conditions, namely floating-point-inexact
and floating-point-invalid-operation.
Furthermore, even though the condition names may appear in an image,
it is not clear that such traps are enabled at every point in time.
The IEEE standard specifies that user-level programs ought to have
the capability of selectively enabling or disabling its five traps;
and other implementations may run on a variety of hardware configurations
for which the traps possible vary from host to host. However, there is
no current way for user-code to ask (1) what conditions are in fact
supporting floating-point traps, nor to ask (2) just what traps are
currently active
Note that some very simple implementations might not be able to cause
trapping even for floating-point-underflow; and in other implementations,
the relevant traps may vary on a host-to-host basic, depending on what
particular optional hardware is available on that host. For example,
Sun3 workstations come in three configurations: one with only software
floating-point support, one with a Motorola MC68881 attached co-processor,
and one with both an MC68881 and a Weitek Floating Point "Accelerator";
the increasing hardware complement gives rise to an increasing number of
implementation-specific traps. Even within the IEEE standard, it is
possible for a conforming implementation to make a refinement of the five
suggested traps [the MC68881 partitions one of the traps into three,
giving a total of eight]; so even though one knows that an implementation
is IEEE compatible, it still makes sense to ask what conditions are
supportable as floating-point traps.
Proposal (FLOATING-POINT-CONDITION-NAMES:ADD-MINIMAL-IEEE)
1. Add FLOATING-POINT-INVALID-OPERATION and FLOATING-POINT-INEXACT
as conditions which are sub-conditions of ARITHMETIC-ERROR.
2. Add a global parameter SUPPORTED-FLOATING-POINT-CONDITIONS which
is to contain a list of all the condition names that can, in that
implementation, be enabled as floating-point traps; this is to
be an "implementation revealing" parameter.
3. Add a function of no arguments ENABLED-FLOATING-POINT-TRAPS which
returns a list of condition names for all currently enabled
floating point trapping conditions.
The intent is that if condition FOO is a currently enabled floating
point trap, then whenever that particular situation arises the
system will arrange to signal the Lisp condition FOO. The means for
enabling and disabling traps is not addressed in this proposal.
Rationale:
Many Common Lisp implementations do in fact run on hardware that
supports the IEEE floating-point standard; a minimal requirement
for porting between these implementations is that they all use the
same name for the five IEEE-mandated floating-point conditions.
Since at least some implementations will provide means for selective
enabling and disabling of various floating-point traps, then the
user must be able to query the system to find out what the current
state is, and what states are supportable.
Current Practice:
Lucid Common Lisp supports this much; moreover, it uses SETF on
(ENABLED-FLOATING-POINT-TRAPS) as the primary means to alter the
currently-enabled traps.
Cost to implementors:
Trivial.
Cost to users:
None; this is an upward-compatible addition.
Benefits:
Portability of a greater amount of user code; portability of "skills",
since IEEE support is so common.
Aesthetics:
It is better for all IEEE implementations to use the same names for
these conditions, rather than have them vary from one to another.
It is also probably better for non-IEEE implementations to use the
IEEE condition names where appropriate, just to minimize the
conceptual overload.
Discussion:
If an implementation is to claim full IEEE support, then it ought to
provide some means of enabling and catching these five IEEE-mandated
traps. Then it would be appropriate to put :IEEE-FLOATING-POINT on
the list *FEATURES* (see CLtL, P.448).
Moon and JonL privately discussed some means for enabling and
disabling various floating-point traps, back in June 1989 when the
float-underflow proposal was under discussion; they came to the
conclusion that "getting the design right and efficient" was more
than a few minutes worth of work, and so postponed further work on it.
[The IEEE standard apparently goes by the name of ANSI-IEEE Std 754-1985;
my working copy is Draft 10.0 from 1982. I don't think there are great
variances between them. -- JonL --]
∂30-Oct-89 1958 X3J13-mailer define-method-combination
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 30 Oct 89 19:58:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 684398; 30 Oct 89 22:56:48 EST
Date: Mon, 30 Oct 89 22:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Barry Margolin <barmar@Think.COM>
cc: x3j13@sail.stanford.edu
In-Reply-To: <19891016164807.5.BARMAR@OCCAM.THINK.COM>
Message-ID: <19891031035701.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I wanted to comment briefly on this message, as a postscript
to the long essay I sent earlier today. Again I apologize for
the amount of traffic on the X3J13 mailing list.
Date: Mon, 16 Oct 89 12:48 EDT
From: Barry Margolin <barmar@Think.COM>
I think the issue is whether it is computed
at runtime or compile time, and I think the nature of Flavors- and
CLOS-style OOP requires them to be computed at runtime.
This is not true. It's the development-oriented nature of the
implementations of Flavors and CLOS with which you are most familiar
that requires effective methods to be computed at run time. In a
delivery-oriented implementation of the same source language, where the
program cannot be changed at run-time, the method combination would
never need to be computed at run-time.
The flexibility
of CLOS implies that the information needed to compute an effective
method may not be available at compile time.
This is true, but it's always available once the whole program has been
loaded. The flexibility of CLOS here is really the ability to compose a
program by loading the output of multiple invocations of compile-file
that don't know about each other, rather than anything more specifically
connected with the details of CLOS.
And even if it were,
computing them all would result in exponentially many effective methods
being computed and stored in object files, many of which would be for
classes that are never actually instantiated.
This is not actually true. I thought this at one time myself, but in
fact it's a false analogy from the particular method indexing technique
used in the Genera implementation of Flavors, in particular the fact
that the methods for all generic functions applicable to a given class
are indexed together in one giant per-class structure. The number of
effective methods for a generic function is only equal to the number of
different combinations of parameter specializers. Subtypes of the
parameter specializers do not create new effective methods that would
have to be compiled. It's probably rare in practice to have effective
methods that are applicable only to classes that are not intended ever
to be instantiated. It is of course quite possible to have effective
methods that are applicable only to classes that happen not to get
instantiated in any particular run of the program. My guess is that this
is not a serious space consumption problem in practice, but I don't
know how to confirm that guess in any general way.
Flavors does have a facility for building effective methods (called
"combined methods" in Flavors) at compile time -- the macro
(COMPILE-FLAVOR-METHODS <flavor-name>) may be placed at top-level in a
file being compiled. However, if the relevant portion of the flavor
hierarchy is later changed, the combined method will be recomputed at
runtime.
Right. Also the correctness of the macroexpansion of COMPILE-FLAVOR-METHODS
is confirmed at load time, and if it's wrong it's done over at load time.
Both of those are features to make development easier and wouldn't
be needed in delivery situations.
Unfortunately, I don't think this scheme is trivially adapted
to CLOS, because of multimethods.
Three obvious things to do are: (COMPILE-CLASS-METHODS class-name)
compiles all effective methods that are applicable to instances of that
class in any argument position (in Flavors COMPILE-FLAVOR-METHODS only
looks at the first argument position), or
(COMPILE-GENERIC-FUNCTION-METHODS generic-function-name) compiles all
effective methods applicable to any arguments for that particular
generic function, or (COMPILE-EFFECTIVE-METHODS) compiles effective methods
for classes and generic functions defined in the file in which it appears.
As Pierson argues, it's probably better not to try throw in delivery
half-measures at the last minute, though.
∂30-Oct-89 2042 X3J13-mailer my list of cleanup issues
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 30 Oct 89 20:42:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 684422; 30 Oct 89 23:40:46 EST
Date: Mon, 30 Oct 89 23:40 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: my list of cleanup issues
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8910292238.AA13520@defun.utah.edu>
Message-ID: <19891031044051.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 29 Oct 89 15:38:14 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Issue 20 can probably be resolved as an editorial issue. Basically,
the question is whether the phrase "symbols in the COMMON-LISP
package" used in the writeup of issue LISP-SYMBOL-REDEFINITION refers
only to *external* symbols. I think the consensus is that that was
the intent.
I agree. All these things should speak of symbols exported by COMMON-LISP,
not symbols accessible in COMMON-LISP or symbols whose home-package is
COMMON-LISP. Ditto for KEYWORD.
The phrase "symbols in package" should never be used, as it is ambiguous.
∂31-Oct-89 0729 X3J13-mailer Re: Issue: FLOATING-POINT-CONDITION-NAMES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 31 Oct 89 07:29:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA16079; Tue, 31 Oct 89 08:29:03 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA15236; Tue, 31 Oct 89 08:29:01 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8910311529.AA15236@defun.utah.edu>
Date: Tue, 31 Oct 89 08:28:59 MST
Subject: Re: Issue: FLOATING-POINT-CONDITION-NAMES
To: Jon L White <jonl@lucid.com>
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Mon, 30 Oct 89 19:03:55 PST
Two minor complaints about the proposal:
2. Add a global parameter SUPPORTED-FLOATING-POINT-CONDITIONS [...]
This should be "symbolic constant" (as in a DEFCONSTANT-style constant)
instead of "global parameter", right? I can't imagine how it would be
useful to allow users to modify its value.
3. Add a function of no arguments ENABLED-FLOATING-POINT-TRAPS [...]
I'm a bit bothered by the asymmetry of the names here. These should
either both be -TRAPS or both -CONDITIONS.
I also wonder if it might make more sense to have both
SUPPORTED-FLOATING-POINT-CONDITIONS and ENABLED-FLOATING-POINT-TRAPS
be type specifiers instead of a constant on the one hand and a
function on the other. Instead of doing a MEMBER test on the
resulting list of condition names, one would do a SUBTYPEP test to
check whether an implementation supports a particular condition.
I don't have any fundamental complaint with the intent of the proposal.
-Sandra
-------
∂31-Oct-89 1300 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 31 Oct 89 12:57:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 684951; 31 Oct 89 15:56:24 EST
Date: Tue, 31 Oct 89 15:56 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
To: Jon L White <jonl@lucid.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8910310303.AA06510@bhopal>
Message-ID: <19891031205628.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 30 Oct 89 19:03:55 PST
From: Jon L White <jonl@lucid.com>
Looking over past "cleanup" discussions, I see that we never got around
to finishing the work on floating-point traps. I realize this is a bit
late, but the addition suggested below seems so short to describe, so non-
controversial (I hope!), and turns out to be so important to portability,
that it would be a shame if we couldn't agree on it next week.
Since we canned something like this in June on the grounds that there
wasn't any time left to add new features, I don't see how we can justify
adding it now. I think we all want something like this, but there are a
number of problems with the details of your proposal and I don't think
there is any time left to work on the design of this new feature. I
hate to leave this out, I'm myself an advocate of giving good control
over floating point exceptions, but I really think we have no choice.
I suppose you might not believe there are problems with the details if
I don't list some. This may not be a complete list. I'll keep it brief.
- The names are inconsistent.
- There is no dynamic-extent form of floating-point exception enabling,
which means that programs will not work correctly in multiprocess
Lisps (such as Symbolics Genera, Explorer, and recent versions of Lucid).
- There is still no specification of what causes the conditions to
be signalled (neither the new conditions nor the existing ones).
- There is no specification of how this interacts with safe/unsafe code.
- There is no specification of what can be done to recover when a
condition is signalled.
- There is no specification of what happens when a condition is disabled.
- Division by Zero is in the IEEE spec as a disablable exception but
is missing from your proposal.
∂31-Oct-89 1325 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Oct 89 13:25:20 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA00302g; Tue, 31 Oct 89 13:22:24 PST
Received: by bhopal id AA17846g; Tue, 31 Oct 89 13:24:20 PST
Date: Tue, 31 Oct 89 13:24:20 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8910312124.AA17846@bhopal>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 31 Oct 89 08:28:59 MST <8910311529.AA15236@defun.utah.edu>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
re: 2. Add a global parameter SUPPORTED-FLOATING-POINT-CONDITIONS [...]
This should be "symbolic constant" (as in a DEFCONSTANT-style constant)
instead of "global parameter", right? I can't imagine how it would be
useful to allow users to modify its value.
It can't be a constant because there are ports for which it will vary
on a host-by-host basis (the example given was the Sun3, which may or
may not have an FPA board attached). Admittedly, only chaos can result
if the End-User starts fiddling with it's value. At worst, this too
would have to be a functional interface.
re: I'm a bit bothered by the asymmetry of the names here. These should
either both be -TRAPS or both -CONDITIONS.
Sometime I get puzzled by it too, but there is a difference between a
"trap" and a CommonLisp "condition". No item in the condition hierarchy
is disabled whenever the associated trap is disable -- it still exists
there, for whatever purposes the software can find for it. Maybe the
confusing thing was to use condition names as the output of the enabled
traps function; or maybe it is confusing to use condition names rather
than condition object on the supported-conditions list? I don't feel
very strongly about the name, except that calling the list of supported
condition names a -TRAPS list could be even more confusing.
re: ...SUPPORTED-FLOATING-POINT-CONDITIONS and ENABLED-FLOATING-POINT-TRAPS
be type specifiers instead of a constant on the one hand and . ..
We thought about having a join condition for all the floating-point
conditions simply a convenience; but the trouble is with DIVISION-BY-ZERO
-- it would need multiple parents since it includes both the floating-point
division by zero trap, and the non-floating-point one. I don't remember if
we allowed multiple-inheritance for the condition system. At least you
can do (subtypep x 'arithmetic-error) as well as:
(subtypep x '(or floating-point-<this> floating-point-<that>))
-- JonL --
∂31-Oct-89 1332 X3J13-mailer Re: Issue: FLOATING-POINT-CONDITION-NAMES
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 31 Oct 89 13:31:59 PST
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Tue, 31 Oct 89 16:33:17 -0500
Date: Tue, 31 Oct 89 16:28 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Issue: FLOATING-POINT-CONDITION-NAMES
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: Jon L White <jonl@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: <8910311529.AA15236@defun.utah.edu>
Message-Id: <19891031212830.2.BARMAR@OCCAM.THINK.COM>
Date: Tue, 31 Oct 89 08:28:59 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Two minor complaints about the proposal:
2. Add a global parameter SUPPORTED-FLOATING-POINT-CONDITIONS [...]
This should be "symbolic constant" (as in a DEFCONSTANT-style constant)
instead of "global parameter", right? I can't imagine how it would be
useful to allow users to modify its value.
Perhaps a loadable IEEE compatibility library would include support for
additional conditions.
3. Add a function of no arguments ENABLED-FLOATING-POINT-TRAPS [...]
I'm a bit bothered by the asymmetry of the names here. These should
either both be -TRAPS or both -CONDITIONS.
Good idea.
I also wonder if it might make more sense to have both
SUPPORTED-FLOATING-POINT-CONDITIONS and ENABLED-FLOATING-POINT-TRAPS
be type specifiers instead of a constant on the one hand and a
function on the other. Instead of doing a MEMBER test on the
resulting list of condition names, one would do a SUBTYPEP test to
check whether an implementation supports a particular condition.
I don't see the need for this.
barmar
∂31-Oct-89 1349 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 31 Oct 89 13:49:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 685007; 31 Oct 89 16:47:24 EST
Date: Tue, 31 Oct 89 16:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
To: Jon L White <jonl@lucid.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8910312124.AA17846@bhopal>
Message-ID: <19891031214724.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 31 Oct 89 13:24:20 PST
From: Jon L White <jonl@lucid.com>
I don't remember if
we allowed multiple-inheritance for the condition system.
We didn't used to, but we do now. See for example, simple-warning on p.2-19
of the recently distributed draft. It's defined in a way that can only be
implemented using multiple inheritance. Fortunately CLOS is available to
provide the multiple inheritance.
∂31-Oct-89 1637 X3J13-mailer Re: WG16 Action Items
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 31 Oct 89 16:37:47 PST
Received: from aiai.edinburgh.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa07490; 31 Oct 89 23:31 GMT
Date: Tue, 31 Oct 89 17:58:17 GMT
Message-Id: <24681.8910311758@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: WG16 Action Items
To: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 26 Oct 89 1216 PDT
Cc: chaynes@iuvax.cs.indiana.edu
> The following are the action items sent from WG16 to be done before
> the next WG16 meeting, which is the first week of February. I quote:
>
> 1 - Short-term standard
>
> Each member body willing to participate to the ``CL subset approach'' is
> requested to produce for the next WG16 meeting (by end of 1989):
>
> - Its definition of ``Kernel'' concept
>
> - The list of features that must be present in the Kernel.
>
> It is stressed that these informations must be electronically
> circulated with WG16 *before* the next meeting to be held in
> USA 1990-02-01/02.
Does the "CL subset approach" use the French definition of "subset"
or some other one or does it not matter?
∂31-Oct-89 1656 X3J13-mailer whitespace after macros
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 31 Oct 89 16:56:49 PST
Received: from cdr.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA21496; Tue, 31 Oct 89 17:56:43 -0700
Received: by cdr.utah.edu (5.61/utah-2.3-leaf)
id AA25566; Tue, 31 Oct 89 17:56:41 -0700
Date: Tue, 31 Oct 89 17:56:41 -0700
From: moore%cdr@cs.utah.edu (Timothy B. Moore)
Message-Id: <8911010056.AA25566@cdr.utah.edu>
To: x3j13@sail.stanford.edu
Subject: whitespace after macros
Cc:
CLtL and section 3.2 of the Working Draft are quite specific about
what happens to whitespace after a token, but neither say anything
about whitespace after macro characters. Step 4 of the state machine
on pg 335 of CLtL implies that no characters of any kind are looked
at after a character macro function returns. However 2
implementations, HPCL I and Lucid, appear to eat the whitespace
character after a terminating macro character.
Is this addressed in any other part of the Standard? Should it be specified?
Tim
∂31-Oct-89 1749 X3J13-mailer whitespace after macros
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 31 Oct 89 17:49:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 685213; 31 Oct 89 20:47:47 EST
Date: Tue, 31 Oct 89 20:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: whitespace after macros
To: Timothy B. Moore <moore%cdr@cs.utah.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8911010056.AA25566@cdr.utah.edu>
Message-ID: <19891101014747.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 31 Oct 89 17:56:41 -0700
From: moore%cdr@cs.utah.edu (Timothy B. Moore)
CLtL and section 3.2 of the Working Draft are quite specific about
what happens to whitespace after a token, but neither say anything
about whitespace after macro characters. Step 4 of the state machine
on pg 335 of CLtL implies that no characters of any kind are looked
at after a character macro function returns. However 2
implementations, HPCL I and Lucid, appear to eat the whitespace
character after a terminating macro character.
I suspect that you are being fooled by the difference between READ and
READ-PRESERVING-WHITESPACE, but that's only a guess. For this kind of
question it's good to include in your mail the simple piece of Lisp
code that you used as a test program.
∂31-Oct-89 1844 X3J13-mailer Re: define-method-combination
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 89 18:44:13 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 89 18:36:45 PST
Date: Tue, 31 Oct 89 18:36 PST
From: Gregor.pa@Xerox.COM
Subject: Re: define-method-combination
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Barry Margolin <barmar@Think.COM>, x3j13@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
In-Reply-To: <19891031035701.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19891101023633.8.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Mon, 30 Oct 89 22:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 16 Oct 89 12:48 EDT
From: Barry Margolin <barmar@Think.COM>
And even if it were,
computing them all would result in exponentially many
effective methods being computed and stored in object
files, many of which would be for classes that are never
actually instantiated.
This is not actually true.
In fact, even PCL has a mechanism for dealing with this problem which
can be easily connected to the "compile all possible effective methods"
code in Moon's earlier message.
The general idea is to recognize that many effective methods will have
the same "shape". For example, all compiled effective methods with one
before, one primary and one after method have the same "shape", even if
the specific methods involved are different. Use of this technique
makes it possible to know that it won't be necessary to call the
compiler to produce a compiled effective method without actually having
to create all possible effective methods in the development image.
I haven't done any data gathering on the savings associated with this
technique, but it has been in PCL for quite some time, and it is one
thing I haven't had too much problem with.
As Pierson argues, it's probably better not to try throw in
delivery half-measures at the last minute, though.
I agree with this whole-heartedly. As you said in your previous
message, any given delivery system must have other implementation
specific extensions, lets leave the particular user-interface to this
functionality up to the implementation as well.
-------
∂31-Oct-89 1937 X3J13-mailer evaluating CLOS performance
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 89 19:37:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 89 19:37:16 PST
Date: Tue, 31 Oct 89 19:35 PST
From: Gregor.pa@Xerox.COM
Subject: evaluating CLOS performance
To: CommonLoops.pa@Xerox.COM, X3J13@Sail.Stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
Message-ID: <19891101033501.1.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
(apologies for the duplicate messages some of you will receive)
There have been a number of messages in different forums lately about
CLOS implementation. David Moon's message to the X3J13 mailing list
addresses some issues having to do with the implementation of method
combination. This message addresses some issues having to do with
proper evaluation of the performance of CLOS in general, and PCL in
particular.
While I have a number of things to say about this, there are three major
points I want to stress:
1) Performance comparisons are difficult. It is important to
compare like functionalities, and be sure you understand the
"semantics" of the operation you are measuring.
2) PCL is not CLOS. PCL is a portable implementation with some
interesting architectural ideas, I believe it can be made to
perform relatively well, but most of the current ports do not
perform adequately.
3) Not all ports of PCL are created equal. The P in PCL means
that PCL can be ported relatively easily, not that it is written
in pure Common Lisp.
There are many things which PCL would like to do, which Common
Lisp compilers are reluctant to let me do. In any given Common
Lisp, it takes work to get the compiler "out of PCL's way".
In some Common Lisps this process is farther along that in others,
but in no Common Lisp is it far enough along.
The rest of this message discusses a number of aspects of the CLOS
language and PCL implementation, providing various insights and evidence
to support these three points.
An important point about CLOS which this message will develop is that
because CLOS is a tight integration with Common Lisp, different but
similar features work together well. defstruct and defclass define
different kinds of classes, but methods can be defined on both kinds --
this makes it possible to choose the kind of class based on one set of
requirements and use generic functions regardless of the decision.
defun and defmethod define different kinds of functions, but both are
called in the same way -- this makes it possible to choose the kind of
function based on one set of requirements but have the callers be able
to use it the same way regardless of the decision.
In short, this makes it possible for a programmer using CLOS-extended
Common Lisp to choose just exactly the functionality they want in any
given case. The language provides a range of functionalities which all
fit together.
<<An expanded version of this note would give some guidelines for making
these decisions, or at least some examples. This version doesn't do
that unfortunately.>>
So, when making performance comparisons, it is important to compare
similar functionalities -- this corresponds to the common folk wisdom
that you shouldn't compare apples and oranges. A performance comparison
should always include a functionality comparison. Two common problem
areas are field access and procedure invocation.
*** Field Access ***
Let's start with the example of field access. Many people try to make
comparisons among the performance of defstruct field access, slot access
and calling accessor generic functions. Following the principle
outlined above it is important to understand the performance and
functionality of the many different field access mechanisms provided:
Given the following definitions:
(defstruct foo (a 1))
(defclass bar () ((a :initform 1 :accessor bar-a)))
(defvar *foo* (make-foo))
(defvar *bar* (make-instance 'bar))
Let us look at the following forms:
(defun fun ()
(foo-a *foo*) ;Form 1
(slot-value *bar* 'a) ;Form 2
(bar-a *bar*)) ;Form 3
(defmethod meth ((b bar))
(slot-value *bar* 'a) ;Form 4
(bar-a *bar*)) ;Form 5
The rest of this section looks at comparisons among forms 1 - 5. Each
of these forms has different functionality AND different performance.
Form 1:
This is a defstruct field access. In many implementations, this
compiles open without any type checking, so the time required is
about one memory read.
The important points about the functionality of this operation are:
it (usually) does no error checking; it only supports single
inheritance, and because it compiles open you must recompile
all your code if you redefine it.
Form 2:
This is a call to slot-value, where the object argument is a an
instance of a standard class (a class defined by defclass without
using the :metaclass option). Moreover, this call to slot-value
appears in a context in which the compiler cannot infer anything
about the class of the object argument. In the current version of
PCL, this takes a long time, I don't know how long. In the next
version, this should take an amount of time comparable to 3 or 4
function calls, but see my comments later about porting PCL. I
haven't though very much about what the fastest one could expect
this to be is.
The important points about the functionality of this operation are:
it does complete error checking (is its argument an object, does it
have a slot by this name, is that slot bound); the class involved
supports multiple inheritance; it doesn't compile open, so you can
change the class definition later; you can define methods on
slot-value-using-class which would affect this operation -- so the
slot access is specializable.
Form 3:
This is a call to an automatically generated accessor of a
standard class. In the next version of PCL, this call should take
time between that of one and two function calls, but see my comments
later about porting PCL.
The important points about the functionality of this operation are:
this is a full call to a real generic function -- you can define
other methods on this generic function and thereby specialize it;
error checking happens.
Form 4:
This is like form 2 with the exception that the form appears in
a context where the compiler can infer a lot about the object
argument. In the next version of PCL, this should take time between
2 and 3 memory reads, but see my comments later about porting PCL.
Most implementations should provide performance for this on the order
of two memory reads.
Form 5:
This is like form 3 with the exception that the form appears in
a context where the compiler can infer a lot about the object
argument. PCL will not do any better in this situation, but other
implementations should be able to get performance similar to that
for form 4.
The point is that these operations have performance and functionality
differences. The appropriate mechanism must be selected, by the
programmer, to get the functionality/performance tradeoff needed in each
situation.
Because CLOS-extended Common Lisp makes it possible to define methods on
classes defined by defstruct as well as classes defined by defstruct,
decisions about how to get field access don't affect whether it will be
possible to use generic functions. This is an important point about the
tight integration of CLOS in Common Lisp.
*** Procedure Invocation and Type Dispatch ***
The second common comparison is between generic function invocation and
ordinary function invocation. This comparison is also fraught with
peril.
Given the following definitions:
(defstruct foo)
(defstruct bar)
(defclass baz () ())
(defclass bee () ())
(defun f1 (x) (defun f2 (x) (defun f3 (x)
(etypecase x (etypecase x (etypecase x
(foo <place 1>) (baz <place 3>) (foo <place 5>)
(bar <place 2>))) (bee <place 4>))) (baz <place 6>)))
(defmethod gf1 ((x foo)) <place 11>)
(defmethod gf1 ((x bar)) <place 12>)
(defmethod gf2 ((x baz)) <place 13>)
(defmethod gf2 ((x bee)) <place 14>)
(defmethod gf3 ((x foo)) <place 15>)
(defmethod gf3 ((x baz)) <place 16>)
The most important point here is to notice that we must compare the
performance of a generic function call to the performance of an ordinary
function call PLUS AN ETYPECASE. It isn't appropriate to compare the
performance of an ordinary function call to a generic function call
because a generic function call does much more than a function call.
If, in a place in your code all you need is an ordinary function, then
that is what you should use, if what you need is a function call plus
some form of type dispatch you usually want to use generic functions.
Basically, when invoking a form like (f1 <object>) or (gf2 <object>),
you should expect the time it takes to get to the corresponding <place
n> mark above to be the same. In many implementations, people will do
a better job of optimizing generic function call than typecase, so you
may even get better performance out of generic function call than
typecase. (See comments on PCL later).
Returning for a moment to functionality, generic functions provide a
great deal of functionality that ordinary functions plus typecase
doesn't. The most obvious is that the definitions of the individual
cases (the <place n> forms) above can be spread around -- individual
defmethod forms can appear in separate places. Also, defmethod forms
can be added later without having access to the source of the previously
existing defmethod forms. Also, generic functions implement inheritance
automatically. Also, generic functions implement method combination
automatically.
Taken together, the discussion of field access and the implementation
of type specific operations show that some of the decisions a user needs
to make are:
Field Access:
Do I want multiple or single inheritance?
Do I want to be able to define methods on slot accessors?
Do I want specializable primitive slot access?
Procedure invocation and type dispatch?
Do I want genericity or just simple procedure call?
Do I want automatic implementation of inheritance?
Do I want automatic implementation of method combination?
It is the answers to these kinds of questions which dictate which
language feature you should use in each particular case. Because CLOS
is a tight integration with Common Lisp, the different language features
work seamlessly together, that makes it possible for you, the programmer
to choose just the semantics you want in each case.
*** Some comments on PCL ***
This section provides one small example of the difference between PCL's
architectural performance possibilities and what happens in the current
ports. By "architectural performance possibilities", I mean what PCL
should be able to do if I had my hands on the sources of the underlying
lisp (and I had a lot more time than I do). By "what happens in the
current ports" I mean the performance of the current ports of PCL and
the port-specific reasons why that is different from the architectural
possibilities.
This discussion is limited to PCL on stock hardware, PCL was never
intended to be at all competitive on Lisp machines.
In particular we will look at a small aspect of one of PCL's major
tasks, implementing method lookup (forsimplicity, this discussion
ignores method combination.)
The essence of method lookup is that when a generic function is called,
the classes of the arguments is used to select an appropriate method to
be called and then that method is called.
This means that in the heart of method lookup, what PCL is doing is
checking the class of arguments, finding a method function to call, and
then calling that method function. All of this happens inside the PCL
runtime, where the datastructures floating around have already been
checked for errors. This means that many of the operations involved in
method lookup require no error checking. For example, PCL can be sure
that the method function it will call is a legal function, and moreover
(using a simple trick) can make sure that it is a compiled function.
So, once the method function is looked up, the actual call to it
requires no error checking.
Looking in the PCL sources (this only appears in the new, unreleased
version) we find the following definition:
(defmacro |RUNTIME FUNCALL| (fn &rest args)
`(funcall (the compiled-function ,fn) ,.args))
The use of the declaration "(the compiled-function ,fn)" corresponds to
the fact that PCL is sure that this macro (|RUNTIME FUNCALL|) will never
be used unless the fn argument is in fact a compiled function.
Architecturally, PCL has enabled an optimization which should improve
the performance of method lookup.
Unfortunately, Common Lisp compilers don't respect this declaration.
The compilers emit code which first checks to ensure that the first
argument to funcall is a function before calling it. This one thing is
just a small bit of overhead, but it directly slows down generic
function call. Not tremendously all by itself, but there are,
unfortunately, a number of others like it.
The root of the problem is that Common Lisp doesn't provide a way for
PCL to tell the underlying Common Lisp to eliminate the error checking,
and no existing port of PCL is good enough to eliminate all the
architecture--port differences. (I should also say that previous
versions of PCL have not had anywhere near as good an architecture).
It is reasonable to expect that better ports of newer versions of PCL
will have better performance. It will be interesting to compare the
performance of these to implementation specific, "hand-coded"
implementations of CLOS. I don't really know what the performance
differences will be.
*** Appendix ***
The following examples show how two, major Common Lisps for the Sun4
compile an ordinary function call and a use of funcall as shown above.
These two Common Lisps were chosen for illustrative purposes only. No
comparison between them or with any other is intended. No endorsement
of either Common Lisp is intended. No criticism of either Common Lisp
is intended. All the Common Lisps I have used generate similar code,
that is the whole point. These two were just chosen to illustrate the
general point.
Also note that even those these two code vectors look a little
different, they are substantially the same.
These two functions can be used to illustrate the difference between the
best out of line function call a given Lisp knows how to do and the kind
of function call you get when you have to use funcall.
(proclaim '(optimize (speed 3) (safety 0) (compilation-speed 0)))
(defun foo (x y)
(funcall (the compiled-function x) y))
(defun bar (x y) (baz y))
;One Common Lisp
;; disassembling #<Function FOO @ #x873716>
;; formals: X Y
;; constant vector:
;; code vector @ #x87344c:
0: save #x-60,%o6
4: move.l %i0,%l0
8: and #x7,%l0,%g2
12: subcc #x2,%g2,%g0
16: beq,a 84
20: move.l %l0,%g2
24: and #x7,%l0,%g2
28: subcc #x6,%g2,%g0
32: beq,a 40
36: moveu.b -6(%l0),%g2
40: subcc #x8,%g2,%g0
44: beq,a 116
48: move.l %l0,%o5
52: move.l %l0,%o0
56: move.l 219(%g4),%o7 ; FUNCALL
60: move.l %i1,%o1
64: jmpl 0(%o7),%o7
68: move.l #x2,%g3
72: jmpl 8(%i7),%g0
76: restore %g0,%o0
80: move.l %l0,%g2
84: move.l 6(%g2),%o5
88: move.l %i1,%o0
92: move.l -2(%o5),%g6
96: jmpl 0(%g6),%o7
100: xor #x1,%g0,%g3
104: bra 72
108: nop
112: move.l %l0,%o5
116: move.l %i1,%o0
120: move.l -2(%o5),%g6
124: move.l %g4,%g2
128: jmpl 0(%g6),%o7
132: xor #x1,%g0,%g3
136: bra 72
140: nop
;; disassembling #<Function BAR @ #x87684e>
;; formals: X Y
;; constant vector:
0: BAZ
;; code vector @ #x876784:
0: save #x-60,%o6
4: move.l 34(%i5),%g2 ; BAZ
8: move.l %i1,%o0
12: move.l 6(%g2),%o5
16: move.l -2(%o5),%g6
20: jmpl 0(%g6),%o7
24: xor #x1,%g0,%g3
28: jmpl 8(%i7),%g0
32: restore %g0,%o0
;Another Common Lisp
(disassemble 'foo)
move %in0, %loc0
move %in1, %in0
move %loc0, %ncp
move [%sq + 911], %nra ; SQ-COERCE-TO-PROCEDURE
jmpl %nra, %nra - 2
nop
move [%ncp - 2], %nra ; Function Code
move 4, %u0
jmpl %0, %nra - 2
move %ncp, %cp
(disassemble 'bar)
move %in1, %in0
move [%cp + 30], %x0 ; BAZ
move [%x0 + 13], %cp
move [%cp - 2], %nra ; Function Code
jmpl %0, %nra - 2
move 4, %u0
-------
∂01-Nov-89 0847 X3J13-mailer Re: whitespace after macros
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Nov 89 08:47:27 PST
Received: from cdr.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA08915; Wed, 1 Nov 89 09:47:22 -0700
Received: by cdr.utah.edu (5.61/utah-2.3-leaf)
id AA26270; Wed, 1 Nov 89 09:47:19 -0700
Date: Wed, 1 Nov 89 09:47:19 -0700
From: moore%cdr@cs.utah.edu (Timothy B. Moore)
Message-Id: <8911011647.AA26270@cdr.utah.edu>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 31 Oct 89 20:47 EST <19891101014747.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Re: whitespace after macros
Date: Tue, 31 Oct 89 20:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 31 Oct 89 17:56:41 -0700
From: moore%cdr@cs.utah.edu (Timothy B. Moore)
CLtL and section 3.2 of the Working Draft are quite specific about
what happens to whitespace after a token, but neither say anything
about whitespace after macro characters.
I suspect that you are being fooled by the difference between READ and
READ-PRESERVING-WHITESPACE, but that's only a guess.
I don't think so. READ-PRESERVING-WHITESPACE affects what happens to
whitespace after tokens. As I understand CLtL, macro characters aren't tokens.
For this kind of
question it's good to include in your mail the simple piece of Lisp
code that you used as a test program.
A sample file, data:
(a b c d)
abc
A test function:
(defun white-test (file)
(with-open-file (stream file)
(list (read stream) (read-char stream))))
Lucid's behavior:
> (white-test "data")
((A B C D) #\a)
>
I agree that it makes sense to throw away the whitespace after a
terminating macro character, but I just don't see where this behavior
is specified in CLtL.
Tim
∂01-Nov-89 1000 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 10:00:13 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08192g; Wed, 1 Nov 89 09:57:15 PST
Received: by bhopal id AA00590g; Wed, 1 Nov 89 09:59:07 PST
Date: Wed, 1 Nov 89 09:59:07 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911011759.AA00590@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 31 Oct 89 15:56 EST <19891031205628.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
Dave, I'm afraid your comments in this reply are directed entirely at
some other proposal (possibly the one we privately discussed in June,
and decided not to work further on?) For example, among other things,
you say:
- Division by Zero is in the IEEE spec as a disablable exception but
is missing from your proposal.
But the introduction to the proposal clearly says:
The currently proposed error system contains names for three conditions
related to floating-point operations: floating-point-underflow,
floating-point-overflow, and division-by-zero.
Also you say:
- There is no dynamic-extent form of floating-point exception enabling, ...
- There is still no specification of what causes the conditions to
be signalled (neither the new conditions nor the existing ones).
But the issue FLOATING-POINT-CONDITION-NAMES addressed *only* the names to
use in the condition system for what are mandated conditions by the IEEE
spec. It specifically said that it would not address the means of
enabling or disabling, and the comments section said:
Moon and JonL privately discussed some means for enabling and
disabling various floating-point traps, back in June 1989 when the
float-underflow proposal was under discussion; they came to the
conclusion that "getting the design right and efficient" was more
than a few minutes worth of work, and so postponed further work on it.
-- JonL --
∂01-Nov-89 1010 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 10:10:11 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08220g; Wed, 1 Nov 89 10:07:12 PST
Received: by bhopal id AA00684g; Wed, 1 Nov 89 10:09:07 PST
Date: Wed, 1 Nov 89 10:09:07 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911011809.AA00684@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 31 Oct 89 16:47 EST <19891031214724.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
re: I don't remember if
we allowed multiple-inheritance for the condition system.
We didn't used to, but we do now. See for example, simple-warning on
p.2-19 of the recently distributed draft. It's defined in a way that
can only be implemented using multiple inheritance. Fortunately CLOS
is available to provide the multiple inheritance.
Yea, I remember that discussion, and the subsequent worry about this
being one of the few places in the non-CLOS part of the spec that
absolutely requires CLOS.
Given the ISO and Japanese worries about CLOS, I'd certainly prefer not
to have the floating-point condition hieararchy force the CLOS issue --
it's really a very minor point about the one codition division-by-zero.
-- JonL --
P.S. Which is not to say that I want to avoid the ISO-CLOS issue --
merely that I wouldn't like to have it bundled into the
floating-point condition names issue.
∂01-Nov-89 1031 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 1 Nov 89 10:30:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 685572; 1 Nov 89 13:29:32 EST
Date: Wed, 1 Nov 89 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
To: Jon L White <jonl@lucid.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8911011759.AA00590@bhopal>
Message-ID: <19891101182932.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 1 Nov 89 09:59:07 PST
From: Jon L White <jonl@lucid.com>
Dave, I'm afraid your comments in this reply are directed entirely at
some other proposal (possibly the one we privately discussed in June,
and decided not to work further on?) For example, among other things,
you say:
- Division by Zero is in the IEEE spec as a disablable exception but
is missing from your proposal.
But the introduction to the proposal clearly says:
The currently proposed error system contains names for three conditions
related to floating-point operations: floating-point-underflow,
floating-point-overflow, and division-by-zero.
I apologize, somehow I missed seeing that. Possibly that happened because
I generally read the Proposal section of an issue writeup much more carefully
than the other sections of supporting material.
Also you say:
- There is no dynamic-extent form of floating-point exception enabling, ...
- There is still no specification of what causes the conditions to
be signalled (neither the new conditions nor the existing ones).
But the issue FLOATING-POINT-CONDITION-NAMES addressed *only* the names to
use in the condition system for what are mandated conditions by the IEEE
spec. It specifically said that it would not address the means of
enabling or disabling, and the comments section said:
Moon and JonL privately discussed some means for enabling and
disabling various floating-point traps, back in June 1989 when the
float-underflow proposal was under discussion; they came to the
conclusion that "getting the design right and efficient" was more
than a few minutes worth of work, and so postponed further work on it.
While what you say about the scope of your proposal is true, my point is
that because it omits parts of the complete solution, it's not very
useful by itself. This supports my larger point, also supported by the
comments you quoted just above, that there simply isn't time, five
months AFTER the "feature freeze" for ANSI Common Lisp, to design this
feature properly, and therefore we really are forced not to solve this
particular problem this time around. I wish that wasn't true but
wishing won't change it.
∂01-Nov-89 1141 X3J13-mailer define-method-combination
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 11:41:40 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08584g; Wed, 1 Nov 89 11:38:08 PST
Received: by bhopal id AA01288g; Wed, 1 Nov 89 11:40:03 PST
Date: Wed, 1 Nov 89 11:40:03 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911011940.AA01288@bhopal>
To: Gregor.pa@Xerox.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM,
x3j13@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 31 Oct 89 18:36 PST <19891101023633.8.GREGOR@SPIFF.parc.xerox.com>
Subject: define-method-combination
re: The general idea is to recognize that many effective methods will have
the same "shape". For example, all compiled effective methods with one
before, one primary and one after method have the same "shape", even if
the specific methods involved are different.
I think you are presuming standard method-combination here -- :before
and :after methods etc -- but that's not all that important since the
idea can be generalized.
In fact, PCL's technique for implementing standard method-combination
appears to be much more general than is necessary for the purely
"standard" case. I believe that something like it can be fruitfully
used to pre-compile all the effective methods of any method-combination
needed by an application -- providing that at application run time there
are no new "interesting" calls to DEFMETHOD (really, no substantive
alterations of the generic function in question). In the case of standard
method-combination (and many like it) it is even possible to produce one
"most general effective method" that will work for all possible effective
methods on that function; and in this case, even "interesting" calls to
DEFMETHOD could be allowed. I won't vouch for the runtime efficiency of
this "most general" method, but clearly a "mixed bag" with only a fixed,
small set of such tools won't be all that inefficient.
On the other hand, it appears to me that Barry has a point worth
considering -- namely that pre-compiling will apparently necessitate
the provision of effective methods (i.e., "shapes" in the terminology
of your msg) which may or may not be used at runtime. It is just not
mechanically possible possible to predict whether a particular
combination of arguments to a generic function will come up at runtime
that will actualy invoke an effective method with a particular "shape".
As to whether or not the wasted space for unused-but-apparent effective
methods is a problem -- well, I won't hazard a single conjecture. As so
often happens in matters like this, it will likely be irrelevant to one
whole raft of users, and will be a major pitfall to some other (hopefully
smaller) raft. It's impossible to get a single statistic that adequately
summarizes the situations of these two "rafts".
-- JonL --
∂01-Nov-89 1233 X3J13-mailer RE: whitespace after macros
Received: from atc.boeing.com ([130.42.28.80]) by SAIL.Stanford.EDU with TCP; 1 Nov 89 12:33:12 PST
Received: by atc.boeing.com on Wed, 1 Nov 89 12:31:46 PST
Date: Wed, 1 Nov 89 12:35 PST
From: Stephen Nicoud <snicoud@atc.boeing.com>
Subject: RE: whitespace after macros
To: Timothy B. Moore <moore%cdr@cs.utah.edu>
Cc: x3j13@sail.stanford.edu
Message-Id: <19891101203528.8.SLN@SKAGIT.atc.boeing.com>
From: moore%cdr@cs.utah.edu (Timothy B. Moore)
Date: 1 Nov 89 01:09:03 GMT
CLtL and section 3.2 of the Working Draft are quite specific about
what happens to whitespace after a token, but neither say anything
about whitespace after macro characters. Step 4 of the state machine
on pg 335 of CLtL implies that no characters of any kind are looked
at after a character macro function returns. However 2
implementations, HPCL I and Lucid, appear to eat the whitespace
character after a terminating macro character.
Is this addressed in any other part of the Standard? Should it be specified?
Tim
I have run across differences in the behavior of READ in various
implementations (Symbolics vs. Explorer and Lucid).
Here's an example:
Assume a file ("my-file.lisp") with only this one line:
(a) (b)(c) (d)
;; Now, I OPEN the file ...
> (setq my-file-stream (open "my-file.lisp" :element-type 'string-char))
#<STREAM "my-file" blah... blah>
;; and do a READ.
> (read my-file-stream)
(A)
;; When I next do a FILE-POSITION on my-file-stream here are the results:
> (file-position my-file-stream)
;; Symbolics
3
;; Explorer and Lucid
4
> (read my-file-stream)
(B)
> (file-position my-file-stream)
;; Symbolics, TI, and Lucid
7
> (read my-file-stream)
(C)
> (file-position my-file-stream)
;; Symbolics
10
;; Explorer and Lucid
11
> (close my-file-stream)
NIL
∂01-Nov-89 1312 X3J13-mailer whitespace after macros
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 13:12:17 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08884g; Wed, 1 Nov 89 13:09:07 PST
Received: by bhopal id AA01597g; Wed, 1 Nov 89 13:11:02 PST
Date: Wed, 1 Nov 89 13:11:02 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911012111.AA01597@bhopal>
To: moore%cdr@cs.utah.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, x3j13@sail.stanford.edu
In-Reply-To: Timothy B. Moore's message of Wed, 1 Nov 89 09:47:19 -0700 <8911011647.AA26270@cdr.utah.edu>
Subject: whitespace after macros
re: I don't think so. READ-PRESERVING-WHITESPACE affects what happens to
whitespace after tokens. As I understand CLtL, macro characters aren't
tokens. . . .
See CLtL, pp374-5, especially the example with the "incorrect" definition
of the function for the single-quote macro character. This to me implies
that macro-character parsings should obey the same "preservation" semantics
as tokens. Otherwise the second major reason for the 'recursive-p'
argument to READ would not be worthy of consideration (see the paragraph
on p375 beginning "Second, a recursive ...").
re: A sample file, data:
(a b c d)
abc
A test function:
(defun white-test (file)
(with-open-file (stream file)
(list (READ stream) (read-char stream))))
Lucid's behavior:
> (white-test "data")
((A B C D) #\a)
Note what "Lucid's behavior" is when the test function is:
(defun white-test (file)
(with-open-file (stream file)
(list (READ-PRESERVING-WHITESPACE stream) (read-char stream))))
namely:
> (white-test "data")
((A B C D) #\Newline)
I believe "preservation of whitespace" is intended to be a property of
the outer call to READ or READ-PRESERVING-WHITESPACE. Your example does
not show the macro character function as "eating" any following whitespace
characters -- rather the #\Newline is gobbled up by the outer call to READ.
On the other hand, it is clear that READ-PRESERVING-WHITESPACE doesn't
gobble up the terminating whitespace.
-- JonL --
∂01-Nov-89 1321 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 13:21:45 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08980g; Wed, 1 Nov 89 13:18:42 PST
Received: by bhopal id AA01638g; Wed, 1 Nov 89 13:20:28 PST
Date: Wed, 1 Nov 89 13:20:28 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911012120.AA01638@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 1 Nov 89 13:29 EST <19891101182932.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
re: . . . there simply isn't time, five
months AFTER the "feature freeze" for ANSI Common Lisp, to design this
feature properly, and therefore we really are forced not to solve this
particular problem this time around.
You still appear to be confusing (1) the question of the names of supported
conditions with (2) the mechanics for enabling/disabling hardware features
that these names imply.
The currently accepted condition system proposal contains the names
FLOATING-POINT-OVERFLOW, FLOATING-POINT-UNDERFLOW, and DIVISION-BY-ZERO
*** without addressing the issue of how to enable or disable them ***.
I only propose to smooth out the set of condition names relevant to
floating point, especially so that it is useful in IEEE impelmentations.
-- JonL --
∂01-Nov-89 1454 X3J13-mailer Issue: FLOATING-POINT-CONDITION-NAMES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 1 Nov 89 14:54:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 685840; 1 Nov 89 17:25:47 EST
Date: Wed, 1 Nov 89 17:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLOATING-POINT-CONDITION-NAMES
To: Jon L White <jonl@lucid.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8911012120.AA01638@bhopal>
Message-ID: <19891101222549.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 1 Nov 89 13:20:28 PST
From: Jon L White <jonl@lucid.com>
re: . . . there simply isn't time, five
months AFTER the "feature freeze" for ANSI Common Lisp, to design this
feature properly, and therefore we really are forced not to solve this
particular problem this time around.
You still appear to be confusing (1) the question of the names of supported
conditions with (2) the mechanics for enabling/disabling hardware features
that these names imply.
The currently accepted condition system proposal contains the names
FLOATING-POINT-OVERFLOW, FLOATING-POINT-UNDERFLOW, and DIVISION-BY-ZERO
*** without addressing the issue of how to enable or disable them ***.
I only propose to smooth out the set of condition names relevant to
floating point, especially so that it is useful in IEEE impelmentations.
The proposal that I was talking about is this one:
Date: Mon, 30 Oct 89 19:03:55 PST
From: Jon L White <jonl@lucid.com>
Proposal (FLOATING-POINT-CONDITION-NAMES:ADD-MINIMAL-IEEE)
1. Add FLOATING-POINT-INVALID-OPERATION and FLOATING-POINT-INEXACT
as conditions which are sub-conditions of ARITHMETIC-ERROR.
This is a proposal to add some condition names.
2. Add a global parameter SUPPORTED-FLOATING-POINT-CONDITIONS which
is to contain a list of all the condition names that can, in that
implementation, be enabled as floating-point traps; this is to
be an "implementation revealing" parameter.
This is a proposal relating to enabling or disabling traps, not a
proposal to add some condition names.
3. Add a function of no arguments ENABLED-FLOATING-POINT-TRAPS which
returns a list of condition names for all currently enabled
floating point trapping conditions.
This is a proposal relating to enabling or disabling traps, not a
proposal to add some condition names.
The intent is that if condition FOO is a currently enabled floating
point trap, then whenever that particular situation arises the
system will arrange to signal the Lisp condition FOO.
This statement is too incomplete to let a programmer know how to use
this facility.
The means for
enabling and disabling traps is not addressed in this proposal.
This statement indicates the proposal is too incomplete to let a
programmer know how to use this facility.
I don't think I'm confusing two different proposals.
If when you said
I only propose to smooth out the set of condition names relevant to
floating point, especially so that it is useful in IEEE impelmentations.
you were saying that you are now reducing your proposal to just point
1, then I don't think there are any design issues as such. Those are
simply names of conditions that might be signalled in some unspecified
circumstances, just like the existing names FLOATING-POINT-OVERFLOW and
FLOATING-POINT-UNDERFLOW. I wouldn't object to that smaller proposal on
the grounds of time, since there is nothing to discuss but the names and
the names you propose are consistent. I would still comment that the
proposal is not useful by itself, just as the existing conditions
FLOATING-POINT-OVERFLOW and FLOATING-POINT-UNDERFLOW are not useful
by themselves because their integration into the language was never
completed.
∂01-Nov-89 1718 X3J13-mailer Re: define-method-combination
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Nov 89 17:17:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 NOV 89 17:15:07 PST
Date: Wed, 1 Nov 89 17:14 PST
From: Gregor.pa@Xerox.COM
Subject: Re: define-method-combination
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM,
x3j13@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
In-Reply-To: <8911011940.AA01288@bhopal>
Message-ID: <19891102011456.3.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Wed, 1 Nov 89 11:40:03 PST
From: Jon L White <jonl@lucid.com>
I think you are presuming standard method-combination here -- :before
and :after methods etc -- but that's not all that important since the
idea can be generalized.
In fact, PCL's technique for implementing standard method-combination
appears to be much more general than is necessary for the purely
"standard" case.
Yes, even in earlier versions of PCL, where only standard method
combination is supported, the compiled effective method "shape" code is
quite general purpose. It was designed to work with other kinds of
method combinations, including user defined ones using the long form of
define-method-combinations or even methods the user defines directly on
compute-effective-method.
In later PCLs, which support define-method-combination, you can see that
only a couple of changes were made to get it to support all of that.
One point though is that, in retrospect, I think it was a mistake to use
the real code walker for comparison of templates. It is of course
necessary (if unfortunate) to use the real code walker to produce the
code generators.
In the case of standard
method-combination (and many like it) it is even possible to produce one
"most general effective method" that will work for all possible effective
methods on that function; and in this case, even "interesting" calls to
DEFMETHOD could be allowed.
As near as I can tell, this is what the Procyon implementation does.
On the other hand, it appears to me that Barry has a point worth
considering -- namely that pre-compiling will apparently necessitate
the provision of effective methods (i.e., "shapes" in the terminology
of your msg) which may or may not be used at runtime. It is just not
mechanically possible possible to predict whether a particular
combination of arguments to a generic function will come up at runtime
that will actualy invoke an effective method with a particular "shape".
Right, this is the desired data I was alluding to. It would be nice to
know, for a number of large applications, just how many "wasted" shapes
there are.
-------
∂01-Nov-89 1802 X3J13-mailer re: WG16 Action Items
To: jeff%aiai.edinburgh.ac.uk@NSFNET-RELAY.AC.UK,
x3j13@SAIL.Stanford.EDU
CC: chaynes@IUVAX.CS.INDIANA.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK sent Tue, 31 Oct 89 17:58:17 GMT.]
Does the "CL subset approach" use the French definition of "subset"
or some other one or does it not matter?
I quoted the actions items verbatim. I have no further information about
what the Convenor or Secretary who took notes intends for the meaning
of ``CL subset approach.''
-rpg-
∂02-Nov-89 1011 X3J13-mailer issue &ENVIRONMENT-BINDING-ORDER, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:11:30 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15561; Thu, 2 Nov 89 09:19:40 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17290; Thu, 2 Nov 89 09:19:36 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911021619.AA17290@defun.utah.edu>
Date: Thu, 2 Nov 89 09:19:35 MST
Subject: issue &ENVIRONMENT-BINDING-ORDER, version 2
To: x3j13@sail.stanford.edu
Forum: Cleanup
Issue: &ENVIRONMENT-BINDING-ORDER
References: CLtL p. 145-146, 63
Issue DEFMACRO-LAMBDA-LIST
Category: CLARIFICATION
Edit History: V1, 24 Oct 1989, Sandra Loosemore
V3, 02 Nov 1989, Sandra Loosemore (comments from Moon)
Problem Description:
Issue DEFMACRO-LAMBDA-LIST states that &ENVIRONMENT can appear once
anywhere at top level of a macro lambda list, but doesn't say anything
about the order in which the &ENVIRONMENT variable is bound relative
to the other lambda-list variables.
Some implementations treat &ENVIRONMENT as a mechanism for naming the
second argument to the macro function, in which case it is bound
before any of the variables in the actual destructuring pattern.
Other implementations bind it with the other lambda parameters in the
usual left-to-right order.
The binding order of &WHOLE parameters is not an issue. This is
because a &WHOLE parameter must appear first in the lambda list, so
there is no difference between binding it first or binding it
left-to-right. The relative binding order of &WHOLE and &ENVIRONMENT
parameters is not an issue because neither one can include init forms
where the binding of the other might be visible.
There are two proposals, FIRST and LEFT-TO-RIGHT.
Proposal (&ENVIRONMENT-BINDING-ORDER:FIRST):
Clarify that the &ENVIRONMENT parameter is bound along with &WHOLE
before any of other variables in the lambda list, regardless of where
&ENVIRONMENT appears in the lambda list.
Rationale:
This proposal provides a convenient explanation for the special
treatment of &WHOLE and &ENVIRONMENT at top-level in a DEFMACRO-style
lambda list. Basically, these two parameters are stripped out and
used to name the two arguments to the macro function, then the binding
of the remaining arguments is handled exactly the same as at
non-top-level or in a DESTRUCTURING-BIND. It is also very
straightforward to implement this model (as opposed to having
special parsing code for destructuring top-level DEFMACRO lambda
lists).
Proposal (&ENVIRONMENT-BINDING-ORDER:LEFT-TO-RIGHT):
Clarify that the all lambda variables in a DEFMACRO-style lambda list
are bound left-to-right, including the &WHOLE and &ENVIRONMENT parameters.
Rationale:
This is more consistent with the order in which variables in ordinary
lambda lists are bound.
Current Practice:
Lucid CL, Utah CL, and KCL implement proposal FIRST. CMU CL
implements proposal LEFT-TO-RIGHT.
Symbolics Genera implements proposal FIRST. Specifically, &WHOLE is
bound first, followed by &ENVIRONMENT, then the destructuring
variables in the order listed.
Cost to implementors:
The changes are probably localized but potentially hairy. It is
possible that in some implementations it might be easier to completely
replace the code which handles lambda-list parsing and destructuring
than to try to patch it. Proposal FIRST is probably easier to
implement initially but the cost of converting an existing
implementation is probably about the same for both proposals.
Cost to users:
There are probably few user programs that would be affected by a
change in the binding order of &ENVIRONMENT parameters.
Benefits:
The language specification is made more precise.
Discussion:
Moon says:
I believe LEFT-TO-RIGHT is more clean, but I don't have strong feelings.
I am equally in favor of either of the two presented proposals or an
EXPLICITLY-VAGUE proposal.
-------
∂02-Nov-89 1012 X3J13-mailer issue MACRO-DECLARATIONS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:12:16 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15615; Thu, 2 Nov 89 09:21:25 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17308; Thu, 2 Nov 89 09:21:22 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911021621.AA17308@defun.utah.edu>
Date: Thu, 2 Nov 89 09:21:20 MST
Subject: issue MACRO-DECLARATIONS, version 2
To: x3j13@sail.stanford.edu
Forum: Cleanup
Issue: MACRO-DECLARATIONS
References: Issue SYMBOL-MACROLET-DECLARE
Issue DECLARATION-SCOPE
Issue DECLARE-TYPE-FREE
Issue DEFINE-COMPILER-MACRO
Issue DYNAMIC-EXTENT
Issue DYNAMIC-EXTENT-FUNCTION
Declarations (CLtL chapter 9)
Category: CLARIFICATION
Edit History: V1, 26 Oct 1989, Sandra Loosemore
V2, 02 Nov 1989, Sandra Loosemore (suggestions from Moon)
Problem Description:
Issue SYMBOL-MACROLET-DECLARE defines a meaning for TYPE declarations
when the lexically visible "binding" of the symbol names a
symbol-macro. It also requires SYMBOL-MACRO to signal an error if a
SPECIAL declaration is provided in the body for a symbol which it
defines as a symbol-macro.
What is the meaning of a SPECIAL declaration appearing in some other
context (such as in a LOCALLY construct), for a symbol for which the
lexically apparent "binding" is a symbol-macro definition? How about
any other declaration which normally applies to a variable or function
binding (IGNORE, DYNAMIC-EXTENT, FTYPE, INLINE, NOTINLINE) when the
lexically apparent "binding" is a macro or symbol-macro definition?
Proposal (MACRO-DECLARATIONS:MAKE-EXPLICIT):
Clarify that the standard declarations that apply to function or variable
bindings have the following effects when the binding is a macro or
symbol-macro:
SPECIAL
SYMBOL-MACROLET signals an error if it includes a SPECIAL declaration
for any symbol that it binds as a symbol-macro. [Issue
SYMBOL-MACROLET-DECLARE] Presumably, this error is of type
PROGRAM-ERROR and is signalled at compile-time rather than run-time.
A SPECIAL declaration for a symbol whose lexically visible binding
is a symbol-macro causes that binding to be shadowed, in the same way
that a SPECIAL declaration shadows lexical variable bindings.
TYPE
A TYPE declaration for a symbol that names a symbol-macro is equivalent
to wrapping a THE expression around the expansion of that symbol-macro.
[Issue SYMBOL-MACROLET-DECLARE] This is meaningful regardless of whether
the declaration appears in the form that bound the symbol-macro or as a
free declaration within the scope of the symbol-macro binding. Multiple
TYPE declarations applying to a single symbol-macro binding are handled
in the same way as multiple TYPE declarations that apply to a
single variable binding.
FTYPE
This declaration is not valid when the lexically apparent binding
is a macro binding rather than a function binding. (This is because
FTYPE declares the functional binding of the name to be of a particular
subtype of FUNCTION, and macros are not FUNCTIONs.)
IGNORE
IGNORE declarations for symbol-macro bindings should be treated in
exactly the same way as IGNORE declarations for variable bindings.
In other words, such a declaration specifies that the bindings of
of the specified symbol-macros are never used.
DYNAMIC-EXTENT
This declaration is not valid when the lexically apparent binding
is a symbol-macro or macro binding rather than a variable or
function binding.
NOTINLINE
In the presence of compiler-macro definitions, this declaration
affects references to macros in exactly the same way that it affects
references to functions. When the lexically apparent binding is a
macro that also has a compiler-macro definition, this declaration can
be used to indicate to a language processor that the macro (and not the
compiler-macro) definition should be used. [Issue DEFINE-COMPILER-MACRO.]
A NOTINLINE declaration for a macro has otherwise has no effect on
its expansion. Implementations are not free to ignore this declaration.
INLINE
To parallel treatment of NOTINLINE, in the presence of compiler-macro
definitions, this declaration affects references to macros in exactly
the same way that it affects references to functions. When the lexically
apparent binding is a macro that also has a compiler-macro definition,
this declaration can be used to indicate to a language processor that
the compiler-macro (and not the macro) definition should be used. An
INLINE declaration for a macro otherwise has no effect on its expansion.
Implementations are free to ignore this declaration.
In those situations where the use of the declaration is not valid, the
consequences of evaluating or compiling the program are undefined.
Rationale:
This proposal is primarily an explicit restatement of things which have
already been stated in other places, with some obvious interpolations
added.
Leaving the consequences undefined permits implementations to signal
an error, to assign some implementation-specific interpretation to
the declaration, or simply to ignore the declaration.
Current Practice:
Utah Common Lisp implements this proposal. It currently ignores all
declarations that apply to function or variable bindings when the
lexically visible binding is a macro or symbol-macro. The
declarations are added to the environment in the normal way but are
never examined by the interpreter or compiler. The exception is that
a SPECIAL declaration will shadow a symbol-macro definition in the
same way that it will shadow a lexical variable binding.
Neither HPCL-I nor Lucid CL complain about FTYPE or INLINE/NOTINLINE
declarations when the lexically visible function "binding" is a macro.
They are apparently being ignored. KCL ignores all declarations
that apply to function bindings (and doesn't yet support symbol-macros).
Cost to implementors:
Presumably small.
Cost to users:
It seems unlikely that this proposal would be an incompatible change
that causes many user programs to break, particularly given the
relative newness of symbol-macros and compiler-macros.
Benefits:
More complete specification of the language and less chance for confusion
to arise later on.
Aesthetics:
Some people might be bothered by the asymmetry between the handling of
TYPE and FTYPE declarations. Strictly speaking, the special handling for
TYPE declarations is unnecessary since one could explicitly include the
THE form in the expansion of the symbol-macro. Other people probably
think that the notational convenience outweighs the asymmetry.
Discussion:
-------
∂02-Nov-89 1011 X3J13-mailer issue READER-ERROR, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:11:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15636; Thu, 2 Nov 89 09:21:55 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17314; Thu, 2 Nov 89 09:21:53 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911021621.AA17314@defun.utah.edu>
Date: Thu, 2 Nov 89 09:21:51 MST
Subject: issue READER-ERROR, version 2
To: x3j13@sail.stanford.edu
Forum: Cleanup
Issue: READER-ERROR
References: Chapter 3, "Syntax"
Section 2.2, "Types"
Category: ADDITION, CHANGE
Edit History: V1, 23 Oct 1989, Sandra Loosemore
V2, 02 Nov 1989, Sandra Loosemore
(change supertypes, update discussion)
Problem Description:
Chapter 3 of the current draft is not consistent about the types of
errors that must be signalled by the reader. In most places where it
specifies that an error is to be signalled, it does not indicate a
particular type of error, but in at least one situation it requires
the error to be of type PROGRAM-ERROR, and in other cases it requires
the error to be of type ERROR.
None of the ERROR subtypes described in section 2.2 really seem
appropriate for syntactic errors detected by the reader. In
particular, the description of PROGRAM-ERROR implies that its purpose
is for errors relating to program syntax which are detectable during
evaluation or compilation rather than read-time errors. It seems
especially inappropriate to use PROGRAM-ERROR for this purpose since
the reader can be used to read things other than programs. Likewise,
STREAM-ERROR appears to have been intended to be used for errors
relating to character-level transactions on the stream rather than
lexical analysis or parsing.
Proposal (READER-ERROR:NEW-TYPE):
Add a new type specifier, READER-ERROR. This is a subtype of the
types STREAM-ERROR, ERROR, SERIOUS-CONDITION, CONDITION, and T. The
type READER-ERROR consists of serious conditions that relate to
lexical analysis (the building and interpretation of tokens) and
parsing (errors in reader macro syntax) by the Lisp reader.
Since READER-ERROR is a subtype of STREAM-ERROR, objects of this type
inherit a STREAM slot, which can be accessed using the function
STREAM-ERROR-STREAM.
Change the discussion in chapter 3 to specify that the type of errors
signalled by the reader is READER-ERROR. There are numerous places
that would be affected.
Rationale:
The general policy that has been followed in other areas of the
language where errors must, should, or might be signalled is to
specify a particular subtype of ERROR which covers that class of
errors. Doing the same for reader errors would be consistent with the
overall policy, but none of the existing error types seem appropriate
for reader-related errors.
Current Practice:
LispWorks (from Harlequin) reportedly already uses such a condition.
Cost to implementors:
Trivial.
Cost to users:
Probably no user programs rely on the reader signalling any particular
type of error yet.
Benefits:
Increased consistency in the language design.
Ability to set up handlers specifically for reader errors.
Discussion:
Pitman says:
Our later comments will show that i would like this condition to be
called PARSE-ERROR so that it doesn't seem to be useful only for
READ-related problems but can in fact be used for other parser-style
applications (e.g., a FORTRAN parser, a user-written English-language
interface, etc.).
The initial version of this proposal specified that READER-ERROR was
disjoint from (rather than a subtype of) STREAM-ERROR. This was
changed because there was a suggestion that some conditions should be
both a READER-ERROR and a STREAM-ERROR. Making it a subtype also allows
it to inherit the STREAM slot and the STREAM-ERROR-STREAM accessor.
-------
∂02-Nov-89 1011 X3J13-mailer issue DEFMACRO-BLOCK-SCOPE, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:11:45 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15572; Thu, 2 Nov 89 09:20:23 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17296; Thu, 2 Nov 89 09:20:20 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911021620.AA17296@defun.utah.edu>
Date: Thu, 2 Nov 89 09:20:19 MST
Subject: issue DEFMACRO-BLOCK-SCOPE, version 2
To: x3j13@sail.stanford.edu
Forum: Cleanup
Issue: DEFMACRO-BLOCK-SCOPE
References: Issue FLET-IMPLICIT-BLOCK
Category: CLARIFICATION
Edit History: V1, 24 Oct 1989, Sandra Loosemore
V2, 02 Nov 1989, Sandra Loosemore
(update current practice, discussion)
Problem Description:
Does the scope of the implicit BLOCK that surrounds the body of
DEFMACRO, MACROLET, DEFINE-SETF-METHOD, DEFTYPE, and
DEFINE-COMPILER-MACRO (the forms that define functional objects that
also support destructuring) include the bindings of the variables in
the destructuring pattern? In other words, is the BLOCK visible
during the evaluation of initialization forms included in the lambda
list?
It seems clear that in forms such as DEFUN which do not support
destructuring, the BLOCK surrounds only the body and includes none of
the lambda-variable binding forms.
There are two proposals, INCLUDES-BINDINGS and EXCLUDES-BINDINGS.
Proposal (DEFMACRO-BLOCK-SCOPE:INCLUDES-BINDINGS):
Clarify that the scope of the implicit BLOCK in the functions defined
by the forms listed above does include the initialization forms within
the lambda list as well as the body forms.
Rationale:
One can view the destructuring code which binds the variables in the
lambda list as part of the body of the function (for example, as
equivalent to a LET* or DESTRUCTURING-BIND construct), which would
be inside the scope of the BLOCK in an ordinary function-defining form.
Some users might find this behavior marginally more useful than the
other alternative.
Proposal (DEFMACRO-BLOCK-SCOPE:EXCLUDES-BINDINGS):
Clarify that the scope of the implicit BLOCK in the functions defined
by the forms listed above includes only the body forms and not the
initialization forms within the lambda list.
Rationale:
One can view the destructuring code which binds the variables in the
lambda list as part of the ordinary lambda-list processing (for example,
as equivalent to binding &AUX variables), which would be outside the
scope of the BLOCK in an ordinary function-defining form. Some people
might find this to be more consistent with the scoping of the BLOCK
in the non-destructuring cases.
Current Practice:
Lucid CL, Utah CL, CMU Common Lisp, Symbolics Genera 7.2, and Franz's
Allegro Common Lisp currently implement proposal INCLUDES-BINDINGS.
Kyoto CL implements proposal EXCLUDES-BINDINGS.
Cost to implementors:
Probably not too much effort involved to fix it.
Cost to users:
Currently nonportable user programs that depend on this being done the
other way will break, but this is a rather obscure point and it is
unlikely that there would be many programs affected.
Benefits:
The specification of the language is made more precise.
Aesthetics:
EXCLUDES-BINDINGS is probably more aesthetic than INCLUDES-BINDINGS
since it makes the behavior of DEFMACRO and friends consistent with
that of DEFUN.
Discussion:
Moon writes:
[There is a third option that] is like INCLUDES-BINDINGS but also
changes DEFUN, DEFMETHOD, FLET, LABELS, and any others that I forgot.
This third option seems clearly correct to me, however it has the
defects that it does not correspond to any current practice and that
it is impossible to implement reasonably in terms of macro expansion
into LAMBDA (basically, a defect in LAMBDA that it has no syntactic
way to express a block name). Given that, I think we probably have
to go with EXCLUDES-BINDINGS, but I'd like to see your proposal
mention all three options.
-------
∂02-Nov-89 1012 X3J13-mailer issue EVALHOOK-STEP-CONFUSION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:12:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15590; Thu, 2 Nov 89 09:20:56 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17302; Thu, 2 Nov 89 09:20:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911021620.AA17302@defun.utah.edu>
Date: Thu, 2 Nov 89 09:20:52 MST
Subject: issue EVALHOOK-STEP-CONFUSION, version 2
To: x3j13@sail.stanford.edu
Forum: Cleanup
Issue: EVALHOOK-STEP-CONFUSION
References: CLtL p 321, 323, 441
Issue STEP-ENVIRONMENT (passed)
Issue APPLYHOOK-ENVIRONMENT (passed)
Category: CHANGE/CLARIFICATION
Edit History: V1, 9 Oct 1989, Sandra Loosemore
V2, 2 Nov 1989, Sandra Loosemore (update discussion)
Problem Description:
Common Lisp permits the evaluator to be implemented by compiling the
form before executing it, but notes that this techniques "renders the
EVALHOOK mechanism relatively useless" (CLtL p. 321).
CLtL also requires the STEP utility to be implemented in terms of
EVALHOOK (p. 323). The restriction against implementing STEP using
some other technique (such as annotations on code lexically within the
body of the STEP) that make more sense in a compiled-only
implementation is pointless. It is probably not even desirable for
STEP to be implemented with *EVALHOOK*, since this effectively causes
the stepper to break on user programs that also use *EVALHOOK*.
Proposal (EVALHOOK-STEP-CONFUSION:FIX):
(1) Clarify that there is no guarantee that the functions that are the
values of *EVALHOOK* and *APPLYHOOK* will ever be invoked during
evaluation.
(2) Remove the requirement that STEP be implemented using *EVALHOOK*.
Make it explicitly vague whether the scope of the code that is affected
by STEP is lexical or dynamic.
(3) Deprecate *EVALHOOK*, *APPLYHOOK*, EVALHOOK, and APPLYHOOK.
Rationale:
Point by point:
(1) This is merely an explicit statement of the status quo.
(2) This permits compiled-only implementations to support a STEP
utility that does something useful.
(3) The eval hook mechanism is a relic of a particular interpreter
implementation technique and really has no place in a language
standard, especially since one of the stated goals of the language is
consistency between compiled and interpreted code. Since there is no
guarantee that these functions will ever be invoked, portable programs
should not rely on them.
Current Practice:
According to Kent Pitman:
I'm told by the guys who did the Cloe implementation that indeed
neither evalhook nor step do much of anything useful. If I understood
them correctly, *evalhook* just never gets called, and step works by a
different mechanism that may work at a granularity different than what
people expect.
Loosemore has been implementing an evaluator for Utah Common Lisp that
uses a preprocessor to partially compile programs. The interpreter
for the processed code does support the use of an *evalhook*-like
special variable, but the information it is passed is in a different
format than that which *evalhook* requires. In particular, the object
representing the lexical environment contains only bindings and not
syntactic information such as macro definitions. It also supports a
variety of annotation-based program debugging hooks that are specified
by declarations. We are in the process of integrating the
preprocessor into the UCL compiler so that most of these debugging
hooks will also work in compiled code.
Cost to implementors:
None.
Cost to users:
None.
Benefits:
Users will not be misled into thinking *evalhook* is more portable
than it actually is.
Compiled-only implementations can make STEP do something reasonable.
Discussion:
There is an article by Parker in Lisp Pointers, Vol 1 #4 which
describes one approach for annotation-based debugging. Loosemore's
PhD dissertation (soon to be available as a UofU Tech Report) also
discusses alternate approaches for implementing program steppers.
Scott Fahlman says:
I am staying out of most of these discussions, but thought I'd throw in my
two cents' worth on this one: I would very much like to see evalhook and
applyhook removed from the standard. They have been a constant source of
confusion, and there are so many different interpretations of what these
hooks do that facilities built on top of them are not really very portable
in practice. I'm now convinced that a really good stepping package cannot
easily be written using these hooks, but must be integrated into the
interpreter of a given implementation.
David Moon says:
Seems okay, except that if we are going to deprecate these things,
I would much rather just remove them. You would surely argue that
no significant program could possibly be depending on EVALHOOK,
since it has no semantics, so there can't be a compatibility issue.
If we agree that something is a bad idea, I would rather remove it
entirely unless there is a compelling compatibility reason to only
deprecate it. In fact even if some programs used EVALHOOK, I would
still want to remove it, as I long ago ceased to believe in any
fantasy of seamless compatibility between CLtL and ANSI CL. But
others might not agree with me there.
Plus if we remove them, Symbolics doesn't have to fix the bug that
EVALHOOK and APPLYHOOK accidentally got declared SPECIAL. I mention
this only as an example of the costs of deprecating things instead
of removing them. They have to be maintained. Not only do they have
to be documented, but in addition to documenting them we have to tell
people not to use them.
Loosemore says:
I'd rather get rid of these things entirely too, but I have previously
noted some resistance to the idea from others. Maybe they've changed
their minds by now. Anyway, if we can't agree to delete them now,
deprecation is better than the current situation.
-------
∂02-Nov-89 1012 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:12:31 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA15646; Thu, 2 Nov 89 09:22:30 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17320; Thu, 2 Nov 89 09:22:27 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911021622.AA17320@defun.utah.edu>
Date: Thu, 2 Nov 89 09:22:25 MST
Subject: issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES, version 2
To: x3j13@sail.stanford.edu
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES
References: DEFSTRUCT; CLtL p. 309
Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (passed)
Category: CLARIFICATION, CHANGE
Edit History: V1, 11 Oct 1989, Sandra Loosemore
V2, 02 Nov 1989, Sandra Loosemore (update discussion)
Problem Description:
Must the symbols which name DEFSTRUCT slots be bound as lambda
variables by the default keyword constructor function? Normally it
would not matter, but if any of these symbols have been proclaimed
SPECIAL it will affect the dynamic environment in which the slot init
forms are evaluated.
There are three proposals, BOUND, NOT-BOUND, and VISIBLY-BOUND.
Background:
CLtL requires each default slot init form to be evaluated "in the
lexical environment of the DEFSTRUCT form in which it appeared". This
means that the obvious technique of supplying the init forms as the
defaults for the keyword arguments in the lambda list of the
constructor function is incorrect, unless care is taken to avoid
shadowing any variable bindings of the symbols which correspond to
those arguments.
For example, given
(defstruct foo
(a <a-init>)
(b <b-init>)
(c <c-init>))
Generating the constructor as
(defun make-foo (&key (a <a-init>) (b <b-init>) (c <c-init>)) ...)
may not evaluate <b-init> and <c-init> in the correct lexical environment
as specified in CLtL. Proposal VISIBLY-BOUND would change the specification
to make this the correct behavior.
One alternative is to wrap the init forms in closures named with gensyms:
(flet ((#:g1 () <a-init>)
(#:g2 () <b-init>)
(#:g3 () <c-init>))
(defun make-foo (&key (a (#:g1)) (b (#:g2)) (c (#:g3))) ...))
Under proposal BOUND, this would be the correct way to implement the
constructor function.
Another alternative is to make the lambda variables themselves gensyms:
(defun make-foo (&key ((:a #:g4) <a-init>)
((:b #:g5) <b-init>)
((:c #:g6) <c-init>)) ...)
Under proposal NOT-BOUND, this would be the correct way to implement the
constructor function.
(Of course, it's possible that DEFSTRUCT could produce a simplified
expansion in many cases by examining the init forms and/or lexical
environment.)
Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE implies that BOA constructors
do bind the symbols which name slots as lambda variables, since these
variables can be referenced in the init forms for subsequent
arguments.
Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:BOUND):
Clarify that the symbols which name slots must be bound as lambda
variables by the keyword constructor function, in the order in which
the slots are specified in the DEFSTRUCT form. Variables for
inherited slots are bound before variables for explitly specified
slots, in the order in which they were specified in the definition of
the inherited structure. Special bindings of these variables will be
visible during the evaluation of the default init forms for subsequent
slots. The slot default init forms are still evaluated in the
lexical environment in which the DEFSTRUCT form itself appears.
Rationale:
This appears to be closest to the intent of CLtL.
Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:NOT-BOUND):
Clarify that the symbols which name slots must *not* be bound as
lambda variables by the keyword constructor function. The slot
default init forms are evaluated in the lexical environment
in which the DEFSTRUCT form itself appears and the dynamic environment
in which the call to the constructor function appears.
Rationale:
This avoids the overhead of creating and invoking closures to compute
the default values of the slots for the default keyword constructor.
Proposal (DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES:VISIBLY-BOUND):
Clarify that the symbols which name slots must be bound as lambda
variables by the keyword constructor function, in the order in which
the slots are specified in the DEFSTRUCT form. Variables for
inherited slots are bound before variables for explitly specified
slots, in the order in which they were specified in the definition of
the inherited structure. Special bindings of these variables will be
visible during the evaluation of the default init forms for subsequent
slots.
Remove the requirement that the slot default init forms be evaluated
in the lexical environment in which the DEFSTRUCT form itself appears.
Instead, require that they be evaluated in a lexical environment that
contains bindings for the previous lambda variables of the constructor
function. This applies to both the default keyword constructor function
and BOA constructors.
Rationale:
This alternative corresponds most closely to current practice. It
avoids the overhead of creating and invoking closures to compute the
default values of the slots for both the default keyword constructor
and BOA constructors.
Example/Test Cases:
(defvar x 'global-x)
(let ((y 'local-y))
(defstruct baz (x 'x-init) (y x) (z y)))
(make-baz)
Under proposal BOUND,
slot X is initialized to X-INIT
slot Y is initialized to X-INIT
(since the init form X is evaluated in the dynamic environment
containing the binding to X-INIT)
slot Z is initialized to LOCAL-Y
(since the init form Y is evaluated in the lexical environment in
which the DEFSTRUCT appears)
Under proposal NOT-BOUND,
slot X is initialized to X-INIT
slot Y is initialized to GLOBAL-X
(since the constructor does not rebind the special variable X)
slot Z is initialized to LOCAL-Y
Under proposal VISIBLY-BOUND,
slot X is initialized to X-INIT
slot Y is initialized to X-INIT
(since the special binding of X made by the constructor is visible)
slot Z is initialized to X-INIT
(since the lexical binding of Y made by the constructor is visible)
Current Practice:
Most implementations (including Lucid CL, HPCL-I, KCL, CMU Common Lisp)
appear to implement proposal VISIBLY-BOUND even though it is in conflict
with what is required by CLtL.
Utah Common Lisp currently implements proposal NOT-BOUND.
Cost to implementors:
For proposal BOUND, the cost of implementing the proposal correctly is
fairly small. The cost of implementing it both correctly and efficiently
is potentially much larger.
For proposal NOT-BOUND, the implementation cost is again fairly small,
but it still requires essentially the same work as in proposal BOUND to
handle BOA constructors correctly.
Proposal VISIBLY-BOUND has the least implementation cost, since this
is what most implementations already do and is the least complicated
of the alternatives.
Cost to users:
Adopting any of these proposals would improve the situation faced by
users now.
Users may find proposal VISIBLY-BOUND to be marginally more useful
than the other alternatives since it allows the values of slots to be
referenced in the subsequent default init forms.
Benefits:
An area of confusion in the language is removed.
Discussion:
Loosemore doesn't care much about which of these alternatives we
adopt, but thinks that leaving this unspecified would be a mistake.
Margolin says:
By the way, I prefer this proposal [NOT-BOUND]. I think lexical
environments should be captured (I think we've fixed everything so
that init-forms are always evaluated in the appropriate lexical
environment), but I don't like making the order of slots significant
by allowing init forms to reference other slots. Order of slots is
often constrained by other requirements (such as the :INCLUDE
hierarchy, or using :TYPE to match a pre-existing structure), so they
shouldn't have an effect on the semantics of the structure.
Moon says:
Surely the default constructor function and "BOA constructors" must work
compatibly. Unspecified initforms for optional and keyword arguments in
a "BOA constructor" default from the slot initform rather than NIL, so
"BOA constructors" face the same issue as default constructors.
VISIBLY-BOUND seems semantically wrong.
I would go with BOUND, assuming we can't just get rid of DEFSTRUCT
entirely. I don't care about the supposed efficiency issue, which is
easily gotten around or ignored.
-------
∂02-Nov-89 1035 X3J13-mailer RE: whitespace after macros
Received: from atc.boeing.com ([130.42.28.80]) by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:22:25 PST
Received: by atc.boeing.com on Thu, 2 Nov 89 09:22:48 PST
Date: Thu, 2 Nov 89 09:26 PST
From: Stephen Nicoud <snicoud@atc.boeing.com>
Subject: RE: whitespace after macros
To: moore%cdr@cs.utah.edu, X3J13@sail.stanford.edu
Supersedes: <19891101203528.8.SLN@SKAGIT.atc.boeing.com>
Message-Id: <19891102172631.5.SLN@SKAGIT.atc.boeing.com>
From: moore%cdr@cs.utah.edu (Timothy B. Moore)
Date: 1 Nov 89 01:09:03 GMT
CLtL and section 3.2 of the Working Draft are quite specific about
what happens to whitespace after a token, but neither say anything
about whitespace after macro characters. Step 4 of the state machine
on pg 335 of CLtL implies that no characters of any kind are looked
at after a character macro function returns. However 2
implementations, HPCL I and Lucid, appear to eat the whitespace
character after a terminating macro character.
Is this addressed in any other part of the Standard? Should it be specified?
Tim
I have run across differences in the behavior of READ in various
implementations (Symbolics vs. Explorer and Lucid).
Here's an example:
Assume a file ("my-file.lisp") with only this one line:
(a) (b)(c) (d)
;; Now, I OPEN the file ...
> (setq my-file-stream (open "my-file.lisp" :element-type 'string-char))
#<STREAM "my-file" blah... blah>
;; and do a READ.
> (read my-file-stream)
(A)
;; When I next do a FILE-POSITION on my-file-stream here are the results:
> (file-position my-file-stream)
;; Symbolics
3
;; Explorer and Lucid
4
> (read my-file-stream)
(B)
> (file-position my-file-stream)
;; Symbolics, TI, and Lucid
7
> (read my-file-stream)
(C)
> (file-position my-file-stream)
;; Symbolics
10
;; Explorer and Lucid
11
> (close my-file-stream)
NIL
∂02-Nov-89 1036 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 2 Nov 89 10:33:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 686279; 2 Nov 89 13:32:07 EST
Date: Thu, 2 Nov 89 13:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-COMPILER-MACRO, version 3
To: x3j13@sail.stanford.edu
In-Reply-To: <8910241949.AA08819@defun.utah.edu>
References: <6v83R@SAIL.Stanford.EDU>,
<8907190732.AA03107@masunter.parc.xerox.com>,
<8907140203.AA07138@defun.utah.edu>,
<19890713224024.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<8907131922.AA16436@bhopal>,
<8907131729.AA06791@defun.utah.edu>,
<8907131656.AA13108@verdi.think.com>,
<8907131702.AA07543@clam.sun.com>,
<19890713160237.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<Bs705@SAIL.Stanford.EDU>,
<8907122158.AA06269@defun.utah.edu>,
<8907122134.AA14129@bhopal>,
<19890712210002.4.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<8907121724.AA06070@defun.utah.edu>,
<jrXeM@SAIL.Stanford.EDU>,
<RrXSX@SAIL.Stanford.EDU>,
<8907121619.AA06014@defun.utah.edu>,
<8907120307.AA05623@defun.utah.edu>,
<8907120122.AA12092@bhopal>,
<8907112354.AA02537@aurora.Franz.COM>,
<8907112003.AA05354@defun.utah.edu>
Message-ID: <19891102183214.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have carefully re-read the referenced mail on this topic (mostly from
July) and I believe that DEFINE-COMPILER-MACRO:FIX-BUGS, version 3,
correctly addresses all the issues raised in that mail. I see two
remaining issues and one problem.
1. It is not made clear whether a compiler macro can be defined only for
the name of a function, or also for the name of a macro or of a special
form. I believe the intent was that a compiler macro can be defined for
any symbol, except the user can't define one for a Common Lisp defined
name that names a function, macro, or special form. The implementation
could define a compiler macro that shadows a special form. An
implementation that allows users to define special forms in their own
package (as an extension) would have to allow users to shadow their
special forms with compiler macros. I would like to see the proposal
clarified to state explicitly that a compiler macro can be defined for
any symbol (other than the ones ruled out in point 4). Of course there
is no guarantee that a language processor will ever call a compiler
macro.
2. There doesn't seem to have been any coordination with the FUNCTION-NAME
proposal. A couple of places in the writeup, although not the description
of DEFINE-COMPILER-MACRO itself, say the name has to be a symbol. It seems
legitimate to me to define a compiler-macro for a SETF function, so I would
like to see the proposal extended to allow the name of a compiler macro to
be any function-name (rather than any symbol) except for those function-names
(including SETF names) that are defined as operator names by the Common Lisp
language.
3. Although Sandra's version 3 writeup satisfactorily addresses the issues
as a cleanup proposal, it is not in a form that is any use as part of the
draft language specification document. Someone's going to have to write
that stuff. Currently there are no writeups for the macro and three functions
added by the proposal, and the writeups in the evaluation and compilation
sections (pages 4-8 and 4-34) are rather a mess and not completely consistent
with this cleanup proposal, so they will need to be reworked. Because the
cleanup issue is so far from the form needed in the document, there is room
for ambiguity, or variation from what people thought, perhaps incorrectly,
they were voting for, during that writing. I have no good suggestion for
this except that if anyone is a fast writer perhaps they could bring a
first draft to the meeting next week.
∂02-Nov-89 1159 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 2 Nov 89 11:59:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 686365; 2 Nov 89 14:58:19 EST
Date: Thu, 2 Nov 89 14:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-COMPILER-MACRO, version 3
To: x3j13@sail.stanford.edu
In-Reply-To: <19891102183214.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19891102195835.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Clarification:
Date: Thu, 2 Nov 89 13:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
....the writeups in the evaluation and compilation
sections (pages 4-8 and 4-34) are rather a mess and not completely consistent
with this cleanup proposal, so they will need to be reworked.
This comment refers specifically to the paragraphs on compiler macros, not to
the entire sections containing them. I have not read section 4.2 at all yet,
except for the one part about compiler macros, and I'm still going through
section 4.1.
∂02-Nov-89 1552 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Nov 89 15:52:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA03947; Thu, 2 Nov 89 16:51:56 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17806; Thu, 2 Nov 89 16:51:52 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911022351.AA17806@defun.utah.edu>
Date: Thu, 2 Nov 89 16:51:51 MST
Subject: Re: issue DEFINE-COMPILER-MACRO, version 3
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: x3j13@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 2 Nov 89 13:32 EST
> Date: Thu, 2 Nov 89 13:32 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> 1. It is not made clear whether a compiler macro can be defined only for
> the name of a function, or also for the name of a macro or of a special
> form. I believe the intent was that a compiler macro can be defined for
> any symbol [...]
I agree that this was the intent.
> 2. There doesn't seem to have been any coordination with the FUNCTION-NAME
> proposal. A couple of places in the writeup, although not the description
> of DEFINE-COMPILER-MACRO itself, say the name has to be a symbol. It seems
> legitimate to me to define a compiler-macro for a SETF function, so I would
> like to see the proposal extended to allow the name of a compiler macro to
> be any function-name (rather than any symbol) except for those function-names
> (including SETF names) that are defined as operator names by the Common Lisp
> language.
This change seems reasonable in itself but would be inconsistent with
the goal of being "just like" DEFMACRO. We voted down the items (7,
8, and 9) in issue FUNCTION-NAME that would have extended DEFMACRO
syntax to accept function-name arguments. If you think it is really
important to have DEFINE-COMPILER-MACRO work on function-names and not
just symbols, I think this would be better handled by considering this
separately as an amendment to issue FUNCTION-NAME, since I would
rather extend DEFMACRO than break the similarity between DEFMACRO and
DEFINE-COMPILER-MACRO.
Reading issue FUNCTION-NAME over again, items 7 and 8 don't seem so
awful to me but item 9 is clearly wrong; you can't expect FBOUNDP,
FDEFINITION, etc to return local function definitions (which don't
exist until run-time) from a compile-time syntactic environment.
> 3. Although Sandra's version 3 writeup satisfactorily addresses the issues
> as a cleanup proposal, it is not in a form that is any use as part of the
> draft language specification document. Someone's going to have to write
> that stuff.
Yes, this is a problem. When I initially wrote up version 3, I
thought about doing a complete rewrite as you suggest, but I
eventually decided that if I did that, people would have a hard time
identifying what exactly I was proposing to add or change, and why. I
also thought that formatting my new proposal as a list of amendments
to the previous version would make things easier procedurally at the
meeting, in case people want to vote on the items individually.
I'm willing to work on the writeup, but I'm not going to have time to
do it before the meeting.
-Sandra
-------
∂02-Nov-89 1629 X3J13-mailer re: issue DEFINE-COMPILER-MACRO, version 3
To: sandra%defun@CS.UTAH.EDU, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from sandra%defun@cs.utah.edu sent Thu, 2 Nov 89 16:51:51 MST.]
> 1. It is not made clear whether a compiler macro can be defined only for
> the name of a function, or also for the name of a macro or of a special
> form. I believe the intent was that a compiler macro can be defined for
> any symbol [...]
I agree that this was the intent.
I'm not sure this was the intent, though it seems plausible. The original
motivation was to be able to provide a mechanism that would replace what
would appear to a function call with some other form, much as some compilers
currently operate. The key element of the proposal is that the compiler
might choose to ignore the expansion, which means that the original form
must be meaningful.
I believe that during our discussion of the issue, functions as the other
designation was considered mostly, but the possibility of macros was
mentioned. Special forms never happened to come up since we don't have
a way to define them and you cannot screw with the builtin special forms.
That is, I think the original intent was for functions only.
We can decide to change the proposal to include these possibilities, but
in describing the functionality of compiler macros in the draft, the best
way to handle the description of the expanded proposal is to not mention
that which the name of a particular compiler macro must designate, only that
it must always designate something else in a conforming program.
-rpg-
∂02-Nov-89 1755 X3J13-mailer issue DEFINE-COMPILER-MACRO, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Nov 89 17:55:20 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA19352g; Thu, 2 Nov 89 17:51:29 PST
Received: by bhopal id AA15426g; Thu, 2 Nov 89 17:53:21 PST
Date: Thu, 2 Nov 89 17:53:21 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911030153.AA15426@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 2 Nov 89 13:32 EST <19891102183214.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DEFINE-COMPILER-MACRO, version 3
re: I believe the intent was that a compiler macro can be defined for
any symbol, except the user can't define one for a Common Lisp defined
name that names a function, macro, or special form.
Yes, that was stated clearly in the original proposal. [Sigh, side point:
the problem with issues presented "on the fly" is that there is no
electronic history on them, and I'm sure there are spurious nits between
the slides presented in Palo Alto and the version that Sandra finally
managed to type in]. Here is the text from the current version:
The issue LISP-SYMBOL-REDEFINITION precludes user definition of any
compiler macros for symbols external in the Lisp package that have a
definition as a function, macro, or special form.
So I'm completely confused now since Sandra's proposed emmendations say:
(4) Clarify that issue LISP-SYMBOL-REDEFINITION does not, in fact,
prohibit user definition of compiler macros for symbols in the
common-lisp package. . . .
What is needed to be "clarified"? Your "belief" expressed above seems
to be an exact duplicate of the original proposal wording.
re: ... FUNCTION-NAME proposal.
Sure. If DEFMACRO does it, then DEFINE-COMPILER-MACRO has to also.
re: Of course there is no guarantee that a language processor will ever
call a compiler macro.
Well, foo, this is indeed counter to the proposal that was passed in
June. It's not a super-critical point, but it certainly breaks the
symmetry with macros if compiler-macros are degraded to the optionality
of declarations [Sandra's first proposed amendment specifically
makes this analogy]. Both RPG and I remember an explicit statement
in either the original, or in the verbal discussion before the vote,
that the compiler had to do the expansion; and that the compiler
might or might not substitute the expansion for the original source
based purely on other compilation constraints such as NOTINLINE,
optimization qualities, etc. -- time-of-day, phase-of-moon, and
other implementor whims don't count here.
In fact, I think the more serious problem that "fell through the cracks"
is that of resolving the competing hiearchy for expansions during
compilation. That is, what do you do if a symbol has both a compiler
macro and a regular macro? Is it permissible for an implementation to
support a special-form with a compiler macro (Answer must be yes, right?).
RPG and I though the order of dominance ought to be something like:
Common-Lisp-Magic-Symbols [such as IF, EQUAL, . . . ]
Interpreter and/or compiler may or may not process "magically".
When there is no special "magic", proceed to the alternatives
mentioned below.
Compiler-Macros
Interpreter must ignore; Compiler must expand. Compiler *may*
substitute the result in place of the original source, or it might
ignore the result and proceed to the alternatives mentioned below.
Macros
Interpreter and Compiler will expand, and substitute the result
for the original source.
Nothing Else More Specific [i.e., Function-Call]
Interpreter will "call the named function"; Compiler will "compile"
a call to the named function.
-- JonL --
∂03-Nov-89 0440 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Nov 89 04:40:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA01031; Fri, 3 Nov 89 05:40:39 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA17946; Thu, 2 Nov 89 22:05:46 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911030505.AA17946@defun.utah.edu>
Date: Thu, 2 Nov 89 22:05:45 MST
Subject: Re: issue DEFINE-COMPILER-MACRO, version 3
To: Jon L White <jonl@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
x3j13@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Thu, 2 Nov 89 17:53:21 PST
Just a few quick comments:
> Date: Thu, 2 Nov 89 17:53:21 PST
> From: Jon L White <jonl@lucid.com>
>
> (4) Clarify that issue LISP-SYMBOL-REDEFINITION does not, in fact,
> prohibit user definition of compiler macros for symbols in the
> common-lisp package. . . .
> What is needed to be "clarified"?
This is something GLS pointed out. The original wording in the
DEFINE-COMPILER-MACRO:NEW-FACILITY proposal claimed that
LISP-SYMBOL-REDEFINITION said something that it really didn't.
> In fact, I think the more serious problem that "fell through the cracks"
> is that of resolving the competing hiearchy for expansions during
> compilation. That is, what do you do if a symbol has both a compiler
> macro and a regular macro?
I thought that the wording of proposal DEFINE-COMPILER-MACRO:NEW-FACILITY
was clear enough that the intent was for a compiler macro had
precedence over everything else, including ordinary macros:
When the compiler is about to compile a nonatomic form, it first calls
COMPILER-MACROEXPAND-1 repeatedly until there is no more expansion
(there might not be any to begin with). Then it continues its
remaining processing, which may include calling MACROEXPAND-1 etc.
I think the only detail that is missing is an explicit statement that
the result of expanding an ordinary macro is re-examined to see if
it's another compiler macro call, but in my mind that's already
implied by "about to compile a nonatomic form".
I don't think there's any ambiguity with precedence in the remaining
situations. To summarize:
Standard CL macros and special forms may have both macro definitions and
special form definitions. It's unspecified which the compiler will use.
(CLtL p 57)
Macro calls must be expanded by the compiler. (CLtL p143)
Anything that's not known to be a macro or special form is treated as
a function call. A name can't be bound to both a macro or special
form definition, and to a function definition at the same time.
(CLtL p. 57, 58, 90)
-Sandra
-------
∂03-Nov-89 1343 X3J13-mailer issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES, version 2
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Nov 89 13:43:37 PST
Received: from challenger ([192.9.200.17]) by heavens-gate id AA25236g; Fri, 3 Nov 89 13:40:36 PST
Received: by challenger id AA03316g; Fri, 3 Nov 89 13:42:13 PST
Date: Fri, 3 Nov 89 13:42:13 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8911032142.AA03316@challenger>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 2 Nov 89 09:22:25 MST <8911021622.AA17320@defun.utah.edu>
Subject: issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES, version 2
I remember that I had to re-implement some non BOA constructors from
VISIBLY-BOUND style to NOT-BOUND style because some Explorer customer had a
number of slot that was greater than LAMBDA-PARAMETERS-LIMIT. In this case, I
had to resort to a &rest parameter style. This has to be clear that anything
except NO-BOUND will require structures to have a number of slots lower than
LAMBDA-PARAMETERS-LIMIT.
Patrick.
∂03-Nov-89 1551 X3J13-mailer Re: issue DEFINE-COMPILER-MACRO, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 3 Nov 89 15:51:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 687236; 3 Nov 89 18:50:37 EST
Date: Fri, 3 Nov 89 18:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINE-COMPILER-MACRO, version 3
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: x3j13@sail.stanford.edu
In-Reply-To: <8911022351.AA17806@defun.utah.edu>
Message-ID: <19891103235046.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 2 Nov 89 16:51:51 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Thu, 2 Nov 89 13:32 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 2. There doesn't seem to have been any coordination with the FUNCTION-NAME
> proposal. A couple of places in the writeup, although not the description
> of DEFINE-COMPILER-MACRO itself, say the name has to be a symbol. It seems
> legitimate to me to define a compiler-macro for a SETF function, so I would
> like to see the proposal extended to allow the name of a compiler macro to
> be any function-name (rather than any symbol) except for those function-names
> (including SETF names) that are defined as operator names by the Common Lisp
> language.
This change seems reasonable in itself but would be inconsistent with
the goal of being "just like" DEFMACRO.
I don't believe that DEFINE-COMPILER-MACRO is "just like" DEFMACRO in
all ways, only in some ways. I think where the original proposal says
"This is just like DEFMACRO except..." that means it has the same kind
of lambda-list and return value that DEFMACRO has. As JonL pointed out
in a recent message, it's unfortunate the way this issue got written at
the last minute without adequate text editing facilities. The original
writeup (DEFINE-OPTIMIZER version 6) said the same thing in considerably
more precise English, presumably because there was a lot more time
available to work on the wording. By now we've wasted far more time
being confused by hasty wording than it would have taken to tighten up
the wording in the first place.
Certainly how the expansion of a compiler-macro gets used is quite
different from a normal macro; a macro is always expanded but expansion
of a compiler-macro is at the language processor's option. Even more to
the point, how a programmer uses a compiler-macro is very different from
how a programmer uses a regular macro. One uses a regular macro to
extend the syntax of the language. It is impossible to use a
compiler-macro to extend the syntax of the language. The only thing one
can use compiler-macros for (unless there is some clever trick I haven't
thought of) is to do more extensive inlining than INLINE declarations
do; in particular error checking can be removed, keyword arguments can
be changed into positional arguments, and optimizations based on type
inference can be done. Note that these are all things that compilers
do. Really, I don't think a compiler-macro can do anything that a
compiler could not do itself if it felt like doing it. The reason we
have compiler macros is as a structured, portable way to extend the
compiler so that people will be better able to use the less than perfect
compilers that exist in the real world. The reason we don't require the
compiler to pay attention to compiler macros, and leave it to market
forces, is the same reason we don't require the compiler to pay
attention to inline declarations.
The fact that how a programmer uses a compiler-macro is very different
from how a programmer uses a regular macro is what makes me think it
makes sense to define a compiler macro for any function name, including
SETF functions, even though it's not necessary to be able to define a
regular macro for anything but a symbol. I might want to optimize
(setf (helmet-size person) (computation)) to not actually call the
(setf helmet-size) generic function in some circumstances. If I can't
do that with a compiler macro, I have to play some kind of naming games,
such as calling the generic function setf-helmet-size, making a
compiler macro for that, and doing a define-setf-method to tell setf
what to do. Then when I define methods and slots I have to know
about the nonstandard name setf-helmet-size. This is silly, either
we shouldn't have compiler macros at all or they should work for all
function names.
I wish we had left these things' name "optimizers" instead of "compiler
macros." Upon re-reading the discussion, I sense that the name
"compiler macro" is confusing some of us into thinking these things are
more like regular macros than they really are. I guess I will leave
that as a wistful wish rather than a proposed amendment, since I do not
wish to waste time.
We voted down the items (7,
8, and 9) in issue FUNCTION-NAME that would have extended DEFMACRO
syntax to accept function-name arguments. If you think it is really
important to have DEFINE-COMPILER-MACRO work on function-names and not
just symbols, I think this would be better handled by considering this
separately as an amendment to issue FUNCTION-NAME, since I would
rather extend DEFMACRO than break the similarity between DEFMACRO and
DEFINE-COMPILER-MACRO.
Reading issue FUNCTION-NAME over again, items 7 and 8 don't seem so
awful to me but item 9 is clearly wrong; you can't expect FBOUNDP,
FDEFINITION, etc to return local function definitions (which don't
exist until run-time) from a compile-time syntactic environment.
To review, 7 was to allow forms like ((setf foo) new-value bar), 8 was
to allow (defmacro (setf foo) ...) and also change MACROLET and
MACRO-FUNCTION, and 9 was to add an optional environment argument to
FDEFINITION, SETF of FDEFINITION, FBOUNDP, and FMAKUNBOUND.
9 was pretty well superseded by SYNTACTIC-ENVIRONMENT-ACCESS. I do not
want to reopen 7 and 8, since I don't think compiler-macros are the same
thing as macros. I agree that the interaction of DEFINE-COMPILER-MACRO
and FUNCTION-NAME could be discussed under the rubric of either issue
name.
While comparing the DEFINE-COMPILER-MACRO and DEFINE-OPTIMIZER proposals
I found another nit to pick, by the way: the DEFINE-COMPILER-MACRO
proposal says the compiler-macro has a documentation string, but it
doesn't modify the DOCUMENTATION function to provide a way to retrieve
that string.
∂03-Nov-89 2148 X3J13-mailer re: issue DEFINE-COMPILER-MACRO, version 3
To: sandra%defun@CS.UTAH.EDU, jonl@LUCID.COM
CC: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
sandra%defun@CS.UTAH.EDU, x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
[In reply to message from sandra%defun@cs.utah.edu sent Thu, 2 Nov 89 22:05:45 MST.]
Sandra writes:
I don't think there's any ambiguity with precedence in the remaining
situations. To summarize:
Standard CL macros and special forms may have both macro definitions and
special form definitions. It's unspecified which the compiler will use.
(CLtL p 57)
Macro calls must be expanded by the compiler. (CLtL p143)
Anything that's not known to be a macro or special form is treated as
a function call. A name can't be bound to both a macro or special
form definition, and to a function definition at the same time.
(CLtL p. 57, 58, 90)
-Sandra
-------
The first point is subject to the cleanup that passed named
LISP-SYMBOL-REDEFINITION. If there are such user definitions of symbols
external to the package COMMON-LISP, the results are undefined.
Of course, a particular implementation can use compiler macros to
implement compiled functionality in the COMMON-LISP package, and
some can allow users to redefine these symbols.
-rpg-
∂04-Nov-89 0027 X3J13-mailer evaluating CLOS performance
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Nov 89 00:27:10 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA02879g; Sat, 4 Nov 89 00:23:33 PST
Received: by bhopal id AA01188g; Sat, 4 Nov 89 00:25:16 PST
Date: Sat, 4 Nov 89 00:25:16 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911040825.AA01188@bhopal>
To: Gregor.pa@Xerox.COM
Cc: CommonLoops.pa@Xerox.COM, X3J13@Sail.Stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 31 Oct 89 19:35 PST <19891101033501.1.GREGOR@SPIFF.parc.xerox.com>
Subject: evaluating CLOS performance
As someone who has been trying to improve lisp compiler performance
to help CLOS and PCL, I can well sympathize with your analysis of
the complexity in evaluating CLOS performance. While acting as one
of Dick Gabriel's correspondents on the Lisp Timings project (whence
came the book "Performance and Evaluation of Lisp Systems), I many
times saw the tendency of people to pick one facet of a 1000-facet
system and focus in on it as THE measure. [Of course, when several
facets have wildly differing values, one can seldom find a single
statistical summary of them that is satisfactory to every end user.]
CLOS _by itself_ is at least as complex as the Lisp systems that
Dick benchmarked, and will no doubt be as difficult to summarize
succinctly as any other such system.
The serious question, however, is that of trying to relate micro
performance measures to predictions of macro behaivour. For example,
by speeding up the generic-function call overhead, how much will a
typical application be speeded up? Overlooking for a moment just
what "typical" means, I will present some experimental data below,
gathered by a kind of perturbation analysis technique, that will
show a few surprising results.
But first, let me say that I very much liked your illustration with the
various kinds of accessor forms -- defstruct's versus Standard-Object
instance access. You stress the right principle -- that of comparing
equivalent functionalities ("apples with apples rather than with oranges").
However, I'm sure you must have made a typo in the defmethod definition:
(defmethod meth ((b bar))
(slot-value *bar* 'a) ;Form 4
(bar-a *bar*)) ;Form 5
Surely you must have meant:
(defmethod meth ((b bar))
(slot-value b 'a) ;Form 4
(bar-a b)) ;Form 5
Right? since the latter is the one that the compiler can optimize.
More to the point, I sense an undercurrent of urgency on your part to
defend PCL's performance. I realize that many people will assess the
inherent capabilities of CLOS from a casual inspection of PCL's present
abilities, and it's important to put a good foot forward. But I also
think it's important to properly assess the complaints against PCL, so
as not to waste time solving interesting, but only secondarily relevant,
problems.
First off, let me say that I think recent PCL's have been outstanding
in many areas of performance. For example, the "Best Case"
performance of simple generic-function calls really is pretty good.
I say "recent PCL's", because two years ago, the picture wasn't quite
so optimistic [furthermore, I ocasionally still see comparisons of
such-and-such a CLOS with PCL circa early 1987, so I know they aren't
completely forgotten].
PCL's Speed of Generic-Function Calling
Despite the basically good performance, several sorts of complaints
have come up against even the most recent release (Victoria-Day).
Patrick Dussud's OOPSLA conference paper compared PCL versus a native
CLOS implementation on a TI Explorer and found that the speed, under
PCL, of a accessor generic-function on a local slot was within a factor
of two for that for the native CLOS (actually, not bad at all, given
that the "P" in PCL means "Portable", and doesn't have microcode hacks
to speed it up); however, the speed of an accessor generic-function
for a shared slot was TWO ORDERS OF MAGNITUDE worse!
What conclusion could be drawn from this? That PCL is "just about"
as fast as the best possible on the Explorer? That it is 77.9 times
slower? that it is (2.2 + 77.9)/2 = 40 times slower? No, I think we
could all recognize that shared-slot access is simply an area of PCL
that hasn't yet had much development. Those of us familiar with the
internals will also readily agree that optimizing it to about the same
level as local slot access isn't at all a hard problem.
Also in recent times, some researchers reported to this electronic
distribution list an incalculable time sink that can occur when a
development loop has the unfortunate experience of causing the
"invalidation" of some generic function being frequently called
(via NOTICE-METHODS-CHANGE). Effectively, each call to the function
results in a re-calculation of ALL of the effective methods on the
function, which can take arbitrarily long since it is at least quadratic
in the number of methods. The generic function "overhead" there might
look like it is orders and orders of magnitude. Again, this appears
simply to be a lack of development, since incremental invalidation is
a concept already proven in other implementations.
Finally, some results of trials I performed on the (in)famous CARWASH
benchmark (partially reproduced below) show that in some reasonable
situations, important generic-functions will wind up going out of line
(to DCODE-CACHE-MISS) even though the items are in the cache. The
slow-down at the generic-function-call overhead level is an order of
magnitude. It may not be the common case, but it is one that doesn't
require extreme contortions to fall into. This too could be easy to fix.
What's the point of listing these negative results? definitely not to
tarnish the reputation of PCL/CLOS! As I've already stated, I think
it has some excellent "best case" situations, and clearly a lot of
useful work can be done staying within those bounds. Rather, what I
hope to point out is that the public view concerning the "inherent"
capabilities of CLOS (or PCL) may be more negatively affected by these
horror stories about orders of magnitude slowdown than by a measured 10%
or 20% inefficiency in an already good case (the basic generic funcall).
Speed of Compiled FUNCALL's In The Supporting Lisp
It's interesting that you picked declarations for FUNCALL to illustrate
potential bottlenecks in the development of generic-function call. Just
two weeks ago, Bob Boyer sent out a lengthy note to the KCL distribution
list about performance improvements in AKCL that depend on having the
compiler notice several things about the context of a FUNCALL:
Date: Wed, 18 Oct 89 18:49:45 CDT
From: boyer@rascal.ics.UTEXAS.EDU (Bob Boyer)
To: kcl@cli.com
Subject: Funcall Speed-Up
Appropriate declarations and proclamations can definitely increase
execution speed in KCL and AKCL.
. . . There are two
conditions that must both be met to obtain the higher speed funcall.
First, the funcall must be of a function that has been proclaimed to
be a function that returns a single value. Second, the textual
occurrence of the funcall must reveal that the funcall does not return
multiple values by satisfying one of three conditions: (i) the value
of the funcall is ignored, e.g., it is a nonfinal member of a progn,
(ii) the funcall occurs as the second arg of a SETQ, or (iii) the
funcall occurs as the second arg of a THE whose first arg is (VALUES
T), declaring that only one value is returned.
. . .
I guess you haven't seen this one yet, since the requisite declarations
(and context) are much more complex than simply a COMPILED-FUNCTION
declaration as shown in your test form:
(defmacro |RUNTIME FUNCALL| (fn &rest args)
`(funcall (the compiled-function ,fn) ,.args))
Boyer's subsequent numbers showed that, with the proper declarations
etc., a FUNCALL in AKCL is only about 30% slower than the minimal
function-to-function call time. However, _without_ those declarations,
the FUNCALL time is over a factor of 6 slower!
I'm sure that an improvement of a factor of 6 at this "micro" level
is good news to AKCL users. The question of how important the 30%
difference is -- the overhead, if you will, for using FUNCALL at all
-- is more difficult to answer. Although it is usually very hard
to predict macro performance from micro benchmarks, I have some data
(see below) that tends to show even a 30% differential in the generic-
function call overhead weighs in down at the "noise" level in a typical
application. This is not at all to say that removing a 30% cost from
a micro component isn't a reasonable thing to do (especially if it
doesn't cost anything to do so); but rather that in the overall picture
of things, there may be other more important optimizations to be done
first. Remember the point above about the orders-of-magnitude stories
being more damaging than tales of a few percentage points off in the
already good case.
Since Boyer asked how other implementations treated FUNCALL, I sent
him a reply for Lucid Common Lisp. You may find it informative now:
Date: Fri, 20 Oct 89 04:42:46 PDT
From: Jon L White <jonl>
Subject: Funcall Speed-Up
First, Lucid's implementation is such that there is practically no
performance difference between doing:
(setq foo #'mumble)
(funcall foo ...)
and:
(mumble ...)
The only difference is the runtime certification that 'foo' holds a
compiled-function (in the FUNCALL case). At the very micro level this
might be an effect varying between 8% and 24% depending on alignment of
the instruction cache (one must always be cognizant of the pitfalls of
"micro" benchmarking!) This cost could be elided if the user would insert
a declaration like:
(funcall (the procedure foo) ...)
but that capability isn't in the current product.
Lucid's "Production" compiler has long taken cognizance of the calling
context of both forms -- (mumble ...) as well as (funcall foo ...) --
and elides any extra work that multiple-value returns would cause when
the call form is in a "1-return-value-wanted" or "dont-care" situation.
Furthermore, there is usually only a minimal cost when multiple return
values are being "spread-out" as in a multiple-value-bind etc.
The type-checking estimate of between 8% and 24% is for an MC68020 --
apparently the on-chip instruction cache can really play havoc with an
attempt to get a single time for such a short instruction sequence.
Although other ports may differ, they will all eventually support a
SYS:PROCEDURE declaration such as is in some of the 68K versions.
[However this capability *might* not be exported to the end user until
the integration of the X3J13 proposal which simplifies the FUNCTION type,
in which case a FUNCTION declaration will be the documented way to provide
that information.]
Estimating Macro Performance From Micro Benchmarks:
FUNCALL's Contribution to Generic-Function Overhead
In general, this seems to be a very difficult task. It may seem like
an even harder problem, by comparison, because it is so easy to
disassemble the "micro" level code and analyze it by counting
instructions or memory cycles. But there seems to be no simple way
to count up the micro pieces in a larger unit.
Nevertheless, here is a case study in projecting macro performance --
namely, figuring out what percentage of total application time is spent
in generic-function call overhead, in order to be able to predict the
relative effects of improvements to the GF-calling protocol. The
application chosen was the infamous CARWASH benchmark, since it didn't
trigger any of the known PCL bugs, and since it appeared to be fairly
intensive in generic-function calling. By buggering the discriminator
codes to always claim a cache "miss" (and by fixing dcode-cache-miss
accordingly), I caused a slowdown of roughly an order of magnitude for
the micro level (note: the micro level here is generic-function-call
overhead -- not funcall overhead, which would just be one component of
it). I did it separately for standard reader/writer dcodes and for other
generic function dcodes; here are the relative times and their effects.
"cache-miss"-slowdown ratio overall-slowdown ratio
std-reader/writers 10-to-1 2.93-to-1 (193%)
other generics 12-to-1 1.33-to-1 ( 33%)
A little grade-school algebra on these numbers leads to the conclusion
that in the normal running of the program, 21% of the time is spent in
calling accessor generic-functions, and 3% of the time is spent in
generic-function-call overheads that aren't accessors. Of course, a
moderate amount of time is spent in CONSing and other non-CLOS Lisp
operations [these runs were made in a post-3.0 Lucid Lisp running on
a Sun3/160 system.] The relevant algebra equations are:
x1 + y1 = z1 x2 + y2 = z2
10*x1 + y1 = 2.93*z1 12*x2 + y2 = 1.33*z2
'x1' is the time for accessor generic-functions, and 'x2' is the other
generic-function call overhead.
The accessor generic-function dcodes don't use FUNCALL.
A non-accessor generic-function consists of at least the ordinary
function-to-function protocol to get to the generic function, some
discrimination code, followed by a FUNCALL coding. For sake of
illustration, let's optimistically assume that the FUNCALL overhead
accounts for 1/3 of the generic-function overhead. Then in this
relatively GF-intensive benchmark, FUNCALL overhead acccounts for at
most 1/3 * 3% = 1% of the total time. Thus an improvement of a
factor of 6 in the funcall overhead might actually be noticed; but
a tweaking of 30% -- as could still be done to the improved AKCL
version -- would be down at the "noise" level of well below 1%.
-- JonL --
∂04-Nov-89 1818 X3J13-mailer [User-Extensible Compiler?]issue DEFINE-COMPILER-MACRO, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Nov 89 18:18:01 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01504g; Sat, 4 Nov 89 18:14:47 PST
Received: by bhopal id AA11509g; Sat, 4 Nov 89 18:16:41 PST
Date: Sat, 4 Nov 89 18:16:41 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911050216.AA11509@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 3 Nov 89 18:50 EST <19891103235046.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [User-Extensible Compiler?]issue DEFINE-COMPILER-MACRO, version 3
[Yes, I realize that no one will be reading this msg before the meeting
in Palo Alto this next week, but for historical purposes I will send out
this comment electronically now.]
re: . . . The only thing one
can use compiler-macros for (unless there is some clever trick I haven't
thought of) is to do more extensive inlining than INLINE declarations
do; in particular error checking can be removed, keyword arguments can
be changed into positional arguments, and optimizations based on type
inference can be done. Note that these are all things that compilers
do. Really, I don't think a compiler-macro can do anything that a
compiler could not do itself if it felt like doing it. The reason we
have compiler macros is as a structured, portable way to extend the
compiler so that people will be better able to use the less than perfect
compilers that exist in the real world. The reason we don't require the
compiler to pay attention to compiler macros, and leave it to market
forces, is the same reason we don't require the compiler to pay
attention to inline declarations.
. . .
I wish we had left these things' name "optimizers" instead of "compiler
macros." Upon re-reading the discussion, I sense that the name
"compiler macro" is confusing some of us into thinking these things are
more like regular macros than they really are.
I believe that the reason we finally did change the name from "optimizer"
to "compiler-macro" was that the name "optimizer" was confusing even more
people. Yes, we have had a bit of a trip-up with wording since the June
meeting, but don't you remember the volumes and volumes of fruitless
argumentation over optimizers? At least when we settled on compiler
macros, we could claim "current practice" from the compilers of Symbolics,
Lucid, and Franz. [and in fact, compiler macros existed well over a
decade ago in Interlisp -- CMACRO's was it? -- and I'm sure they existed
in the original Lisp's like the one on CTSS at MIT in the 1960s].
Nit time: one reason I don't like "optimizer" is that frequently mine
turn out to be "pessimizers". Let's just say (as you did) that
compiler-macros are CL's mechanism for a user-extensible compiler.
-- JonL --
∂14-Nov-89 0513 X3J13-mailer next meeting
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 14 Nov 89 05:13:41 PST
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa13290; 13 Nov 89 18:19 GMT
Date: Mon, 13 Nov 89 18:29:56 GMT
Message-Id: <1458.8911131829@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: next meeting
To: x3j13@sail.stanford.edu
Could someone please tell me when the next meeting (ie, the first
one in 1990) is? I need to know as soon as possible.
I aopologize for sending this to the entire list, but I'm no longer
sure who is the right person to ask.
-- Jeff
∂14-Nov-89 0521 X3J13-mailer next meeting
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 05:21:32 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Nov 89 07:14:00-CST
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 14 Nov 89 05:13:41 PST
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa13290; 13 Nov 89 18:19 GMT
Date: Mon, 13 Nov 89 18:29:56 GMT
Message-Id: <1458.8911131829@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: next meeting
To: x3j13@sail.stanford.edu
Could someone please tell me when the next meeting (ie, the first
one in 1990) is? I need to know as soon as possible.
I aopologize for sending this to the entire list, but I'm no longer
sure who is the right person to ask.
-- Jeff
∂14-Nov-89 0911 X3J13-mailer next meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 09:11:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 692200; 14 Nov 89 12:10:01 EST
Date: Tue, 14 Nov 89 12:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: next meeting
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
cc: x3j13@sail.stanford.edu
In-Reply-To: <1458.8911131829@aiai.ed.ac.uk>
Message-ID: <19891114171014.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 13 Nov 89 18:29:56 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Could someone please tell me when the next meeting (ie, the first
one in 1990) is? I need to know as soon as possible.
Since I didn't see any answers yet, I'll answer this and copy the whole
list to cut down on duplicate answers. Wouldn't want to clog up the ether
over the Atlantic ocean. It's tentatively Monday throuigh Wednesday,
April 16-18, 1990, tentatively in Boston. We didn't specify which Boston
but it's probably not the one 100 miles or so from you. I believe this
date is not totally committed.
I aopologize for sending this to the entire list, but I'm no longer
sure who is the right person to ask.
JLZ@lucid.com would be a good guess.
∂14-Nov-89 0914 X3J13-mailer next meeting
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 09:14:10 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Nov 89 11:11:31-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 09:11:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 692200; 14 Nov 89 12:10:01 EST
Date: Tue, 14 Nov 89 12:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: next meeting
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
cc: x3j13@sail.stanford.edu
In-Reply-To: <1458.8911131829@aiai.ed.ac.uk>
Message-ID: <19891114171014.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 13 Nov 89 18:29:56 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Could someone please tell me when the next meeting (ie, the first
one in 1990) is? I need to know as soon as possible.
Since I didn't see any answers yet, I'll answer this and copy the whole
list to cut down on duplicate answers. Wouldn't want to clog up the ether
over the Atlantic ocean. It's tentatively Monday throuigh Wednesday,
April 16-18, 1990, tentatively in Boston. We didn't specify which Boston
but it's probably not the one 100 miles or so from you. I believe this
date is not totally committed.
I aopologize for sending this to the entire list, but I'm no longer
sure who is the right person to ask.
JLZ@lucid.com would be a good guess.
∂14-Nov-89 0948 X3J13-mailer November 89 Meeting minutes.
Received: from atc.boeing.com ([130.42.28.80]) by SAIL.Stanford.EDU with TCP; 14 Nov 89 09:48:48 PST
Received: by atc.boeing.com on Tue, 14 Nov 89 09:49:13 PST
Date: Tue, 14 Nov 89 09:54 PST
From: Stephen Nicoud <snicoud@atc.boeing.com>
Subject: November 89 Meeting minutes.
To: x3j13@sail.stanford.edu
Message-Id: <19891114175430.0.SLN@SKAGIT.atc.boeing.com>
Are the November 89 Meeting minutes available on-line somewhere?
Thanks,
Steve Nicoud
∂14-Nov-89 0952 X3J13-mailer November 89 Meeting minutes.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 09:51:53 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Nov 89 11:49:08-CST
Received: from atc.boeing.com ([130.42.28.80]) by SAIL.Stanford.EDU with TCP; 14 Nov 89 09:48:48 PST
Received: by atc.boeing.com on Tue, 14 Nov 89 09:49:13 PST
Date: Tue, 14 Nov 89 09:54 PST
From: Stephen Nicoud <snicoud@atc.boeing.com>
Subject: November 89 Meeting minutes.
To: x3j13@sail.stanford.edu
Message-Id: <19891114175430.0.SLN@SKAGIT.atc.boeing.com>
Are the November 89 Meeting minutes available on-line somewhere?
Thanks,
Steve Nicoud
∂14-Nov-89 1339 X3J13-mailer next meeting
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 13:39:35 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Nov 89 15:35:45-CST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Nov 89 13:35:31 PST
Received: from rose ([192.31.212.83]) by heavens-gate id AA04736g; Tue, 14 Nov 89 13:32:10 PST
Received: by rose id AA00404g; Tue, 14 Nov 89 13:33:43 PST
Date: Tue, 14 Nov 89 13:33:43 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8911142133.AA00404@rose>
To: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Mon, 13 Nov 89 18:29:56 GMT <1458.8911131829@aiai.ed.ac.uk>
Subject: next meeting
The next meeting is scheduled April 16 - 18. The place is yet to be
determined but will probably be on the east coast.
---jan---
∂14-Nov-89 1447 X3J13-mailer November 89 Meeting minutes.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 14:47:42 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Nov 89 16:45:43-CST
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 14:45:20 PST
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA06786; Tue, 14 Nov 89 14:42:17 -0800
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA01533; Tue, 14 Nov 89 14:44:37 PST
Message-Id: <8911142244.AA01533@masunter.parc.xerox.com>
Date: Tue, 14 Nov 89 14:44:37 PST
From: <masinter@parc.xerox.com>
To: snicoud@atc.boeing.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Stephen Nicoud's message of Tue, 14 Nov 89 09:54 PST <19891114175430.0.SLN@SKAGIT.atc.boeing.com>
Subject: November 89 Meeting minutes.
Sorry, I meant to send this out. These are *DRAFT* unreviewed minutes
of the November 89 meeting.
November 6, 1989 Xerox PARC, Palo Alto, California X3J13 Meeting
Monday, November 6, 1989
09:05am Call to order, Guy Steele chair
Gregor Kiczales informed us that no badges would be needed, a phone is
located outside the room, lunch baskets will be made available and that, in
the case of an earthquake, get under the table fast.
27 people will be having lunch today. Jan Zubkoff asked everyone to get in
their $60 made out to LUCID.
Attendees introduced themselves.
Mailing lists will move from SAIL to MCC on Thursday.
X3J, CLWindows, CL, CLOS, and CLCleanup mailing lists will be on
X3J13 @ MCC.COM
Approval of Agenda
Discussion of future meetings will be postponed to Wednesday. CL issues
is moved to tomorrow. Draft Committee Report will be given 15 min.
Approval of Minutes
Mary Van Deusen asked that people look at the June minutes over break
periods and that the changes be integrated and voted on tomorrow. It was
noted that the minutes were never sent over the net after the last meeting.
A volunteer will be needed to put the June minutes and the November minutes
on the net after this meeting.
09:25am, ISO meeting, Dick Gabriel
Agenda Item 6
Dick Gabriel discussed the ISO meeting. Instead of talking about
technical contents of drafts, the meeting discussed plans. At the previous
meeting, had decided to not do anything original but to have people
submit drafts and look into draft modifications. French group now
brought up issue of using Common Lisp subset and that was topic of long
discussion. A position was taken that "A language is a subset if you can
translate it into a superset." The French are looking for a common kernel
between Common Lisp and WG 16, along with dynamic binding. Japan made
an informal request for a Common Lisp subset without CLOS. Dick noted
that the chair of WG16 has the role of determining consensus and only
voting when consensus occurs.
Dick noted that the minutes are of extreme importance in that they
represent the only accepted history.
Kernel concept and list of features will be available before the early
February next meeting in Palo Alto. We need to decide if we are willing
to participate in a subset approach and what features do we feel need
to be part of that kernel. It's important that we let our feelings about
a subset plan be known early.
Concern was expressed by the committee of the effect of subsetting on
portability.
Other Business
Guy mentioned that the new version of his book is at the printer's now
and everyone in this committee will be getting a courtesy copy.
10:40am Break, Agenda Item 7
11:00am Recovene, Agenda 6 (continued)
ISO has agreed to call its new lisp ISLISP.
Kent Pitman moved, and Barry Margolin seconded, to split Dick Gabriel's
three part plan into its constituent parts.
JonL White moved, and Dan Pierson seconded, to combine the first two parts
into a single part. The motion failed by a majority.
The original motion of Kent's passed unanimously.
Part 1. Informal response to the Japanese
We spent a lot of time thinking about whether CLOS should be part of Common
Lisp. We strongly believe it should be part of CL. We would not supporty
ISLISP without CLOS.
Part 2. The U.S. declines to participate in the approach of subsetting
CL. We have previously spent a lot of time discussing this issue and
rejected it.
Sandra Loosemore moved, and Walter van Roggen seconded, that the issue be
postponed until tomorrow when Dick and Gregor would have a firmer position.
The motion passed unanimously.
11:25am, Drafting Committee, Dick Gabriel
Agenda Item 12
Dick discussed the type of changes that he made to the draft:
1) in all places where decision talked about how an implementation would do
something, he tried to phrase in terms of properties of conforming programs.
2) he removed anthromophormisms. The system would no longer "believe".
3) he took out advice to implementions.
4) he took out use of words turned into verbs (e.g. interned).
5) he took out flames.
6) he took out overspecification.
7) he changed some typesetting decisions.
In summary, tried to make the discussion more like CLOS.
12:05pm, Lunch
01:05pm Reconvene
Concern was expressed over the fact that the financial coverage of
the editor's position was about to expire and the question was raised on
what the effect on the standard would be.
One suggestion was to look at a distribution of costs of an editor
over 4-6 companies. Another was to look to DARPA for a grant.
Sandra Loosemore volunteered to participate in the rewriting over the
next few months. David and Walter suggested making a list of sections
that people could volunteer to work on.
Larry moved that we adjourn until 3:15pm and continue with the cleanup
issues.
03:15pm Reconvene
David Moon offered to coordinate volunteers for the writing effort.
Guy and Dick will be considering whether they can offer 1/2 time
toward the writing effort over the next 6 months.
David asked for a work plan to be published to this group by the end
of the month.
The work load would require monthly review.
JonL volunteered about 20 hours of writing time. Kent offered
reviewing time.
The committee offered applause to the drafting subcommittee for the
work already done.
03:40pm Cleanup Subcommittee, Larry Masinter
Agenda Item 8
&ENVIRONMENT-BINDING-ORDER, Version 3, November 3, 1989
PROPOSALS: LEFT-TO-RIGHT, FIRST
A straw vote showed that 9 would vote for LEFT-TO-RIGHT and 9 would
vote for FIRST.
COMPLEX-ATANH-BOGUS-FORMULA, Version 1, September 20, 1989
The motion passed 16-0.
CONDITION-RESTARTS, Version 2, June 26, 1989
Kim Barrett made the following friendly amendment:
1. In item 4, para 3, replace 1st sentence:
"When this argument is supplied, only those restarts which are associated
with the given condition or restarts which are not associated with any
condition are considered."
2. In item 5, after "WARN"
"(or is a form which macroexpands into such a list)"
3. In item 7, remove
"-- a condition --"
Add
"The argument to the test function is the value of the optional condition
argument most of these functions accept (or nil for invoke-restart,
since it doesn't have that argument).
The motion, with the friendly amendment, passed unanimously.
DEFINE-COMPILER-MACRO, Version 3, July 12, 1989
PROPOSALS: NEW-FACILITY, FIX-BUGS
The issue is deferred until tomorrow.
DEFINE-DECLARATION-RETURN-VALUE, Version 1, October 29, 1989
The motion passed unanimously.
DEFMACRO-BLOCK-SCOPE, Version 1, October 24, 1989
PROPOSALS: INCLUDES-BINDING, EXCLUDES BINDING
The EXCLUDES BINDING proposal passed unanimously with 1 abstention.
A sense of the meeting is that DEFUN and other functions were already
specified in CLTL.
DEFSTRUCT-CONSTRUCTOR-OPTIONS, Version 1, October 11, 1989
The motion passed unanimously.
DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES, Version 2, November 2, 1989
PROPOSALS: BOUND, NOT-BOUND, VISIBLY-BOUND
A straw vote on the three proposals showed:
BOUND 2
NOT-BOUND 12
VISIBILY-BOUND 2
The NOT-BOUND proposal passed 15-1.
DEFSTRUCT-SYNTAX-ERRORS, Version 1, October 11, 1989
The issue was deferred to tomorrow when specific proposals can be
presented.
EVALHOOK-STEP-CONFUSION, Version 2, November 2, 1989
Sandra made a friendly amendment to delete part 1 and to change the
first word of part 3 from "Deprecate" to "Delete".
The motion, as amended, passed 15-2.
FLOATING-POINT-CONDITION-NAMES, Version 1, October 30, 1989
JonL made a friendly amendment to remove parts 2 and 3. The motion,
as amended, passed unanimously.
INSPECT-RETURN-VALUE, Version 1, October 23, 1989
Kent moved, and xx seconded, the following amendment:
"INSPECT either returns its argument or, if permitted by the
implementation, some other object which has been interactively
designated during the INSPECT session."
The issue was deferred to tomorrow with no second to the amendment.
MACRO-DECLARATIONS, Version 2, November 2, 1989
The motion passed unanimously.
MACROEXPAND-RETURN-VALUE, Version 1, October 29, 1989
The motion passed 13-1-2.
READER-ERROR, Version 2, November 2, 1989
Kent moved, and Dan seconded, an amendment to change the name
READER-ERROR to PARSE-ERROR. The amendment passed 12-3.
The motion, as amended, passed unanimously.
STANDARD-READTABLE, Version 3, November 3, 1989
The issue was deferred to tomorrow.
05:00pm Other Business
05:15pm Adjournment
Tuesday, November 7, 1989
09:10am Cleanup Subcommittee (continued)
&ENVIRONMENT-BINDING-ORDER, Version 3, November 3, 1989
PROPOSALS: LEFT-TO-RIGHT, FIRST
A straw vote showed that no one would object to either proposal.
The FIRST proposal passed 15-0. A motion to replace the FIRST
proposal with the LEFT-TO-RIGHT proposal failed 4-12.
DEFSTRUCT-SYNTAX-ERRORS, Version 1, October 11, 1989
Sandra removed this issue from consideration.
INSPECT-RETURN-VALUE, Version 1, October 23, 1989
The motion failed 3-13.
STANDARD-READTABLE, Version 3, November 3, 1989
The issue was deferred to another meeting.
DEFINE-COMPILER-MACRO, Version 3, July 12, 1989
PROPOSALS: NEW-FACILITY, FIX-BUGS
JonL proposed:
Compiler Macro Expand (and -1) should perform any checking of
compiler optimization qualities, such as NOTINLINE, SPEED, SAFETY, etc.,
so that the result is what is actually used when computing.
Implementations are free to implement this as:
1) returning the EQ form means no expansion
2) COMPILER-MACRO-EXPAND may implement optimization checks
itself, or may leave it to the macro itself - this is
implementation-dependent.
JonL's proposal was not yet placed on the floor.
Walter proposed:
DEFINE-COMPILER-MACRO
Replace "Like DEFMACRO...&WHOLE." with
"The lambda-list is a macro lambda list as accepted by DEFMACRO, and
supports &WHOLE and &ENVIRONMENT and destructuring."
COMPILER-MACRO-EXPAND (-1)
Change "Note that a compiler macro may decline to provide any
expansion merely by returning the EQL form;"
&add "and the form must not have been modified.
Walter's proposal was not placed on the floor.
David Moon moved, and Dick Gabriel seconded, to
Eliminate
(OR (FIND-SYMBOL "CELL-ERROR"
(FIND-PACKAGE
"COMMON-LISP"))
(FIND-SYMBOL "ACCESS-ERROR"
(FIND-PACKAGE
"COMMON-LISP")))
Ditto for CELL-ERROR-NAME and/or
ACCESS-ERROR-NAME
Introduce UNBOUND-VARIABLE-NAME,
UNDEFINED-FUNCTION-NAME,
UNBOUND-SLOT-NAME.
The amendment passed 9-8.
Straw vote showed that one person felt strongly about their vote.
Larry moved, and Dan seconded, to roll back the previous motion to
CELL-ERROR. The motion passed 12-5.
10:35am Break
11:10am ISO Report (continued)
Straw poll of modified position to see if position is on the right
track. The position was unanimously supported.
12:00pm Lunch
01:30pm Reconvene
The following position was prepared as a reply for ISO:
1) X3J13 considered the question of defining a subset of Common Lisp
by excluding CLOS, and decided that it would not be in the best
interests of programmers to do so. X3J13 believes that CLOS will be
a fundamental part of Common Lisp and will be widely accepted
because it captures the essence of current practice in the Lisp
community. Indeed, many existing implmeentations of Common Lisp
already support CLOS in one form or another, differing primarily
in choice of implementation techniques rather than in the set of
features supported. Other implementations support object-oriented
programming features that are similar to CLOS. X3J13 believes there
are no fundamental technical problems in removing CLOS from Common
Lisp, but will not support such an endeavor.
2) Several times, X3J13 considered the question of Common Lisp
subsets. There was a subcommittee on subsets which was unable to
produce an acceptable subset definition: the iteration subcommittee
considered making some iteration constructs optional and decided
against it; and the optionality of CLOS was considered and rejected
because there has been a recognized need for object-oriented
programming in Lisp.
X3J13 finally decided that no technically acceptable subset is consistent
with the primary goals of X3J13, which place a strong emphasis on
portability of code.
Therefore, X3J13 advises against ISO WG16 standardizing a subset of
Common Lisp.
3. X3J13 is interested in exploring long-term Lisp standardization
by focusing on areas such as parallel processing, modules, distributed
computing, multi-language programming, and user interfaces. At this
time, X3J13 has no more detailed ideas about a starting point for long
term standardization. But we are interested in long term standardization.
4. X3J13 was not explicitly requested to do so, but we would like to
clarify our intention in the following sentence from page 1-17:
"The language described in this standard contains no subsets, although
subsets are not forbidden."
We mean by this that we do not support subset standards, but we do
support (and envision) subset implementations. Such implementations
would be marked as specified in section 1.5, bullet 6.
To clarify what we mean when we use the word subset:
Language L is a subset of language L' iff
for every valid program P in language L
P is also a valid program in language L'
and P has the same defined behavior in both L and L'.
A motion to support this position passed unanimously.
01:45pm Whither (what's next)
Agenda Item 24
David Moon submitted the following ideas for drafting a work plan:
Glossary, Error and Other Terminology
Representative Function Pages
4.1 Evaluation
All function pages (except hard ones)
6.1 Notes and Rules
5.1 Conditions
4.2 Compilation
4.1 Methods
Hard Function Pages
Rest of Chapters 1, 2, 3, 5
Large New Facilities
LOOP
Pretty Print
Insert remaining cleanup issues
Review Comments (receive, distribute, edit, archive)
Production issues (formatting, copying, mailing)
All X3J13 members need to contribute reading, writing
Quality?
02:10pm Next Meeting
April 16-18, 1990 are the tentative dates for the next meeting on
the east coast.
The committee applauded Gregor and Larry for their work in hosting this
meeting.
02:20pm Whither (continued)
The realistic goals that could be expected to be achieved by the next
meeting were discussed.
Dick noted that 10 pages of the compilation section took him two weeks
of full-time work from the good basis of Sandra's work.
02:55pm June and November Minutes
Larry Masinter will take the June and November minutes and put them on
the net. The approval of both sets of minutes will be put off until the
next meeting.
03:00pm Break
03:20pm Cleanup Subcommittee (continued)
COMPILER-MACRO
David moved, and Sandra seconded, the following amendment
* Change item 3 of proposal FIX-BUGS to read:
Remove the functions COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1.
Transfer all properties of these functions to langauge processors
that examine compiler macros (e.g., shadowing by lexical binding,
NOTINLINE declarations, etc.)
* Add a new item (6):
State explicitly that the name of a compiler macro can name a macro
as well as a function
* Add a new item (7):
Replace "Like DEFMACRO ... &WHOLE" in proposal NEW-FACILITY with:
the lambda-list is a macro lambda-list as accepted by DEFMACRO,
and supports &WHOLE and &ENVIRONMENT and destructuring.
* Add a new item (8):
Clarify that a compiler macro may decline to provide any expansion
merely by returning the EQL form.
* Add a new item (9):
Clarify that the consequences are undefined if a compiler macro
destructively modifies its form argument.
Barry moved, and Kim seconded, an amendment to change bullet 2 from
can to cannot. The motion failed 4-13.
David moved, and Kim seconded, the following amendment:
1) change the 'name' of a compiler-macro from a symbol to a
function name. The &WHOLE argument can be (funcall #'name.arguments).
This motion is later flushed and replaced with another motion.
*****
Larry made a friendly amendment to David's motion to change it to
the following:
Add a sixth bullet:
Change the 'name' of a compiler macro from a symbol to a function
name.
Replace third bullet:
The lambda-list is a function lambda-list like DEFUN, plus
&ENVIRONMENT is allowed.
Replace fourth bullet:
A compiler macro may decline to provide any expansion by returning NIL.
Dan made an amendment to Larry's replacement amendment to:
Restore &whole and destructuring.
Specify that the &whole form receives the value ((setf NAME).arguments)
The amendment failed 8-10.
Larry's friendly amendment failed 9-9.
David's amendment
1) change the 'name' of a compiler-macro from a symbol to a
function name. The &WHOLE argument when name is a cons
can be (funcall #'name.arguments).
The amendment passed 14-4.
Amendment to compiler-macro proposal, as amended by the above votes,
is a friendly amendment to FIX-BUGS proposal of
DEFINE-COMPILER-MACRO, Version 3, July 12, 1989
PROPOSALS: NEW-FACILITY, FIX-BUGS
The motion, as amended, passed 17-1.
04:40pm Draft Subcommittee (continued)
David presented issues for consideration.
1) pprint tabular doesn't figure out column width itself
2) tilda colon t might be a compatibility problem for some people
3) implementing formatter by calling format is not possible due to current
wording problems
These, and others, will be presented to the pprint group for solution.
4) ensure-generic function needs to be changed when colon lambda list
argument not supplied
5) define-methods-combination has a colon arguments feature which should be
eliminated
6) do we want to flush generic-flat, generic labels,
generic-function, with-added-methods. They have ambiguities in
their descriptions
7) if you read description of slot-unbound and slot-missing functions,
it says method can return any number of values and the original
function will return those values. Say that you can't change the
number of values returned.
8) what kind of error checking do you get for function argument
mismatching
9) does deftype allow &key in its lambda list
10)is there a way for an implementation to say that it conforms in such as
way that #plus can test
11)last loop draft has one page of comments. What is the process for
addressing those comments.
05:40pm Adjournment
Tuesday, November 7, 1989
09:00am
05:00pm Adjournment
Minutes submitted November 8, 1989, Mary S. Van Deusen.
≠
∂14-Nov-89 1728 X3J13-mailer comments on minutes from november meeting
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 17:28:17 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Nov 89 19:27:02-CST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Nov 89 17:26:45 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA22451; Tue, 14 Nov 89 18:26:45 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA08316; Tue, 14 Nov 89 18:26:41 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911150126.AA08316@defun.utah.edu>
Date: Tue, 14 Nov 89 18:26:40 MST
Subject: comments on minutes from november meeting
To: maida@ibm.com
Cc: x3j13@sail.stanford.edu
Here are some comments on the draft minutes....
>03:40pm Cleanup Subcommittee, Larry Masinter
>Agenda Item 8
>
> &ENVIRONMENT-BINDING-ORDER, Version 3, November 3, 1989
> PROPOSALS: LEFT-TO-RIGHT, FIRST
> A straw vote showed that 9 would vote for LEFT-TO-RIGHT and 9 would
> vote for FIRST.
This issue was then postponed for consideration on Tuesday.
> DEFMACRO-BLOCK-SCOPE, Version 1, October 24, 1989
> PROPOSALS: INCLUDES-BINDING, EXCLUDES BINDING
> The EXCLUDES BINDING proposal passed unanimously with 1 abstention.
The correct names of the proposals on this issue are INCLUDES-BINDINGS
and EXCLUDES-BINDINGS.
> INSPECT-RETURN-VALUE, Version 1, October 23, 1989
> Kent moved, and xx seconded, the following amendment:
> "INSPECT either returns its argument or, if permitted by the
> implementation, some other object which has been interactively
> designated during the INSPECT session."
> The issue was deferred to tomorrow with no second to the amendment.
Kent's amendment was a friendly amendment.
>Tuesday, November 7, 1989
>09:10am Cleanup Subcommittee (continued)
>
> INSPECT-RETURN-VALUE, Version 1, October 23, 1989
> The motion failed 3-13.
The proposal that was voted on here included Kent's friendly amendment.
> DEFINE-COMPILER-MACRO, Version 3, July 12, 1989
> PROPOSALS: NEW-FACILITY, FIX-BUGS
> [...]
> JonL's proposal was not yet placed on the floor.
> [...]
> Walter's proposal was not placed on the floor.
At this point, DEFINE-COMPILER-MACRO was postponed until after lunch
so that we could assemble all the various amendments and have copies
printed.
> David Moon moved, and Dick Gabriel seconded, to
> Eliminate
> (OR (FIND-SYMBOL "CELL-ERROR"
> (FIND-PACKAGE
> "COMMON-LISP"))
> (FIND-SYMBOL "ACCESS-ERROR"
> (FIND-PACKAGE
> "COMMON-LISP")))
>
> Ditto for CELL-ERROR-NAME and/or
> ACCESS-ERROR-NAME
>
> Introduce UNBOUND-VARIABLE-NAME,
> UNDEFINED-FUNCTION-NAME,
> UNBOUND-SLOT-NAME.
>
> The amendment passed 9-8.
>
> Straw vote showed that one person felt strongly about their vote.
>
> Larry moved, and Dan seconded, to roll back the previous motion to
> CELL-ERROR. The motion passed 12-5.
The minutes list this discussion under issue DEFINE-COMPILER-MACRO, but
it was really a separate, unnamed issue raised by Kent Pitman.
>03:20pm Cleanup Subcommittee (continued)
> COMPILER-MACRO
This is issue DEFINE-COMPILER-MACRO again.
> David moved, and Sandra seconded, the following amendment
There seems to be some confusion here. I introduced the bulleted list
of changes that follows this in the minutes as a friendly amendment to
my own proposal FIX-BUGS.
> David moved, and Kim seconded, the following amendment:
> 1) change the 'name' of a compiler-macro from a symbol to a
> function name. The &WHOLE argument can be (funcall #'name.arguments).
>
> Larry made a friendly amendment to David's motion [...]
> Larry's friendly amendment failed 9-9.
This vote was not on Larry's amendment, but on David's amendment including
Larry's friendly changes.
> David's amendment
> 1) change the 'name' of a compiler-macro from a symbol to a
> function name. The &WHOLE argument when name is a cons
> can be (funcall #'name.arguments).
> The amendment passed 14-4.
What really happened here is that David's original amendment was
introduced again, I think by somebody else. I can't remember who
proposed it or who seconded it this time.
-Sandra
-------
∂14-Nov-89 1741 X3J13-mailer next meeting
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 17:41:29 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Nov 89 19:30:52-CST
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Nov 89 17:30:23 PST
Received: from relay.cc.u-tokyo.ac.jp ([192.41.197.3]) by argus.Stanford.EDU with TCP; Tue, 14 Nov 89 17:22:09 PST
Received: from ccut.cc.u-tokyo.ac.jp by relay.cc.u-tokyo.ac.jp (5.61/2.6W)
id AA27256; Wed, 15 Nov 89 10:30:27 +0900
Received: from aoyama.cc.aoyama.ac.jp by ccut.cc.u-tokyo.ac.jp (5.61/6.4J.6-ut1.80)
id AA27345; Wed, 15 Nov 89 10:31:04 +0900
Received: by aoyama.cc.aoyama.ac.jp (4.0/6.4J.6-agu4)
id AA21504; Wed, 15 Nov 89 10:28:53 JST
Received: by kepa.cc.aoyama.ac.jp (4.0/6.4J.5-aguac)
id AA03275; Wed, 15 Nov 89 10:28:31 JST
Date: Wed, 15 Nov 89 10:28:31 JST
From: Masayuki Ida <ida@cc.aoyama.ac.jp>
Return-Path: <ida@cc.aoyama.ac.jp>
Message-Id: <8911150128.AA03275@kepa.cc.aoyama.ac.jp>
To: jlz@lucid.com
Cc: ida@cc.aoyama.ac.jp, x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Tue, 14 Nov 89 13:33:43 PST <8911142133.AA00404@rose>
Subject: next meeting
>>Date: Tue, 14 Nov 89 13:33:43 PST
>>From: Jan Zubkoff <jlz@lucid.com>
>>
>>The next meeting is scheduled April 16 - 18. The place is yet to be
>>determined but will probably be on the east coast.
>>---jan---
>>
>>
Dear Jan,
Is the above date fixed completely ?
I will attend the EUROPAL conference for march 27 to 29 at UK.
So, it's impossible to fly abroad again in April.
If the meeting were scheduled on the first week of April between April
2nd to 5th, I can attend....
Masayuki Ida
Aoyama Gakuin University
∂15-Nov-89 0837 X3J13-mailer next meeting
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 Nov 89 08:37:25 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 15 Nov 89 10:30:13-CST
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 15 Nov 89 08:29:54 PST
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Wed, 15 Nov 89 11:31:19 -0500
Date: Wed, 15 Nov 89 11:26 EST
From: Barry Margolin <barmar@Think.COM>
Subject: next meeting
To: Masayuki Ida <ida@cc.aoyama.ac.jp>
Cc: jlz@lucid.com, x3j13@sail.stanford.edu
In-Reply-To: <8911150128.AA03275@kepa.cc.aoyama.ac.jp>
Message-Id: <19891115162600.3.BARMAR@OCCAM.THINK.COM>
Date: Wed, 15 Nov 89 10:28:31 JST
From: Masayuki Ida <ida@cc.aoyama.ac.jp>
>>Date: Tue, 14 Nov 89 13:33:43 PST
>>From: Jan Zubkoff <jlz@lucid.com>
>>
>>The next meeting is scheduled April 16 - 18. The place is yet to be
>>determined but will probably be on the east coast.
If the meeting were scheduled on the first week of April between April
2nd to 5th, I can attend....
This might be a good idea for another reason: April 15 is Easter Sunday,
and some people might not want to spend it in the air. I complained
about April 9-11 because of Passover (not to mention a wedding in
Phoenix that weekend), and I think the Christians should get equal
attention.
barmar
∂15-Nov-89 1111 X3J13-mailer November 89 Meeting minutes.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 Nov 89 11:10:54 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 15 Nov 89 13:09:19-CST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 15 Nov 89 11:09:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 693129; 15 Nov 89 14:07:48 EST
Date: Wed, 15 Nov 89 14:07 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: November 89 Meeting minutes.
To: masinter@parc.xerox.com, maeda@ibm.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8911142244.AA01533@masunter.parc.xerox.com>
Message-ID: <19891115190755.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Here are a couple of corrections to the minutes I noticed while reading
through them. I did not do a comprehensive review.
11:25am, Drafting Committee, Dick Gabriel
4) he took out use of words turned into verbs (e.g. interned).
words -> Common Lisp defined names
The following position was prepared as a reply for ISO:
community. Indeed, many existing implmeentations of Common Lisp
implmeentations -> implementations
03:20pm Cleanup Subcommittee (continued)
COMPILER-MACRO
DEFINE-COMPILER-MACRO
David moved, and Sandra seconded, the following amendment
I think there was only one Sandra in the room, but there were at least
two Davids, and I don't think either of them moved this particular
amendment. Anyway I don't think I did. I don't think it matters who
made motions, but if it does matter, people should be identified
unambiguously.
∂15-Nov-89 1251 X3J13-mailer *DRAFT* June 89 X3j13 minutes
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 Nov 89 12:51:00 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 15 Nov 89 14:47:40-CST
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Nov 89 12:47:08 PST
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA01376; Wed, 15 Nov 89 12:43:54 -0800
Received: by masunter.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA01993; Wed, 15 Nov 89 12:46:16 PST
Message-Id: <8911152046.AA01993@masunter.parc.xerox.com>
Date: Wed, 15 Nov 89 12:46:16 PST
From: <masinter@parc.xerox.com>
To: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
Cc: x3j13@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Wed, 15 Nov 89 17:13:19 GMT <14260.8911151713@aiai.ed.ac.uk>
Subject: *DRAFT* June 89 X3j13 minutes
Reply-To: masinter@parc.xerox.com
The June minutes were supposed to be revised before mailing. I'm less
sure of the status. I remember that there were some corrections
discussed at the November meeting.
Here's what I have... I'm getting together a "mail archive" service
for passed cleanup issues and other stuff; I've not put together the
amended issues from Nov 89 yet, though.
===============================
June 26-28, 1989 Palo Alto, California X3J13 Meeting
Monday, June 26, 1989
Agenda Items 1, 2, and 3
Bob Mathis opened the meeting and invited the attendees to introduce
themselves.
He noted that this was the 12th meeting and thought he saw the activities
beginning to wind down.
Jan Zubkoff announced that the next meeting would be in September 6-8 in
Palo Alto, California. The November 8-10 meeting would be back in
Fairfax, Virginia. Concern was expressed that the meetings were held too
frequently. This topic will be brought up again on Wednesday.
** Note that this has been changed later in the minutes to only a November
6-8 meeting at Xerox PARC.
Agenda Item 4, Approval of Minutes
The minutes were approved subject to changes noted during this meeting.
Agenda Item 5, Other Business
Jan Zubkoff will find out where lunch will be held.
09:30am Series Proposals, Guy Steele
Agenda Item 6
We now have a polished series proposal from Dick Waters. Should we
consider it?
Guy Steele moved that the series proposal as documented in the draft
version of Steel's book be added to the X3J13 Common Lisp standard. David
Moon seconded the motion. The motion failed 2-13. 3 abstained.
Dick Waters moved that the series proposal be added to the X3J13 Common
Lisp standard as an appendix. Dan Pierson seconded the motion. Bob
Mathis felt that the failure of the motion would result in a reference
to the series proposal in the standard. The motion failed 3-11. 3
abstained.
10:35am Lisp Pointers
Mary Van Deusen announced that Lisp Pointers has been accepted as an
alternate publication of SIGPLAN Notices and will be made available to
all Lisp Pointers subscribers for free for one year.
10:40am Break, Agenda Item 7
11:00am ISO Report, Dick Gabriel
Agenda Item 8
A straw vote adopted the German report as the working plan for WG16.
The most interesting action item was brought up by the Japanese.
They were concerned with what would happen if ANSI Common Lisp were
adopted by ISO -- intellectual property rights and royalty rights.
IPS was concerned with who had intellectual property rights on ANSI
Common Lisp. Discussion with ANSI showed no problem. Professor Ito
was concerned that a Japanese implementation of Common Lisp would
force royalties to be paid to some company in US for implementation
or documentation. ANSI position says no royalties are to be paid.
A written answer was given on these issues.
The German proposal is that standard proposals must be submitted by
the end of July. Dick said we would submit part of our standard
directly to the delegates. He suggested that we send everything but
functional descriptions. They also want a rationale of why we are
making the draft, set of evaluation criteria to evaluate the draft,
the user committee addressed, etc. We also need to say what
revisions we intend to submit and the timeframe in which we intend to
make those revisions. This is not considered to be the official
submission but only a draft to comment on.
If the language is chosen as one of the ISO standards, they would provide
comments and suggestions which would not be required to be followed.
The timing is to make the drafts available at the September ISO meeting
in Japan. Following all this would be a vote of acceptance or rejection.
Drafts will be provided by us, the Scheme committee (Chris Hanes), and
a European draft (written by Padget and implemented by Fitch), FEEL,
(Free and Eventually Euro Lisp).
The Scheme community are ready to pull back their submission of Scheme
if Common Lisp is rejected.
Gregor moved to empower the ISO delegation to submit to the ISO
committee that part of the Common Lisp standard that they believe
appropriate to submit at the end of July. Barry Margolin seconded
the motion. The motion passed unanimously 20-0-0.
Guy will be preparing the supplementary documents and pass them by the
X3J13 committee electronically.
Criteria: Dick: useful dialect, clearly and fully described.
Bob: mathematical multiplicative formula based on use of features.
12:15pm Lunch, Agenda Item 9
01:30pm Window System Standard.
Agenda Item 10
Jim Kempf described the Solo Window Interface.
Bill York described "CLIM" the Common Lisp Interface Manager.
The discussion focused on the work on standardization of interfaces
to window systems and graphics systems and what role this committee
has to such work.
02:45pm Break, Agenda Item 11
03:00pm Cleanup Issues, Larry Masinter
ADJUST-ARRAY-NOT-ADJUSTABLE, Version 11, June 23, 1989
The motion passed with one vote opposed.
COMPLEX-RATIONAL-RESULT, Version 3, April 28, 1989
The motion passed unanimously.
DYNAMIC-EXTENT-FUNCTION, Version 2, June 11, 1989
The motion passed unanimously.
Dick Gabriel volunteered to handle ERROR-CHECKING-IN-NUMBERS-CHAPTER in
the
editorial subcommittee. Kent Pitman moved that the editorial subcommittee
be instead authorized to place this type of signalling statement, and
other changes like this, throughout the document. Gregor seconded the
motion. This motion passed unanimously.
HASH-TABLE-SIZE, Version 1, March 20, 1989
The issue was deferred until tomorrow.
LOAD-TRUENAME, Version 4, April 11, 1989
The motion passed with one vote opposed.
PEEK-CHAR-READ-CHAR-ECHO, Version 3, October 8, 1988
The issue was deferred.
PRETTY-PRINT-INTERFACE, Version 1, June, 1989
A straw vote was called: How many people feel we should add this to
the standard this year? 15 in favor. 3 opposed.
How many want the whole thing voted? 7 in favor. 6 opposed.
This issue was deferred to the next cleanup session for voting in its
entirety.
READ-CASE-SENSITIVITY, Version 6, June 24, 1989
This issue was deferred.
REQUIRE-PATHNAMES-DEFAULT
JonL White moved, and Dan Pierson seconded, to reconsider the
REQUIRE-PATHNAMES-DEFAULT. Leave PROVIDE/REQUIRE essentially the same as
in CLTL, but direct the editorial subcommittee to place it in deprecated
status. The motion failed 5-11.
SUBTYPEP-TOO-VAGUE, Version 5, March 15, 1989
This issue will be deferred while Guy Steele corrects this version.
TYPE-OF-UNDERCONSTRAINED, Version 6, June 22, 1989
The motion passed unanimously.
UNDEFINED-VARIABLES-AND-FUNCTIONS, Version 1, November 29, 1988
This issue will be deferred until Gregor is available.
WITH-OPEN-FILE-DOES-NOT-EXIST, Version 1, March 17, 1989
Proposals: DON'T EVALUATE and STREAM-IS-NIL
The STREAM-IS-NIL motion passed unanimously.
THE-AMBIGUITY, Version 2, January 11, 1989
Proposals: FOR-DECLARATION and FOR-DISCRIMINATION
The FOR-DECLARATION motion passed unanimously.
STREAM-DEFINITION-BY-USER, Version 1, March 22, 1989
The issue will be deferred.
STREAM-CAPABILITY, Version 3, May 12, 1989
The motion passed unanimously.
SETF-MULTIPLE-STORE-VARIABLES, Version 1, June 16, 1989
This issue will be deferred.
PRINT-CASE-PRINT-ESCAPE-INTERACTION, Version 1, January 26, 1989
Proposals: LIKE-PRIN1, LIKE-WRITE-STRING, VERTICAL-BAR-RULE-NO-UPCASE,
VERTICAL-BAR-RULE-PERMIT-UPCASE, EXPLICITLY-VAGUE.
The VERTICAL-BAR-RULE-NO-UPCASE motion passed unanimously.
05:00pm Adjournment
Tuesday, June 27, 1989
09:00am Call to Order, Agenda Item 14
09:00am Compiler Subcommittee, Sandra Loosemore
Agenda Item 15
CLOS-MACRO-COMPILATION, Version 5
Proposal: MINIMAL
The motion passed unanimously.
COMPILE-ENVIRONMENT-CONSISTENCY, Version 6
Proposal: CLARIFY
Amendment: BOBS-AMENDMENT
BOBS-AMENDMENT failed unanimously.
Kent Pitman offered the following editorial advice: add to (1) the
sentence, "except in situations where EVAL, COMPILE, or COMPILE-FILE
is used to force new semantic analysis at runtime."
The CLARIFY proposal passed unanimously.
COMPILE-FILE-SYMBOL-HANDLING, Version 4
Proposal: NEW-REQUIRE-CONSISTENCY
A friendly amendment was made to change, in item 1b, "first top-level
form" to "first non-atomic top-level form".
Sandra Loosemore moved, and Gregor seconded, an amendment to clarify
that if the first top-level form is a call to IN-PACKAGE, it doesn't
matter whether or not the symbol CL:IN-PACKAGE is accessible in the
package that is the value of "PACKAGE" when LOAD is called.
The amendment failed 3-10.
Straw vote: Delete 1b: 8
Keep 1b: 8
Straw vote of just principles: Get rid of 1b: 7
Keep 1b: 10
Keep 1b as is: 0
Clarify 1b: 10
The committee decided, by acclaimation that, if this proposal passes, the
cleanup subcommittee will clarify 1b.
This issue will be deferred until the end of the day.
COMPILED-FUNCTION-REQUIREMENTS
Proposals: FLUSH and TIGHTEN
Kent volunteered to write an alternate proposal to TIGHTEN. The motion
was tabled until Kent's proposal is ready.
COMPILER-DIAGNOSTICS, Version 13
Proposal: USE-HANDLER
Barry Margolin moved, and Jonl White seconded, the amendment to change
item #3 to state that both COMPILE and COMPILE-FILE are permitted (but
not required) to establish a handler for ERROR. For example, they
might issue a warning, and restart compilation from some
implementation-dependent point in order to let the compilation proceed
without manual intervention. The amendment passed 13-2.
Gregor moved, and Barry seconded, the amendment that in item 4, the second
return value should instead be a list of all conditions signalled during
the compilation process.
Kent moved, and Sandra seconded, a motion to table this issue until
after 5pm. The motion passed 10-7.
CONSTANT-FUNCTION-COMPILATION, Version 1
Proposal: NO
The motion passed unanimously.
MACRO-CACHING, Version 3
Proposals: DISALLOW and DEPRECATE
The DISALLOW proposal passed unanimously. The DEPRECATE proposal
failed 4-9.
PROCLAIM-ETC-IN-COMPILE-FILE, Version 4
Proposal: NEW-MACRO
A friendly amendment was made to change the name DEFPROCLAIM to DECLAIM.
The motion, as amended, passed unanimously.
SYNTACTIC-ENVIRONMENT-ACCESS, Version 10
A friendly amendment was made to replace the last sentence of the
description of the function ENCLOSE with:
The LAMBDA-EXPRESSION is permitted to reference only the parts of the
environment argument ENV that are relevant only to syntactic processing,
specifically declarations and definitions of macros and symbol-macros.
The consequences are undefined if the LAMBDA-EXPRESSION contains any
references to variable or function bindings that are lexically visible in
ENV; any GO to a tag that is lexically visible in the environment ENV; or
any RETURN-FROM a block name that is lexically visible in the environment
ENV.
A friendly amendment was made to make a global change of "property list"
to "a-list with value in the CDR".
A friendly amendment was made to remove the parenthetical phrase "(i.e.,
those that are "pervasive")" from the first paragraph of
DECLARATION-INFORMATION and to change "the declaration is pervasive,
rather than applying to bindings." to "the declaration does not apply to
bindings." following :DECLARE in the DEFDECLARE section.
A friendly amendment was made to change DEFDECLARE to DEFINE-DECLARATION.
The motion, as amended, passed unanimously.
QUOTE-SEMANTICS
Jonl asked to reopen the QUOTE-SEMANTICS issue. The motion failed
4-8.
COMPILE-FILE-SYMBOL-HANDLING, Version 4
Proposal: NEW-REQUIRE-CONSISTENCY
David Moon proposed, and Larry Masinter seconded, an amendment to
remove the last two paragraphs of the proposal, which follow point (3).
The amendment passed 11-5.
David Moon proposed, and Barry Margolin seconded, an amendment to
change all occurrences of "*PACKAGE*" to "*PACKAGE* and *READTABLE*".
This amendment was withdrawn.
The issue was deferred.
12:05pm Lunch, Agenda Item 18
01:15pm Cleanup Subcommittee, Kent Pitman
Agenda Item 19
CONDITION-RESTARTS, Version 2
The motion passed unanimously.
FUNCTION-COMPOSITION
The proposal was reconsidered with the friendly amendment to replace
"always" (which had been renamed "constantly"). The amended proposal
passed 10-5.
FUNCTION-TYPE
The proposal was reconsidered. A motion to flush the addition to COERCE
was tabled.
HASH-TABLE-SIZE
The proposal was tabled until JonL is present.
PATHNAME-CANONICAL-TYPE, Version 1, July 7, 1989
Straw poll: how many feel we will not reach closure. All
Sandra moved to table and Larry seconded. The motion passed with
3 votes opposed.
PATHNAME-COMPONENT-CASE, Version 5, June 17, 1989
Kent moved, and Steve Haflich seconded, an amendment to change "uppercase"
to "lowercase" and "lowercase" to "uppercase" in paragraph 3. The
amendment failed 4-10.
Barry moved, and Sandra seconded, an amendment to change "the default is
:COMMON" to "the default is :LOCAL". The amendment passed 14-3.
The motion, as amended, passed 12-4.
PATHNAME-COMPONENT-VALUE, Version 3, June 17, 1989
Proposal: SPECIFY
The motion passed unanimously.
PATHNAME-EXTENSIONS, Version 1, December 28, 1988
The proposal was withdrawn.
PATHNAME-LOGICAL, Version 4, June 23, 1989
Larry moved, and Sandra seconded, to table this proposal. The motion
failed 8-10.
Kim Barrett moved, and Walter von Roggen seconded, to strike item 8
of the proposal. The motion failed with two votes in favor.
Larry moved, and Sandra seconded, to reconsider the tabling. The motion
passed 10-9.
PATHNAME-PRINT-READ, Version 1, October 21, 1988
Kim Barrett moved, and Sandra seconded, to table this proposal until after
PRINT-READABLY. The motion passed 9-5.
PATHNAME-SUBDIRECTORY-LIST, Version 7, June 17, 1989
A friendly amendment specified that the list returned by
PATHNAME-SUBDIRECTORY-LIST is not guaranteed to be freshly consed and that
the consequences of modifying this list is undefined.
The motion, as amended, passed 16-1.
PATHNAME-SYNTAX-ERROR-TIME, Version 1, July 7, 1989
Proposals: PATHNAME-CREATION, NAMESTRING-COERCION, and EXPLICITLY-VAGUE.
The EXPLICITLY-VAGUE proposal passed 16-2.
PATHNAME-SYSTEM-TYPE, Version 2, June 17, 1989
The motion failed with one vote in favor.
PATHNAME-WILD, Version 7, June 23, 1989
Sandra moved, and Kim seconded, to change "T" to "TRUE" in sections
1 and 2. The amendment passed 12-2.
The motion, as amended, passed 12-8.
03:00pm, Break, Item 20
03:10pm Cleanup Subcommittee, continued
PEEK-CHAR-READ-CHAR-ECHO, Version 4, June 26, 1989
PROPOSALS: FIRST-READ-CHAR and TOO-TIRED-TO-THINK-UP-A-CLEVER-NAME
A friendly amendment duplicated the paragraph "Clarify that the echo
behavior of interactive streams..." to the end of the TOO-TIRED
proposal.
A friendly amendment says that it only applies to echo streams made
by MAKE-ECHO-STREAM.
A motion to withdraw the passed version of this proposal with TOO-TIRED
failed 14-2. Version 3 remains the passed version.
PRETTY-PRINT-INTERFACE
A friendly amendment globally changed all instances of "column-position"
to "horizontal-position".
How many people are interested in pursuing a format-style interface to
the pretty printer? 8-10
How many people approve of the idea format taking a second argument which
is a function, alternative to it taking a string? 11-8.
How many people think that #" shorthand is useful enough to use? 4-10
How many people are in favor of functional interface at the end of the
proposal? Unanimous
How many people want the facility to compile format strings? 11-7
Larry suggested that a drafting subcommittee unanimously agree on changes
to the PRETTY-PRINT and present them to the committee. The subcommittee
suggests Dick Waters, Sandra, Walter, Dan Pierson, Steve Haflich, and
Lausch. The committee agreed to accept the decision of the
subcommittee by 14-4.
PRINT-CIRCLE-SHARED, Version 1, March 30, 1989
Proposals: RESPECT-PRINT-CIRCLE and NEW-VARIABLE
A friendly amendment changed the RPC proposal to include the phrase, "of
objects that would not READ to be EQ," between "sharing" and "when".
The RESPECT-PRINT-CIRCLE proposal, as amended, passed 10-6.
A friendly amendment added :SHARED argument to WRITE for the NEW-VARIABLE
proposal. The NEW-VARIABLE proposal, as amended, failed 7-10.
A new proposal ":NEW-VALUE" was moved by Kent and seconded by Barry.
*PRINT-CIRCLE* was allowed to take on a value :CIRCLE-ONLY, which said
that the printer would only detect circularities, but not other types
of sharing.
The :NEW-VALUE proposal passed 14-4.
Steve Haflich moved, and Barry seconded, to reconsider the passed
proposals. The motion passed unanimously.
Barry moved, and Dan seconded, the following amendment to the :NEW-VALUE
proposal: When *PRINT-CIRCLE* is :CIRCLE-ONLY, the printer is not
required to detect shared structure, but may do so. The amendment passed
10-7.
The :NEW-VALUE proposal, as amended, failed in favor of
RESPECT-PRINT-CIRCLE 9-10.
READ-CASE-SENSITIVITY, Version 6, June 24, 1989
A friendly amendment changed "a readtable" to "*readtable*".
The motion, as amended, passed 13-3.
SEQUENCE-TYPE-LENGTH, Version 1, June 16, 1989
The motion passed 17-1.
SETF-MULTIPLE-STORE-VARIABLES, Version 2, March 22, 1989
The motion passed 11-7.
STREAM-DEFINITION-BY-USER, Version 1, May 22, 1989
The motion was indefinitely tabled.
STRING-COERCISON, Version 2. May 9, 1989
The motion passed unanimously.
SUBTYPEP-TOO-VAGUE, Version 5, March 15, 1989
A friendly amendment inserted the following after "directly" in the first
paragraph: "as a type specifier (while the type specifier listed in CLtL
Table 4-1 and names of DEFSTRUCT or DEFCLASS-defined types may,, in some
cases, be implemented in terms of DEFTYPE, they are to be regarded for
this purpose as not being "user-defined". Therefore, SUBTYPEP must regard
elements as primitive with respect to the question of returning NIL NIL.)
The motion passed unanimously.
UNDEFINED-VARIABLES-AND-FUNCTIONS, Version 1, November 29, 1988
Dave Moon moved, and JonL seconded, an amendment to strike the line:
"-Reading an unbound slot should invoke the function SLOT-UNBOUND."
The amendment passed 11-4.
The motion, as amended, passed unanimously.
BIT-ARRAY-FUNCTIONS, Version 6, June 19, 1989
PROPOSALS: ADD and NO-NEW-FUNCTIONS
Sandra moved, and Guy seconded, an amendment to delete 5,6 and 7.
The amendment passed 15-1.
The proposal ADD, as amended, failed 6-14.
The proposal NO-NEW-FUNCTIONS, as amended, failed 1-13.
DATA-IO, Version 8, June 23, 1989
The motion passed 18-1.
DEFINE-OPTIMIZER, Version 6, March 22, 1989
A straw vote to reconsider this issue passed 11-6.
Steve Haflich moved and Dan Pierson seconded an amendment to change
"optimizer" to "define-compiler-macro", "optimize-expression" and
"optimize-expression-1" to "compiler-macroexpand" and
"compiler-macroexpand-1." The amendment passed 11-2.
Larry moved, and Guy seconded, to close off debate. The motion failed
10-6.
JonL moved, and Steve Haflich seconded, the following amendment changes:
Straw votes: stay now 17
how many want to pass a similar issue 8-11
The motion is tabled until tomorrow.
EQUAL-STRUCTURE
Dick Waters moved, and Dan Pierson seconded, Jonl's amendment as follows:
Clarify the definition of EQUALP on DEFSTRUCT instances to be as follows:
* EQUALP on two DEFSTRUCT instances 's1' and 's2', where one is a
non-typed defstruct and the other is typed, is false.
* EQUALP on two DEFSTRUCT instances 's1' and 's2', where both are
non-typed defstructs is true iff:
(1) The type of 's1' is the same as the type of 's2' (this is the same
as saying that the defstruct name for 's1' is the same as that for
's2').
(2) The value of each slot of 's1' is EQUALP to the value of the same
slot of 's2' (where "same" means same name) (this is not the same
as 'slots' for standard-objects in CLOS).
The amendment, as amended, passed 14-4.
FLOAT-UNDERFLOW, Version 3, June 18, 1989
Jonl moved to separate parts 1 and 2 from parts 3, 4 and 5.
A motion to pass Part I and 2 passed 15-2.
Jonl moved to table Parts 3, 4, and 5 indefinitely. The motion passed
10-2.
HASH-TABLE-SIZE, Version 1, March 20, 1989
Dave Moon moved a friendly amendment to:
Append to proposal section:
Keep the first and last stentences of the definition of :REHASH-TRESHOLD
(CLtL p. 284. Replace the rest with:
This can be a REAL between 0 and 1, inclusive, which is a hint to the
implementation of the maximum desired hash table occupancy level. An
implementation is permitted to ignore this argument.
Add "Editorial Consequences":
Remove second complete paragraph on p. 283. It's too implementation-
dependent. Clarify the implementation is not necessarily an actual hash
table of any particular hashing technique.
The motion, as amended, passed unanimously.
MAP-INTO, Version 3, June 23, 1989
The motion passed 18-1.
PATHNAME-PRINT-READ, Version 1, October 21, 1988
Gail moved, and Barry seconded, an amendment to strike paragraph 2.
The amendment failed 9-10.
Sandra made a friendly amendment, to change "T" to "TRUE".
The motion, as amended, passed 14-3.
07:00pm Adjournment
Wednesday, June 28, 1989
09:00am Opening Comments and Call for Checks, Bob Mathis and Jan Zubkoff
09:05am Compiler Subcommittee, Sandra Loosemore
Agenda Item 15 (continued)
COMPILE-FILE-SYMBOL-HANDLING
Sandra moved, and Barry seconded, the following amendment. The amendment
passed 16-3.
(1) Restore the first of the two deleted paragraphs.
Rationale: Clarifies that this is not a "crash and burn" error.
(2) Add: A symbol S appearing in the source code is similar as a constant
to a symbol s' in the compiled code if:
* their print names are similar as constants
and, either
* s is accessible in *PACKAGE* at compile time, and s' is accessible
in *PACKAGE* at load time
or
* s' is accessible in the package that is similar as a constant to
the home package of symbol s.
Rationale: This defines "similar as constants" for interned symbols.
(3) Clarify that the "similar as constants" relationship for interned
symbols has nothing to do with *READTABLE* or how the function
READ would parse the characters in the print name of the symbol.
Larry moved, and Jonl seconded, to delete item 2 from the amendment .
The motion failed 3-11.
The motion, as amended, passed unanimously.
COMPILER-DIAGNOSTICS
This issue is tabled until David Moon creates an amendment.
COMPILED-FUNCTION-REQUIREMENTS
PROPOSAL: FLUSH and TIGHTEN
Kent made a friendly amendment to TIGHTEN:
* Strike second and third bullet in #1
* In #4, change clause 1 ("Clarify...COMPILED-FUNCTION;") to
Clarify that COMPILE must produce an object of type
COMPILED-FUNCTION if that is possible (for example, some
implmentations might not be able to compile lexical closures);
Larry moved, and Jonl seconded, an amendment to
bring back the third bullet and remove the sentence in
the amendment "if that is possible...lexical closures);
The votes on the amendment were divided into two parts: voting on
the third bullet and voting on the text.
The motion to keep the third bullet failed 8-10.
The motion to strike the text passed 14-4.
Larry moved, and Gregor seconded, an amendment to replace #4 by the
sentence: "Clarify that COMPILE must produce an object of type
COMPILED-FUNCTION. The amendment passed 17-0.
The TIGHTEN proposal, as amended, passed 14-4.
Sandra moved, and Dan Pierson seconded, to replace TIGHTEN with FLUSH.
The motion failed 5-13.
COMPILER-DIAGNOSTICS
David Moon moved, and Steve Haflich seconded, the following amendment:
In point 4, make COMPILE and COMPILE-FILE return 3 values:
VALUE 2: NIL: no compiler diagnostics,
true: some compiler diagnostics
VALUE 3: NIL: no compiler diagnostics other than style warnings
true: serious compiler diagnostics
The amendment passed 12-5.
Gregor moved, and Dick seconded, to replace the voted on amendment with
the following:
Change the second value from COMPILE and COMPILE-FILE in point 4 to one
of:
NIL -- no compiler diagnostics
STYLE-WARNING -- style warnings only
ERROR -- compiler says code is incorrect
Gregor withdrew his amendment.
JonL moved, and Steve seconded, to amend the motion to follow the last
line of the amendment with "or other conditions of type ERROR or WARNING,
but not STYLE-WARNINGS. The amendment passed 14-2.
The motion, as amended, passed unanimously.
10:30 Break, Agenda Item 24
10:45 Editorial Committee, Kathy Chapman
Agenda Item 23
CONFORMANCE-POSITION, Version 10, June 20, 1989
The motion passed unanimously.
EXTRA-RETURN-VALUES, Version 6, June 21, 1989
David Moon made a friendly amendment to remove "error" from the list
since it never returns and change the typo in the first line of the
rationale to say "additional values" rather than "additional arguments".
The issue was tabled for half an hour to let Sandra create an amendment.
Kathy described the status of the document. The following sections have
been heavily reviewed and the structure will probably not change: 1.1,
1.2, 1.3, 1.4, 1.5, 1.6, 2.1, 2.2, 5.1, Glossary, Macros, and Evaluator.
The following sections have been heavily reviewed and are still being
worked on: 4.1, 4.2, 2.3, 2.4, 2.5, and 8.1.
Kathy offered the following guide to understanding a particular defined
word description: (1) read section 6.1; (2) look it up in the table of
contents or index; read the description; (3) pay particular attention to
"glossary" and "data type" fonts; (4) read referenced "concept" sections.
To understand a concept: (1) chapters 1-5 contain concept information
about objects, types, reader, evaluation, compilation, conditions,
programming interfaces, the environment, I/O, and generazlized reference;
(2) the glossary contains concept information; (3) chapters 6/7 contains
some concept information.
The schedule is as follows:
July 31st - part of draft to ISO
August 5th - ISO draft sent to X3J13 for review
A letter ballot is being considered.
September meeting - draft will be distributed.
November meeting - resolve all issues brought up during X3J13 review.
Send out for public review.
There was considerable discussion concerning the worth of having a meeting
in September.
Straw poll: The ISO draft will be mailed out, a November meeting will
examine the corrections made to the ISO draft, after the "final" draft
is finished, a meeting will be set for a few months after the "final"
draft is sent out and responses made. 17-1
** The committee unanimously has agreed to accept Gregor's invitation to host
** the November Monday, Tuesday, Wednesday 6-7-8 meeting at Xerox PARC.
Reviewing Goals (by priority order):
-- Consistency with decision made by X3J13
-- Eliminate technical inaccuracy
-- Eliminate technical ambiguity
-- Eliminate typos, etc.
-- Clear presentation
Non-Goals:
-- Convince readers that Common Lisp is a "nice" language.
-- Make the language consistent with one's opinion of the "best"
computer language
12:00pm Lunch, Agenda Item 26
01:15pm Editorial Subcommittee, Kathy Chapman (continued)
The committee as a whole stood and crossed their heart that they would
abide by the reviewing goals as set out by David Moon.
EXTRA-RETURN-VALUES, Version 6, June 21, 1989
Jonl moved, and Barry seconded, that all functions can return extra values
and we add a macro N-VALUES n &body body, which returns the first n values
that body returns, appending NILS as necessary. n is evaluated, body is
an implicit PROGN. The amendment failed 6-10.
Walter moved, and Skona seconded, to eliminate bullet 2 of the proposal.
The motion passed 10-5.
The motion, as amended, passed 10-9.
01:50pm Characters Proposal, Thom Linden
Agenda Item 28
PROPOSAL 2.4.2
Kent moved, and Sandra seconded, an amendment to strike the first two
paragraphs of the proposal. The amendment passed 14-1.
David Moon moved, and Barry seconded, an amendment to add to the second
bullet "and FORMAT directives" and add to the third bullet CHAR-EQUAL and
other case-insensitive character predicates. The amendment passed
unanimously.
Chris moved, and Barry seconded, an amendment to add a new bullet which
says "the effect of CHAR-UPCASE and CHAR-DOWNCASE. The amendment passed
unanimously.
Walter moved, and Dick Waters seconded, an amendment to add DIGIT-CHAR to
the previously added bullet. The amendment failed 5-11.
The motion, as amended, passed 17-1.
PROPOSAL 2.4.3
Barry made a friendly amendment to pluralize repertoire at the end of the
first sentence.
David Moon moved, and Sandra seconded, an amendment to replace the
proposal with the following text:
"Every character repertoire name is a type specifier and a subtype of
type CHARACTER."
The amendment passed 16-3.
The motion, as amended, passed 16-2.
PROPOSAL 2.4.4
Barry moved, and Sandra seconded, an amendment to have char-label and
char-script-name return symbols, not strings. Barry withdrew his
amendment.
The motion failed unanimously.
PROPOSAL 2.4.5
The proposal was withdrawn.
PROPOSAL 2.5.1
A friendly amendment changed the last sentence of the description of the
FIND-EXTERNAL-CHAR function to "If the named coded character set does not
contain a character of the specified index character, NIL is returned.
Richard Lamson made a friendly amendment to change the name
of FIND-EXTERNAL-CHAR to EXTERNAL-CODE-CHAR.
Thom promised to supply a list of specific names.
Kent moved, and Barry seconded, an amendment to add
ALL-EXTERNAL-CODED-CHARACTER-SET-NAMES which returns a list of all the
coded character sets supported by the implementation.
The amendment passed 9-7.
The motion, as amended, failed 4-12.
PROPOSAL 2.5.2
A friendly amendment removed the paragraphs beginning "As many coded
character set names..." through "...hyphen, and digit 0-9 characters".
Richard Lamson moved, and David Moon seconded, that the first sentence
of the proposal be changed to: "* :EXTERNAL-FORMAT which specifies
an implementation-recognized scheme for representing characters in files."
and that "other than a member of the specified coded character sets to a
stream" be replaced by "which cannot be represented by the given file
format and that "to try" be deleted following "is an error". The
amendment passed unanimously.
Sandra added a friendly amendment to add the following sentence to the end
of the last paragraph: "Clarify that if the implementation does not
recognize the value given for :EXTERNAL-FORMAT, an error is signalled.
Larry made a friendly amendment to add STREAM-EXTERNAL-FORMAT
stream which does "the right thing" as per editorial committee.
The motion, as amended, passed 11-4.
PROPOSAL 2.5.4 (A)
The motion was approved with one vote in opposition.
PROPOSAL 2.5.6
Walter moved, and Sandra seconded, an amendment to add an argument
:ELEMENT-TYPE to MAKE-STRING-OUTPUT-STREAM which defaults the same way
MAKE-STRING does. The amendment passed 12-4.
Kent moved, and Barry seconded, an amendment to add an argument
:ELEMENT-TYPE to WITH-OUTPUT-TO-STRING which defaults the same way
MAKE-STRING does and permit an initial string of NIL to mean that an
initial string has not been supplied. If the initial string is supplied,
then the :ELEMENT-TYPE argument is ignored. The amendment passed 9-8.
Larry moved, and Bob Mathis seconded, an amendment to delete the phrase
"of the most specialized type". Larry withdrew his amendment.
David Moon moved, and Dick Gabriel seconded, an amendment to remove the
changes made by the previous two amendments (UNDO 2). The amendment
failed 4-12.
Kent Pitman moved, and Barry seconded, an amendment to change in both
bullets the phrase "of the most specific type..." to "of the indicated
element type." and to change "accepts all characters" to "accepts all
characters of the indicated element type." The amendment passed
unanimously.
The motion, as amended, passed 15-1.
PROPOSAL 2.5.7
A straw poll: would you accept this under some change? 7
there is no wording you would accept? 9
Bill York made a friendly amendment to replace the last sentence with the
sentence "The return value depends on the current state of the stream;
that is, two calls to FILE-STRING-LENGTH with the same stream and object
may return different values.
The motion, as amended, passed 12-5.
CONCERNING A FOOTNOTE IN SECTION 2.3.2
Kent moved, and JonL seconded, a motion that we adopt an explicitly vague
posture on the issue of what happens when a character is stored in a
string, the representation of which does not accomodate the character.
The editorial subcommittee is requested to provide an explicit note that,
in situations such as this, programmers should explicitly upgrade the
string in portable code. The motion passed 9-4.
03:30pm Cleanup Subcommittee, Larry Masinter
Agenda Item 19
COMPILE-FILE-SYMBOL-HANDLING
Steve moved a friendly amendment to make the following changes to the
proposal:
Page 2 - Extend the second paragraph:
Like macro-function, the SETF value (if not NIL) must be a function of two
arguments: the entire macro call, and the environment. The second
argument to MACRO-FUNCTION must be omitted when it is SETF.
Page 2 - Strike and replace the next-to-last paragraph:
The compiler is required to expand compiler macros; it is unspecified
whether the interpreter does so. The intention is that only the compiler
will do so, the range of possible "compiler-only" implementation
strategies precludes any firm specification.
Page 3 - Replace the first paragraph:
The issue LISP-SYMBOL-REDEFINITION precludes user definition of any
compiler macros for symbols external in the Lisp package that have a
definition as a function, macro, or special form.
Page 3 - Add after paragraph 2:
Note that if the expansion/nonexpansion of a compiler macro is to be
controlled by the compilation optimize declarations, it is up to the
compiler macro to consult these declarations (using the
DECLARATION-INFORMATION function).
Note that compiler macros do not appear in information returned by
FUNCTION-INFORMATION; they are global, and their interaction with other
lexical and global definitions can be reconstructed by
COMPILER_MACRO_FUNCTION. It is up to code-walking programs to decide
whether to invoke compiler macro expansion.
JonL moved, and Barry seconded, an amendment to the amendment to remove
the first paragraph added after paragraph 2. The amendment passed 8-4.
The motion, as amended, passed 14-3.
PATHNAME-LOGICAL
A call to close off debate passed 12-4.
The motion passed 12-4.
05:22pm Adjourn
Minutes submitted July 16, 1989, Mary S. Van Deusen.
∂17-Nov-89 1615 X3J13-mailer SXHASH questions
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 17 Nov 89 16:15:29 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 17 Nov 89 18:11:49-CST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Nov 89 16:11:23 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA28293; Fri, 17 Nov 89 17:11:27 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA10853; Fri, 17 Nov 89 17:11:24 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8911180011.AA10853@defun.utah.edu>
Date: Fri, 17 Nov 89 17:11:22 MST
Subject: SXHASH questions
To: x3j13@sail.stanford.edu
I hate to keep reopening the same old can of worms, but a bug in UCL's
implementation of SXHASH has pointed out more problems in the
specification of this function.
First there is the question of the requirement of consistency across
"incarnations" or "core images". CLtL says: "Hash values produced by
SXHASH may be written out to files, for example, and meaningfully read
in again into an instance of the same implementation." This doesn't
make much sense, since the hash values produced by SXHASH are integers
and of course it is always meaningful to print and read integers.
Perhaps what it intended to say is that the objects passed as
arguments to SXHASH can be printed out and read back in to a different
"incarnation", and SXHASH running in that "incarnation" would produce
the same result as in the original?
The other question has to do with the effect of destructive operations
on the object on the value returned by SXHASH, within a single
"incarnation". The CLtL description doesn't say anything about this
at all. Since the description of SXHASH uses EQUAL, one might think
of applying the same rule to SXHASH as for EQUAL hash tables, but I
don't see how it could return a consistent value for objects of types
that EQUAL would compare with EQ (such as structure types) except by
always returning a constant for all objects of that type, since
identity of objects across "incarnations" is not a well-defined
concept at all. If this wasn't the intent, the spec ought to include
an explicit caveat about *any* destructive modification of the object
possibly causing SXHASH to return inconsistent values, right?
One possible fix to both ambiguities is redefining SXHASH uniformly in
terms of "similarity as a constant", instead of using EQUAL within a
single "incarnation" and print/read consistency across multiple
"incarnations". I do not think this would be an incompatible change
for users; since EQUALity implies (or is at least supposed to imply)
similarity as a constant, the rule specified at the bottom of page 285
in CLtL would still hold.
Anybody else have any thoughts on this?
-Sandra
-------
∂17-Nov-89 2106 X3J13-mailer SXHASH questions
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 17 Nov 89 21:06:18 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 17 Nov 89 23:02:23-CST
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 17 Nov 89 21:02:07 PST
Return-Path: <barmar@Think.COM>
Received: from Leander.Think.COM by Think.COM; Sat, 18 Nov 89 00:04:25 -0500
Received: by leander.think.com; Fri, 17 Nov 89 23:59:47 EST
Date: Fri, 17 Nov 89 23:59:47 EST
From: barmar@Think.COM
Message-Id: <8911180459.AA10174@leander.think.com>
To: sandra%defun@cs.utah.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8911180011.AA10853@defun.utah.edu>
Subject: SXHASH questions
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Fri, 17 Nov 89 17:11:22 MST
First there is the question of the requirement of consistency across
"incarnations" or "core images". CLtL says: "Hash values produced by
SXHASH may be written out to files, for example, and meaningfully read
in again into an instance of the same implementation." This doesn't
make much sense, since the hash values produced by SXHASH are integers
and of course it is always meaningful to print and read integers.
Perhaps what it intended to say is that the objects passed as
arguments to SXHASH can be printed out and read back in to a different
"incarnation", and SXHASH running in that "incarnation" would produce
the same result as in the original?
Yes, this was the intent. In the context of SXHASH, the "meaning" of the
value is that (EQUAL x y) implies (= (SXHASH x) (SXHASH y)); the sentence
is saying that you can write x and (SXHASH x) to a file, and when you later
read them back (even in a different incarnation) the relationship is still
true.
One possible fix to both ambiguities is redefining SXHASH uniformly in
terms of "similarity as a constant", instead of using EQUAL within a
single "incarnation" and print/read consistency across multiple
"incarnations". I do not think this would be an incompatible change
for users; since EQUALity implies (or is at least supposed to imply)
similarity as a constant, the rule specified at the bottom of page 285
in CLtL would still hold.
I think this is a wonderful solution. The notion of "similar as constant"
is a very recent thing, and can probably be applied in most cases where
relationships between data in different incarnations of Lisp are involved.
∂05-Dec-89 1258 X3J13-mailer FYI -- tech report available
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Dec 89 12:58:20 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 5 Dec 89 14:49:33-CST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Dec 89 12:49:02 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA08538; Tue, 5 Dec 89 13:49:11 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA25813; Tue, 5 Dec 89 13:49:09 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8912052049.AA25813@defun.utah.edu>
Date: Tue, 5 Dec 89 13:49:07 MST
Subject: FYI -- tech report available
To: x3j13@sail.stanford.edu
Several of you have expressed interest in getting a copy of my thesis,
which deals with visual debugging tools and implementation mechanisms
for debuggers. It is now available as a UofU tech report. If you
want a copy, send a message with your snail-mail address to
hughes@cs.utah.edu (Stephanie Hughes). Ask for report UUCS-89-020.
-Sandra
-------
∂19-Dec-89 1216 X3J13-mailer address change
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 19 Dec 89 12:16:11 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 19 Dec 89 13:52:40-CST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Dec 89 11:51:29 PST
Received: from rose ([192.31.212.83]) by lucid.com id AA19170g; Tue, 19 Dec 89 08:48:02 PST
Received: by rose id AA17764g; Tue, 19 Dec 89 08:50:39 PST
Date: Tue, 19 Dec 89 08:50:39 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8912191650.AA17764@rose>
To: X3J13@sail.stanford.edu, common-lisp@sail.stanford.edu
Subject: address change
LISP AND SYMBOLIC COMPUTATION: An International Journal
and
X3J13 Business
Please send future correspondence, submissions and reviews to me at the
following address:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
415/329-8400 x5509
I will be in transit for 3 weeks after Christmas arriving January 15.
---jan---
∂19-Dec-89 1349 X3J13-mailer COMMON-LISP symbols database available
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 19 Dec 89 13:49:12 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 19 Dec 89 15:45:04-CST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Dec 89 13:44:25 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA28472; Tue, 19 Dec 89 14:44:36 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA05723; Tue, 19 Dec 89 14:44:30 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8912192144.AA05723@defun.utah.edu>
Date: Tue, 19 Dec 89 14:44:28 MST
Subject: COMMON-LISP symbols database available
To: x3j13@sail.stanford.edu
I have built an annotated database of all symbols which I believe are
supposed to be exported from the COMMON-LISP package.
Here are some interesting statistics:
972 symbols total have usages defined (some symbols have multiple usages)
62 class names
62 symbolic constants
9 symbols that name declarations
6 symbols that name documentation types
611 non-generic functions
26 generic functions
8 lambda-list keywords
91 macros
10 standard method combinations
5 optimize qualities
21 symbols used as random syntax
5 restart names
70 symbols that name places for SETF
29 special forms
92 type names
25 symbols which can be used in type specifier lists
53 variables
You can FTP a copy of the database from cs.utah.edu (128.110.4.21), in
directory pub/cl-index. Look at the "readme" file there for more
information about the format of the entries.
If you find mistakes in the database or have suggestions for adding
more annotations, please send me mail. I've checked the list of
symbols against a list prepared independently by David Moon, but I
suspect that there might be a few symbols which have been given
incorrect usages.
-Sandra
-------
∂20-Dec-89 1704 X3J13-mailer updated symbols database
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 20 Dec 89 17:04:33 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 20 Dec 89 18:58:30-CST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Dec 89 16:57:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.4-cs)
id AA02132; Wed, 20 Dec 89 17:58:14 -0700
Received: by defun.utah.edu (5.61/utah-2.3-leaf)
id AA06973; Wed, 20 Dec 89 17:58:09 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8912210058.AA06973@defun.utah.edu>
Date: Wed, 20 Dec 89 17:58:08 MST
Subject: updated symbols database
To: x3j13@sail.stanford.edu
I have updated the database of COMMON-LISP symbols to include a few
missing usages that have been pointed out to me. Also, as suggested
by David Moon, I have given all TYPE-NAME symbols an explicit
DECLARATION usage as well. The new files are available in the same
old place on cs.utah.edu.
-Sandra
-------
∂10-Jan-90 0519 X3J13-mailer FIND-CLASS for "forward-referenced" classes?
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 10 Jan 90 05:19:25 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 10 Jan 90 07:15:29-CST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 90 05:14:48 PST
Received: from bhopal ([192.31.212.13]) by lucid.com id AA04817g; Wed, 10 Jan 90 05:14:42 PST
Received: by bhopal id AA16374g; Wed, 10 Jan 90 05:12:51 PST
Date: Wed, 10 Jan 90 05:12:51 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <9001101312.AA16374@bhopal>
To: x3j13@sail.stanford.edu
Cc: cl-cleanup@sail.stanford.edu
Subject: FIND-CLASS for "forward-referenced" classes?
[Apologies for double copies some of you will receive -- numerous people
are on one of these distribution lists, but not the other.]
Should FIND-CLASS find a "class" that has only been mentioned in a
forward-referenced way, as a direct-superclass of a non-finalized class?
Does the name of such "class" constitue a valid type-specifier? E.g.,
(defclass FOO (BAR) (a b c))
defines a non-finalized class named FOO, but does it define one named BAR?
Chapters 1&2 of the CLOS specification do not specify how one should
arrange to make "forward" references to superclasses work. Chapter 3
suggest somewhat indirectly an implementation technique of actually
creating a class object, to use as a stub, for such a reference. But
there seems to be no requirement that it must be implemented this way;
some implementations do it this way, and some apparently just keep
around internal lists of the class names that were referenced in a
"forward" way.
Arguing against letting FIND-CLASS return a forward-referenced-class
object is that the existence of such an actual class-object is merely an
implementational artifact, and may not even be portable. From a larger
point of view, one could ask why the mere mention of a potential class
name BAR when defining the class FOO should give any legitimate definition
for BAR; certainly when you make a forward reference to a function name,
you don't define that funcion; i.e.
(DEFUN FOO (X) (LIST (BAR X X)))
will define FOO, but not define BAR.
Arguing for letting *something* find the forward-referenced class is
the fact that when using the metaobject protocols in an implementation
that supports forward references this way, you will eventually want a
handle on the actual object.
Finally, it must be asked, what is the behaviour of the type system on
non-finalized classes (i.e., classes which have some direct, or even
non-direct, superclass that hasn't been defined yet). Clearly, TYPEP is
moot, since you can't make instances of non-finalized classes. But what
about subtypep? The answer for non-finalized class names probably should
be consistent with the answer for forward-referenced class names.
One possible alternative is simply to say that the class names (or class
objects too) don't become valid type specifiers until the class is fully
defined.
-- JonL --